DLL 参考仅在 NuGet 在服务器上还原后有效

Question

The title could probably be better, but I can't really come up with something better right now. I'm running into a very strange problem between two of my servers: Server1 and Server2.

Both are Windows 2012 R2/IIS 8.5. Server2 was cloned from Server1 when they were built and have been on the same patch cycle since.

I recently deployed a major code change to Server1 which included the addition of a new project to my solution. The majority of the solution targets .NET Framework 4.6 (with some older bits here and there, but nothing all that important) but the new project targets .NET Standard 1.3 in the properties. This new project has all of its references listed as NuGet packages.

When I compile this entire solution on my local computer and run it, everything works fine. When I deployed it to Server1, however, I began to get the following error any time the code got to a point of referencing the .NET Standard 1.3 project's code.

Could not load file or assembly 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

After trying everything I could think of and find online to resolve this, I eventually was able to get this to run properly by installing MSBuild onto the machine and running the msbuild -t:restore command. Once that was run directly on the server, everything began working.

I thought maybe the deployment process was missing a step, so when I moved all the code over to Server2, I literally moved the entire codebase as-is from Server1 to Server2. I didn't even rely on my own deployment process in fear that it was the cause of the problem.

Sure enough, once running the code on Server2, I saw the exact same error again. At this point the only thing I haven't done on Server2 is run that command and while it may fix it for these dev machines, I'm not particularly eager to install a program like MSBuild onto our production servers to fix this there.

So now my question: Does anyone know if there's something I'm missing here? I admit, I don't wholly understand NuGet so I'm not sure why the msbuild -t:restore command fixes this. Is there some way to replicate what this command does on a file-structure or config level that can be incorporated into a deployment process?

Or... should I just stop worrying about putting MSBuild on a production server and make the on-server build activity part of our regular deployment process moving forward?

Answer 1

PLEASE NOTE: I do not recommend the solution below to anyone who runs into this problem with an application that is meant to exist for a long time with continuous enhancements. The only reason this was a viable option for us was because the main application will be reaching EOL soon and the codebase is not expecting to go through any more major enhancements or integrations before it is decommed completely.

It turns out the solution was to add NuGet to our core application (which never actually used NuGet and only relied on manual references) and then force the core application to downgrade its own System.Net.Http and System.Diagnostics.DiagnosticSource packages to the packages used by the .NET Standard 1.3 targeted project. I wasn't particularly happy about this approach, because it spells quite a bit of issues for us moving forward if we ever need to upgrade anything, but for the purposes of the current project, it'll work.

I'm still a little confused about why using a Web.Config binding never worked for this. It was my understanding that if I used the code below, I wouldn't have to worry about downgrading or upgrading library references, and that .NET would handle the pointing of refence calls based on the binding settings shown.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="System.Net.Http" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
                <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

We even tried using a newVersion of 4.1.1.3 and 4.1.1.0 (with the appropriate DLL changes), but neither of them worked. The potential reality that the application was just completely ignoring this line in the config is a whole other concern for us, but luckily, as the note above states, we won't have to worry about this application much longer.