You can resolve No suitable constructor found errors in CodeDress, MDrivenServer, Turnkey, or the MDriven Designer Play action by removing conflicting assemblies and ensuring that the model, CodeDress assemblies, and running application use compatible binaries.

What this error usually means

This error commonly means that CodeDress resolved an incompatible version of Eco.Interfaces.dll. The application then looks for a constructor defined against one version of the interfaces while a different version has been loaded. The constructor is therefore not considered suitable, even when the generated or custom code appears correct.

This is usually an assembly-loading problem, not evidence that you must add or change a constructor in your model. If you are designing a model constructor, see Documentation:Constructor in generated code.

Fix assembly-version conflicts

Use the following checks in order. Rebuild and test after completing them.

1. Close Visual Studio, MDriven Designer, and any local Turnkey or MDrivenServer process that is using the affected model.
2. Check the Global Assembly Cache (GAC) for Eco.Interfaces. On Windows, inspect:
   • C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Eco.Interfaces
3. Ensure that the GAC does not contain old copies of Eco.Interfaces.
4. If an Eco.Interfaces assembly must be present in the GAC, ensure that it is the same version as the assembly in the running MDrivenServer installation's bin directory.
5. Check the model's ModelCodeAssemblies directory. Do not place Eco.* assemblies there.
6. Clean the Visual Studio solution, then rebuild it.
7. Start the application again and repeat the action that produced the error.

Location	What to check	Why it matters
GAC	Old or conflicting Eco.Interfaces assemblies	CodeDress can resolve an old GAC assembly instead of the interfaces expected by the running application.
ModelCodeAssemblies	Any Eco.* assemblies	The linker can mix these assemblies with the assemblies loaded by Turnkey or MDrivenServer.
MDrivenServer bin directory	The Eco.Interfaces version used by the running server	This is the version that must match the version used by the model and CodeDress in this scenario.

For example, a development workstation may have MDrivenFramework assemblies installed for Visual Studio support while MDrivenServer uses assemblies from its own installation directory. If CodeDress loads an older GAC copy of Eco.Interfaces, the types no longer match the server's types and constructor resolution fails.

If the error occurs when you press Play in MDriven Designer

The MDriven Designer Play action starts the system and searches for CodeDress assemblies. The error can occur if the model is stored in a directory that makes CodeDress scan unrelated assemblies.

1. Create or choose a directory used only for the model and its intended files.
2. Move the model to that directory.
3. Make sure unrelated application DLLs are not located where CodeDress will scan them.
4. Open the moved model in MDriven Designer.
5. Press Play again.

For example, do not keep a model beside output folders or collections of DLLs from other applications. Put the model in its own directory so CodeDress only discovers assemblies that belong to that model.

Verify target compatibility

The binaries for .NET Framework and .NET Core are different. A CodeDress assembly built with a Framework-targeted model will not work with a core-built server, and the reverse combination is also incompatible.

If the running server targets .NET Core, create a ModelProject in Visual Studio that targets .NET Core and build the model from that project. Also ensure that the installed Turnkey version and the MDriven Framework installed for Visual Studio are the same version. For a Turnkey debugging workflow, see HowTos:Debug Turnkey Generic Code.

Version-name change to be aware of

The assembly description changed from ECO to MDriven with the introduction of NuGet support for .NET 5. Treat this as a significant version boundary. A mismatch where MDrivenServer uses one version and CodeDress was compiled against another can produce this error.

When to investigate constructors instead

Investigate the model or generated constructor only after you have ruled out assembly conflicts. A normal constructor in generated code has a specific signature, and constructors for live objects normally receive an IEcoServiceProvider. The supported patterns are described in Documentation:Constructor in generated code.

If the related error says that an object is unavailable offline, the issue is different: the object was created without an EcoSpace service provider. Follow Documentation:Not available for Offline object for that case.

If the error remains

Check these details before continuing troubleshooting:

• The version of the MDrivenServer installation that is running.
• The target framework used to build the ModelProject and CodeDress assemblies.
• Whether the GAC still contains an older Eco.Interfaces assembly.
• Whether ModelCodeAssemblies contains any Eco.* assemblies.
• Whether the error happens in Visual Studio, when pressing Play in MDriven Designer, or only in a running Turnkey application.

If the failure is instead related to generated source files or Visual Studio project-file structure, use HowTos:Fix Code Generation Issues.

See also

• HowTos:Debug Turnkey Generic Code
• Documentation:Constructor in generated code
• Documentation:Not available for Offline object
• HowTos:Fix Code Generation Issues