I was under the impression that if you use a configuration reference set to you main model and referenced subsystems, all will be affected. However, it is breaking my code generation advisor checks. This is the image I am getting:
Is this normal? I thought it should work as usual as the individual settings. Is it because it cannot distinguish between a config reference or a single config file?
The way I have propagated the config reference to all the models is by opening Model Explorer > Reference > Propagate to Referenced Models.
Related
I have a huge Simulink model and I am testing some options to improve its performance. The model is implemented using a library for reusable components and subsystem for the hierarchy and organization.
I was wondering if converting some subsystems to model reference will improve performance, besides other advantages. The problem is that every single library component is a masked subsystem itself, and so far I couldn't figure out how to convert a masked subsystem to a model reference. A error message appears when trying to convert:
Invalid usage of convertToModelReference. The subsystem to be
converted must be an atomic, or triggered subsystem block. Cannot
convert a virtual subsystem to a model
Reading simulink documentation did not help.
My questions is:
Is it possible to convert a masked subsystem to a model reference?
If yes, do I need to make some adjustments in every masked subsystem/library block through the whole hierarchy? (Or only in the reespective top tier block that I am trying to convert?)
What is this error message about?
In addition to what Phil said, you can only convert an atomic subsystem into a referenced model. An atomic subsystem means that the subsystem executes as a whole rather than the hierarchy of the model being flattened during compilation, as with virtual subsystems. For more details, see the documentation. You can have library components within referenced models, but there are a number of limitations, see Simulink Model Referencing Requirements and Model Referencing Limitations.
Despite the constraints, model referencing is generally advised as the way to approach large-scale modelling and it should give you performance improvements, as the referenced models run in accelerated mode (unless otherwise configured), and are rebuilt only when structural changes are made to the model. See Componentization Guidelines in the documentation for more details.
In my experience that's a catch all error message, which basically means that something is wrong (but not necessary the obvious virtual subsystem problem that it seems to indicate), but the converter doesn't have enough "smarts" to give a very specific fix to the problem.
Sometimes the problem is that parameters needed by the reference block aren't being passed through the mask to it correctly.
But you most likely need to look at various of the limitations of model referencing and work through the potential issues.
Depending on how many conversions you have to do you might find manually converting the subsystems (by copying them into new models and configuring the new models manually) is less frustrating that trying to figure out why the automatic conversion is not working.
I'm new to the Entity Framework. I've created a model-first schema in Visual Studio 2012 with EF5, but I'm having trouble getting the generated code to build. One of my entities ("Test") has the same name as the model (edmx) and the project (csproj) files, so it conflicts with the namespace (Test is a namespace but is used like a type). So I decided to change the namespace by setting a "Custom Tool Namespace" for the .tt files. This worked, but then I found that the "Test" entity's generated .cs file was entirely empty (other entities were generating properly), so I had build errors where other entities reference "Test". Renaming the entity results in a properly generated class, and therefore a building project, but I really want to use the original name.
I will probably end up scratching the project and starting over, ensuring to choose unique names for the project, the model, and the entity. But I'd rather know how to fix this if possible in case I run into something similar when the project is further along and it's not so easy to start over.
you can use use an alias on the Using Directive, e.g. using Project = PC.MyCompany.Project; to differentiate between namespaces. see MSDN
I have several columns that I changed from Int to BigInt.
I opened up my EF model and did an 'Update Model from Database' and expected to see those columns now be Int64s. But they are still Int32s.
(I ran it several times just to be sure.)
I double checked my database and the columns are definitely BigInts.
So... does 'Update Model from Database' not work for a change of data type? Does it need to be manually applied?
Unfortunately, you'll need to delete the items from your model and then add them back in - at least that's the only thing I have managed to get working.
There is at least one third-party tool that is supposed to help with this, but have not tried it personally.
I'm using VS2008 SP1. If you change the datatype in the "ModelView" (CSDL) of the edmx, errors will occur because the "DatabaseModel" (SSDL) is not updated. You have to edit the *.edmx manually (XML). That is not so hard as it sounds.
You can simply search for the Property that the "Error List" of VS provides you (search in files is maybe the best solution for this). Go to the line where the wrong datatype appear and fix it.
e.g. you changed float to nvarchar(50) on the database --> go to your model and change Double to String --> validate --> Error.... --> Search for the property and make following changes:
<Property Name="YourChangedProperty" Type="float" />
to
<Property Name="YourChangedProperty" Type="nvarchar" MaxLength="50" />
This works very well if you know exactly what you've changed on the database. If you've made countless changes, you would have to analyse your changes with some DB-compare tool or regenerate the whole model.
Not very nice. But it "works".
take care
M
Correct - data types don't appear to update automatically. You can simply change the data type in the model view using the Properties window and change the Type to Int64.
Answer
For the specific scenario you mentioned, you will need to manually change the Type from Int32 to Int64.
There are a number of ways that this can be done, but the easiest is probably just to open the model (using the default editor) and change the Type of the property from Int32 to Int64.
Explanation (from MSDN Library)
The ADO.NET Entity Data Model Designer (Entity Designer) uses the Update Model Wizard to update an .edmx file from changes made to the database. The Update Model Wizard overwrites the storage model as part of this process. The Update Model Wizard also makes some changes to the conceptual model and mappings, but it only makes these changes when objects are added to the database. For example, new entity types are added to the conceptual model when tables are added to the database, and new properties are added to entity types when columns are added to a table. For details about what changes are made to the .edmx file, see Changes Made to an .edmx File by the Update Model Wizard.
For your scenario, the important thing to note is that the update model wizard is updating the .edmx file with your changes, but only to the storage model. When changes are made to the definition of existing columns, the conceptual model is not updated. For a complete description of changes made by the update model wizard, please see the "Changes Made to an .edmx File by the Update Model Wizard" link above.
You need delete your EF model and than create again and will work.
This may be an older question, but it is most assuredly still relevant today as the issue has not changed. As such, I thought I'd offer a synopsis of the research performed to date on the issue, including some observations of my own:
This failure to update the existing data-types is by design, based upon notes attached to Microsoft's documentation on the topic, as reported in the answer from timb. (Note that Microsoft appears to have either moved or purged the linked document and current documentation does not refer to this issue, but similarly worded notes can still be found elsewhere in archived documentation. Reference) The "Update Model from Database..." wizard does not update those changes, and instead pushes the onus for resolving the issue back onto the developer, in order to avoid making incorrect automatic changes which could theoretically corrupt the Model in ways which were not intended by the developer.
As such, there are really only two ways to resolve the issue, without resorting to third party tools:
Delete the affected tables from the Model and re-add them with the "Update Model from Database..." wizard, as noted in the answer from E.J. Brennan. The potential weakness of this method is that it doesn't always succeed, particularly if the original model was generated using a previous version of the Entity Framework, which can sometimes force the developer to perform significantly more work than might otherwise be necessary to complete the task.
Manually adjust the affected fields from the graphical model viewer, by right-clicking on the field in the table and selecting "Properties..." from the contextual menu. NOTE: Do not make manual changes directly to the Model .cs files from a code window, as such changes will be reverted the next time the "Update Model from Database..." wizard is run; if the changes are performed from the graphical model viewer, they will persist beyond re-running the wizard.
Also if you work with MySQL on Windows - recreating model may also wont help. Schema is somehow cached in MySQL. So if model is not updated even after recreation try to restart MySQL service and VS to be sure. After that model should be successfully updated.
I solved this by modifying the .EDMX file with a text editor.
Find your value and change it's type. Then correct the type in other errors that will be shown in the debugger.
I work with EF 4 (not with Self-tracking entities currently). I've added some columns (non of them is a key and all of the are nullable) to one of my entities, and got the Number of members in conceptual type does not match with number of members on object side type exception.
I've followed the accepted answer here but all I got from that was that this entity does not appear in my edmx anymore. I've re-added it from DB, but I keep getting the same exception.
I think the problem is that I've copied the csdl/ssdl/msl files to my executing assembly directory. I'd like to copy the updated files, but they're not created again (they were once created in the obj\Debug\edmxResourcesToEmbed folder of my EF project), not even after removing them.
Any way to get those files created again?
Thanks.
P.S: As I don't want to publish excess amounts of code, I don't add anything yet but I'll be happy to add needed information, I'm just not sure what exactly is needed.
So if you want to create the csdl, ssdl amd msl files, do the following:
Go to your edmx file.
Click on the GuI screen that shows the model.
Switch to the property window (I didn't know that it needs to be accessed from the GUI area and not by right clicking the file in the Solution Explorer.
In the Metadata Artifact Process select Embed in Output Assembly.
Done and done, the files will appear in Debug\edmxResourcesToEmbed under obj or obj\x86, depends on your build definitions.
I'm sorry if this seems to simple to explain, but I was in need for those instructions (msdn was not a great help) and I hope it might help others.
What are (If there are) the differences between a Simulink library and a model reference. There's advantadges in using either of them in different situations?
The main purpose of libraries and model reference are the same: facilitate the reuse of simulink models. When you work with libraries, simulink "imports" the content of the referenced models in to the main model. Sometimes, this leads to the developer dealing with gigantic models (more than 50k blocks), which can be time consuming. When you are designing a library, the lib file cannot be run. You have to "instantiate" it in the main model. On the other side, model reference deals with separated models. They are put together when you press the simulate button, but during the design time, you deal with completely separated models. With model reference, you can also select acceleration methods (it basically compiles the model) and this can't be done with libraries.
Adding some more to danielmsd's answer:
Configuration Management: Model references can be put easily into
version control and developers can work independently from each other. A library is one file, so the blocks
cannot be versioned individually and developers cannot work in parallel.
You can protect model references.
Code Generation: Incremental build is only possible with model referencing.
BUT:
Model referencing has quite a few limitations, so check them out carefully before picking this option. See Model Referencing Limitations.
From a system design perspective model references should be used for components of your system. That is the different parts your system is made from. Libraries should be used as utilities. That is reuable blocks that are used through out your design.
For example a robot control system includes components: navigation, control, path_plannen etc. These are components and should be implemented with model references. In that case they are developed as independent models and can be tested independently.
Inside the components you could need utility blocks such as low_pass_fileter, error_state_handler and check_input_range, they are libraries.
Advantages of mdl ref:
- Code generation: Model references allow partial builds when using the coder product. Assuming you have a really large model with 100k blocks and it takes 20 minutes to build, splitting it up in model references will reduce the build time since only the changed model will need to rebuild.
Model update: only changed model references are updated "CTRL+D" therefore this helps when having really large models.
Simulation: In simulations mdl refs are generated as dlls which makes your simulations much faster (the effect is much bigger than the difference between normal and accellerator mode)
Disadvantages pains:
- In general Mdl referencing is somehow a pain to use due to limitations
There is no possibility to pass a Simulink.parameter.object which has a tree structure. (When using type:BusObject only the value property has a structure, the other properties don't)
When a subsystem has a bus signal as input, a mdl ref needs a bus object to specify the input interface, and the library block doesen't. (Even if its quite ugly to use unspecified bus inputs in a lib block). (Note that busobject are always global in the base workspace... risk of naming collisions)