I am on llblgen 5.8 but had to install 4.2 because I have to compile for a windows 2003 environment. Alle code in the problem situation is generated with 4.2.

This drives me crazy....

Severity Code Description Project File Line Suppression State Warning The primary reference "HITc.OPCSupport" could not be resolved because it has an indirect dependency on the assembly "SD.LLBLGen.Pro.ORMSupportClasses, Version=5.8.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27" which was built against the ".NETFramework,Version=v4.5.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Tester C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 2203

I am compiling everything against 4.0 Profile Client. There are no references to 5.8. The error occurs when I try to do some tests in a console program testing the code that on itself compiled fine. I do not see where the references to the 5.8 lib are from.

I'm stuck......

Using visual studio, I presume? As this likely is caused by visual studio's retarded way to resolve assemblies. It uses 'hint paths' with an assembly where they are to be found, but even if the assembly is in that folder (e.g. if you look at the 'Path' in the properties of the assembly reference) it might still reference another one from elsewhere.

To fix it, set the 'Specific Version' to 'true' for the reference and make sure the version is the right one.

An indirect reference is likely pulled in by the generated code you're referencing. So your cli app references HITc.OPCSupport, but that references the wrong dlls (likely due to this vs issue).

vs 2022 does a better job at this tho, but 2019 and earlier don't

I am on VS 2019.

Just noticed that somewhere in the process of adding references to the test program the following is added to the config:

<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-2.0.14.0" newVersion="2.0.14.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="SD.LLBLGen.Pro.ORMSupportClasses" publicKeyToken="ca73b74ba4e3ff27" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.8.0.0" newVersion="5.8.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="SD.LLBLGen.Pro.DQE.SqlServer" publicKeyToken="ca73b74ba4e3ff27" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.8.0.0" newVersion="5.8.0.0" /> </dependentAssembly> </assemblyBinding> </runtime>

I'll try to find out when that is happening.

Well, we're not adding the assembly redirect, so something else must be doing that. Resharper perhaps? Or another helpful addon?

Thanks for your help. I recreated the test program from scratch and it seems to be working now. Pffff. Allways a lot of stress if you encouter these kind of things and they have to be solved asap.

Yeah I've been there many times too and know how you feel! So next time: check config file and set specific version, that should at least get you a running system (and sometimes toss the .vs folder but as it's visual studio, that may or may not help)