Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Upgrading FSharp.Core version, assembly reference error while deploying to IIS application

We upgraded FSharp.Core.dll as part of a deployment of a web application on IIS 8 (ASP.NET Web API) and started seeing FSharp.Core FileLoad exceptions immediately following deployment. FSharp.Core.dll version went from 4.3.0.0 to 4.3.1.0.

Our standard automated deployment involves replacing the application folder contents with updated binaries(dlls), global.asax and web.config, thus causing IIS to recycle the apppool. FSharp.Core.dll is bundled as part of the build. Our applications are deployed to a load-balanced environment. Our automated deployment scripts use ‘robocopy’ to purge the application directory (mywebapp, below) and copy the new content in its place.

Typical IIS application folder structure:

mywebapp/bin/fsharp.core.dll
mywebapp/bin/custom-fsharp-lib.dll
mywebapp/bin/custom-csharp-lib.dll
mywebapp/bin/System.Web.Http.dll, etc…
mywebapp/global.asax
mywebapp/web.config

We have observed that if the application is not serving requests during the deployment, then the deployment completes successfully. However, if the application is under load and serving requests during the deployment, the application throws an exception for each subsequent request as soon as the deployment is complete:

Unhandled exception processing POST for https://websiteName/application/endpoint: System.IO.FileLoadException Could not load file or assembly 'FSharp.Core, Version=4.3.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) - at WebAppFunction.Execute…..(etc)

After seeing this exception we checked the application binaries and saw that FSharp.Core.dll version was 4.3.1.0 (i.e. the upgraded version had deployed correctly). It appears that if serving traffic during deployment, the newly deployed application cannot find the correct FSharp.Core.dll version, even though it is present in the application bin folder. It appears that the application may still have some handle on the old FSharp.Core.dll version.

This problem persists following server reboot, IISReset or recycling the IIS apppool. Our solution was to rollback the deployment to the previous build (with FSharp.Core.dll v4.3.0.0) after which the application recovered. We then deployed the new build (with FSharp.Core.dll v4.3.1.0) to each server individually while pulled out of the load balancer with the apppool stopped, thus ensuring no load during deployment, and the new build deployed successfully.

We have never before observed this behaviour during deployments of web applications, regardless of whether assembly versions are being upgraded or not. Has anybody else ever come across this problem with FSharp.Core.dll, and if so, can the behaviour be explained?

like image 261
tomoc21 Avatar asked Oct 19 '17 09:10

tomoc21


1 Answers

You might need to add the assembly redirect in your web.config:

 <dependentAssembly>
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.3.1.0" />
 </dependentAssembly>

That error you have described has occurred to us before (although not during the exact time of deployment) and the above is what always solves it.

like image 168
Juan Tarquino Avatar answered Nov 13 '22 20:11

Juan Tarquino