Linking bug - when using without adding all dlls in the project

[Watchwolf]

Describe the bug Can't load dll, the manifest definition is different from the assembly.

To Reproduce

• I create a dll which use RazorLight 2.0 Beta 10 installed with Nuget.
• I compile it and then copy all dlls from Debug\ into my second project (command line tools).
• I reference ONLY my dll in the second project
• When I run my second project I have the error :

"Impossible de charger le fichier ou l'assembly 'System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' ou une de ses dépendances. La définition trouvée du manifeste de l'assembly ne correspond pas à la référence de l'assembly. " English : "Can't load the file/assembly 'System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one dependencies. The definition found in the manifest of the assembly is different from the assembly referenceed.

The version of the dll System.IO.Compression is 4.2.0.0.

Expected behavior My second project (command line tools) should run fine without having to references all the RazorLight dlls in the project file.

Information (please complete the following information):

• OS: Win 10
• Platform NET Framework 4.6.2
• RazorLight version 2 Beta 10
• Are you using the OFFICIAL RazorLight package? Yes
• Visual Studio version Community 2019

Thank you for your help :)

[jzabroski]

@Watchwolf Why do you think this is a bug with RazorLight and not an incorrectly configured csproj by your consuming app?

It is a bit strange that you are manually copying dll's around. This sounds like an x-y problem. Why are you copying dll's around manually vs. using the new csproj SDK project system that computes the transitive closure of dependencies and builds a correct deps.json file, runtime.HostSettings.json, hostpolicy.dll, etc?

[jzabroski]

Basically, the moment you copy dll's, and subvert the nuget/msbuild pack/publish/restore system cycle, you have opted out of everything that should protect you from these linking bugs. (There are a few holes in this system, but if you're subverting the system to start by copy-pasting, I don't think that's something I know how to support, and I don't think anyone else would support that scenario, either.)

[Watchwolf]

I'm sorry for the delay.

I have solved the problem by adding this in the app.config.

I suppose by default Windows was trying to use the dll in C:\Windows which are older, forcing the version solved the problem. (I don't install RazorLight in the executable project, only in the dll dependency).

<runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="System.Threading.Overlapped" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
                <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.0.0" />
            </dependentAssembly>

....... (see the app.config of the project where RazorLight is installed for the complete list.)