You can use this page to diagnose a failed MDriven C# code generation run in Visual Studio, including locked generated files and the ObsoleteYOUNEEDTOACT compile error.
Code generation (Codegen) generates C# from your MDriven model. Start with the message or symptom you see, then apply the matching fix below.
Resolve a locked generated file
If Codegen reports a message such as "Sometimes the files are locked by VS - please try again.", Visual Studio is likely holding a generated source file open.
- In Visual Studio, close every editor tab that displays generated code.
- Run Codegen again.
- If the error remains, close all editor tabs, restart Visual Studio, and run Codegen again.
Do not edit generated files to work around a lock. Generate the files again after Visual Studio releases them.
Remove a Solution Items node
A Solution Items node in the Visual Studio solution has been reported to interfere with Codegen.
- In Solution Explorer, look for Solution Items.
- Remove the Solution Items node from the solution.
- Run Codegen again.
Repair code generation for selected classes
When Codegen does not work for one or more classes, the Visual Studio project may have incorrect relationships between the class file and its generated .eco.cs file. This can happen after a source-control merge.
Follow Fix Code Generation Issues to excludeânot deleteâthe affected generated .cs and .eco.cs files, then generate all code again with Ctrl + <the C# button>. The regeneration restores the expected Visual Studio file structure without overwriting files.
For .NET Standard-style project formats, files in a directory can be included automatically, which can prevent the modeling environment from locating them in the project file. See Codegen Issues .net standard for the required project setting and DependentUpon structure.
Fix ObsoleteYOUNEEDTOACT
ObsoleteYOUNEEDTOACT is a deliberately generated attribute that makes the project fail to compile. It tells you that C# contains a model-identified method that no longer has a matching valid method in the UML model.
A generated model method has a UmlElement id. Codegen adds ObsoleteYOUNEEDTOACT when it finds a method with such an identifier and either:
- the UML class no longer contains the identified method, or
- the method exists in the model but is implemented with OCL or EAL through its Body expression.
Why you must act
At runtime, compiled MDriven code is reflected back into a model. A method that remains in C# with a stale UmlElement id can make the model checksum obtained from code differ from the checksum obtained from the model. This mismatch can affect MDrivenServer and prototyping; in particular, MDrivenServer can refuse to save data.
Choose the correct cleanup
| Situation | What to do |
|---|---|
| You deleted the method from the model and no longer need its C# implementation. | Remove the obsolete generated method from your C# code, then build again. |
| You deleted the method from the model but want to retain the C# implementation as an ordinary helper method. | Keep the method, but remove its UmlElement id so it is no longer presented as a model method. |
| The method is now implemented by an OCL or EAL expression in the model. | Remove the old C# model-method implementation, or retain it only as an ordinary helper after removing its UmlElement id. |
| You intended the method to remain a C#-implemented model method. | Restore or correct the method in the model, generate code again, and build. |
For example, if you remove a modeled method named CalculateTotal, then generate code, an older C# implementation of CalculateTotal that still carries its UmlElement id is no longer valid as a model method. Delete that stale implementation, or remove the identifier if you are keeping it only as a non-model helper.
Extra C# methods are allowed. The problem is not an extra method by itself; the problem is an extra method that still claims the identity of a UML element that is absent from, or no longer C#-implemented by, the model.
Generate, build, then upload
After you change model structureâsuch as classes, associations, state machines, or methodsârefresh the generated code and build before you use the updated application or upload the model.
- Generate code with the C# button. If needed, right-click the C# button and choose to generate all.
- Build the Visual Studio project.
- Upload the model only after the build succeeds.
This order matters when using CodeDress: the compiled assemblies are uploaded and reflected to provide C# model-method implementations. Uploading before building can send assemblies that represent an older model. See Code generation and Switching to Visual Studio from MDrivenDesigner for the full workflow.
Keep C# implementations intentional
When a modeled method has an empty EAL Body, Codegen can generate a C# stub for its implementation. C# implementations let you use model access and referenced .NET assemblies, but use OCL and EAL where they express the intended model behavior. Expressions in the model remain visible to MDriven's model inspection, cross-references, and look-ahead behavior.
If a CodeDress project fails after a framework or server update, also verify that the MDriven framework version used to compile the project is in the same vicinity as the Turnkey version. See Calling your own C# .NET things from Turnkeyâserver side.