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?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With