You can restore MDriven C# code generation in Visual Studio when generated code is missing, stale, incorrectly nested, or fails to generate for one or more model classes.

Code generation (Codegen) creates C# files from your MDriven model. For each generated class, Visual Studio must recognize the main .cs file and its generated .eco.cs companion with the correct dependency relationship.

Start with a safe regeneration

Use this procedure when Codegen does not update one or several classes, or when generated files have the wrong structure in Solution Explorer. This can occur after a source-control merge changes the project file.

1. In Visual Studio, locate the affected generated class files in Solution Explorer.
2. Exclude both generated files from the project: the ClassName.cs file and the ClassName.eco.cs file. Exclude them; do not delete them from disk.
3. Open the model and regenerate code:
   • Use the C# generation button with Ctrl held, as used in older workflows; or
   • Right-click the C# generation control and choose the option to regenerate all code. This regenerates code even when checksums agree.
4. Confirm that the files are included again in the project.
5. Build the project and resolve any compilation errors before continuing.

For example, if Customer.cs is present but Customer.eco.cs is no longer nested beneath it after a merge, exclude both files and regenerate all code. Codegen does not overwrite the files during this recovery; it regenerates the correct Visual Studio project structure.

Check the project-file dependency

If the issue returns, unload or otherwise open the Visual Studio project file and inspect the entries for an affected class. The generated .eco.cs file must depend on the corresponding .cs file.

<Compile Include="EcoProject1\Class1.cs" />
<Compile Include="EcoProject1\Class1.eco.cs">
  <DependentUpon>Class1.cs</DependentUpon>
</Compile>

The DependentUpon value is the main file name, not its full path. In this example, Visual Studio displays Class1.eco.cs under Class1.cs.

Do not edit generated class content to repair a generation problem. Repair the project-file inclusion and dependency, then regenerate from the model.

SDK-style .NET projects

Newer .NET project formats automatically include files that exist in the project directory. In that format, Codegen may not find generated files through the project file and generation can behave inconsistently.

Follow Documentation:Codegen Issues .net standard to disable default compile-item inclusion and define the generated-file dependency. That guidance uses an Update entry for the generated file, for example:

<Compile Update="EcoProject1\Class3.eco.cs">
  <DependentUpon>Class3.cs</DependentUpon>
</Compile>

Keep the project-file approach consistent with the project format. Do not add a second competing inclusion for the same generated file.

If Codegen reports locked files or fails

If Codegen reports that files may be locked by Visual Studio, close every editor tab that shows generated code. Restart Visual Studio if needed, then run generation again.

Also inspect Solution Explorer for a Solution Items node. Remove that node if it is present; it has been reported to prevent Codegen from working correctly. See Documentation:Codegen failed for this failure mode and its specific diagnostic.

Resolve ObsoleteYOUNEEDTOACT errors

An ObsoleteYOUNEEDTOACT attribute in generated code is deliberate. It means Codegen found a C# method with a UML element identity (UmlElement id) that no longer represents a method in the UML model, or represents a model method implemented through an OCL or EAL expression in its body.

The generated attribute intentionally prevents compilation. Do not work around it by removing the generated diagnostic. Instead, make the implementation code and model agree:

1. Find the flagged method in your C# implementation code.
2. Decide whether the method should remain a model method.
   • If it should remain in the model, restore or correct the corresponding model method, then regenerate code.
   • If it is now an ordinary implementation-only C# method, keep the method but remove its UML element identity so it is no longer treated as a model method.
3. Regenerate code and build the project.

For example, if you delete the CalculateTotal method from the model but retain a C# method carrying its former UML identity, Codegen adds ObsoleteYOUNEEDTOACT. You may retain CalculateTotal as extra implementation code, but it must not retain the identity of the deleted model method.

This check prevents a mismatch between the model checksum and the checksum reflected from compiled code. Such a mismatch can cause MDrivenServer or prototyping to refuse database saves, so treat the compile error as a required model/code cleanup step.

Verify model, code, and server are aligned

After repairing generation, update the full chain in this order:

1. Treat the model open in MDriven Designer as the intended version.
2. Generate C# code and build the project so the compiled assemblies reflect that model.
3. Upload the model to MDrivenServer. If you use CodeDress, building first avoids uploading old assemblies with an old model.
4. Start the local application or Turnkey server and test a save operation.

For the complete explanation of the model, compiled-code, and server versions, see Documentation:Code generation.

Related Visual Studio issue

If opening an .ecomdl file shows XML rather than the model surface, this is not a class-code generation failure. Use HowTos:Fix Visual Studio Not Opening Model File and review Documentation:Visual Studio before retrying Codegen.

See also

• Documentation:Code generation
• Documentation:Codegen failed
• Documentation:Codegen Issues .net standard
• Documentation:Visual Studio
• HowTos:Debug Turnkey Generic Code
• HowTos:Evolve Database with Code