Hans Karlsen (talk | contribs) (Created page with "Working with CodeDress and if you get this error "No suitable constructor found" check the following: In the GAC check that you only have the current Eco.Interfaces - and not...") |
Hans Karlsen (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
Working with CodeDress and if you get this error "No suitable constructor found" check the following: | Working with CodeDress and if you get this error "No suitable constructor found" check the following: | ||
In the GAC check that you only have the current Eco.Interfaces - and not any old copies of the assembly: | In the GAC check that you only have the current Eco.Interfaces - and not any old copies of the assembly - and that the GACed version is the version in MDrivenServer/bin: | ||
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Eco.Interfaces | C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Eco.Interfaces | ||
| Line 8: | Line 8: | ||
When the linker tries to resolve the reference to Eco.Interfaces - it may end up with the wrong one and then nothing matches up correctly and we have no access to the correct contstructor. | When the linker tries to resolve the reference to Eco.Interfaces - it may end up with the wrong one and then nothing matches up correctly and we have no access to the correct contstructor. | ||
This issue does not normally arise on the server since you probably have not installed MDrivenFramework there. The problem arises due to a fight on what version to use between MDrivenFramework (that must GAC assemblies to allow for VisualStudio to work) and MDrivenServer that does not GAC assemblies. | |||
Revision as of 09:39, 2 September 2018
Working with CodeDress and if you get this error "No suitable constructor found" check the following:
In the GAC check that you only have the current Eco.Interfaces - and not any old copies of the assembly - and that the GACed version is the version in MDrivenServer/bin:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Eco.Interfaces
Also check the CodeDress assemblies (\ModelCodeAssemblies) so that you do not have any Eco.* assemblies there - the linker will wrongfully mix in these instead of the ones in your running application (Turnkey or MDrivenServer)
When the linker tries to resolve the reference to Eco.Interfaces - it may end up with the wrong one and then nothing matches up correctly and we have no access to the correct contstructor.
This issue does not normally arise on the server since you probably have not installed MDrivenFramework there. The problem arises due to a fight on what version to use between MDrivenFramework (that must GAC assemblies to allow for VisualStudio to work) and MDrivenServer that does not GAC assemblies.