After upgrading our project to use the Azure SDK 2.5, I get the following runtime exception when deployed to Azure (web role):
Could not load file or assembly
'Microsoft.WindowsAzure.ServiceRuntime, Version=2.4.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its
dependencies. The system cannot find the file specified.
One of the referenced packages from NuGet is still referencing ServiceRuntime 2.4.0.0. From what I understand, all I need to do to fix this is create a bindingRedirect in our web.config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.WindowsAzure.ServiceRuntime" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-2.5.0.0" newVersion="2.5.0.0"/>
</dependentAssembly>
Unfortunately this doesn't work. The exception persists. Can anyone provide guidance?
After upgrading to SDK 2.5 myself i had the same problem you have now. I went trough all of the projects in the solution, and checked all of the references to Microsoft.WindowsAzure.ServiceRuntime. Remove them, and add them again using the Add Reference option. Select the assembly again, however make sure it is the 2.5.0.0 version. Rebuild and redeploy. Things should work again now.
For me, setting the Copy Local property to True for the referenced assembly fixed this.
In Solution Explorer find your project's reference to the library.
Right click and choose Properties
In the Properties window set Copy Local to True
Related
Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have to keep a backup copy of the dll and replace it again for the site to come up. How to fix the issue
I noticed the web.config for build 21.106.0024 (under Acumatica ERP 2021 R1 21.106.0024\Acumatica ERP\Files) shows the following:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
But the installed instance of Acumatica for the same build version shows:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.0.0.0" />
</dependentAssembly>
So I commented out the 1.0 version and put in the 5.0 version and it worked:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<!--<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.0.0.0" />-->
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
That workaround works for local development without issues but there is a bug with the installer I believe. Strange that the web.config looks correct from the installed files but not when a new instance is created.
EDIT:
The root cause of the error is likely that you have a reference to Microsoft DLL in your Acumatica DLL extension project.
And you also likely have a Website in the same solution which adds the extension projection reference. To check this, right click Website go to Property Pages and check in References, with Add Reference button in Project reference section.
This setup copies references automatically when you compile. You can remove copying of some references with CopyLocal=False property. However this doesn't appear to apply for Microsoft.Bcl.AsynInterfaces. Maybe you used Bind feature in Acumatica Customization page to set-up that automatic copying or created the extension C# project from the Acumatica Customization page.
In case the website is broken by a DLL file in Acumatica Bin directory. To restore original DLL files use Acumatica ERP Wizard (same version as corrupted website) and select 'Perform Application Maintenance'
Then select the corrupted site and run 'Update Only Website':
Check the date of the DLL which was previously corrupted:
Then identify the process which replaces the original DLL file shipped with Acumatica by a incompatible version and remove it. I suspect you are compiling a C# project in Visual Studio. And this project is configured to deploy files directly into Acumatica Bin directory. After compilation the date of the corrupted DLL file would change in Acumatica Bin folder.
Try removing the website from your solution if it's there and has a reference to your C# Acumatica extension project:
If there's a Post Build script (project properties-> build) that replace Acumatica DLL remove it.
Then compile to any directory that isn't Acumatica Bin folder. This is configured in C# project properties build section.
After compilation copy only the required compiled files which does not include 'Microsoft.Bcl.AsyncInterfaces.dll' to Acumatica Bin folder.
This copy operation can be done manually, with a batch file, with a post build script etc... The important thing is that it shouldn't copy DLL files which are already shipped with Acumatica.
One other possible solution is to select the same .Net Framework version that the Acumatica site uses in your own extension DLL. That way when compiling you would be replacing Microsoft DLL with the same version.
I got past this by referencing the Microsoft.Bcl.AsyncInterfaces DLL in my DLL project. The DLL project that I've made is set to put the DLL directly into the bin directory of the Acumatica web site. This works when I have the Acumatica website included in the Visual Studio project. .Net 4.8, Acumatica 2021 R2, Visual Studio 2019
The Microsoft.Bcl.AsyncInterfaces.dll that will appease Acumatica is in the C:\Program Files\Acumatica ERP\Files\Bin folder.
I have a project that has some dlls referring to Microsoft Unity 1.1 and my code is using Unity2.
I tried the solution described here. However, I added the version 2.0 dll as reference in the project from visual studio and in the web.config file in the <codebase ...> tag's href, i pointed to the physical file locations correctly. During runtime, I am still getting the error as could not load assembly Unity 1.1.
Any idea on how to fix this issue is highly appreciated.
Config used is :
<dependentAssembly>
<assemblyIdentity name="Microsoft.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
<codeBase version="1.1.0.0" href="E:\Saravanan Doraiswamy\App\bin\v1.1\Microsoft.Practices.Unity.Configuration.dll" />
<codeBase version="2.0.414.0" href="E:\Saravanan Doraiswamy\App\bin\v2.1\Microsoft.Practices.Unity.Configuration.dll" />
</dependentAssembly>
This kind of redirection is not possible. Hence this post is closed.
We are using Azure SDK 1.8 and it working fine on local. we are using TFS hosted build controller to deploy on azure.
It was working fine before but sudden today we getting this error although we have no azure sdk dll version changed but online we get this error. Is this because of TFS build controller upgraded with new sdk? and strange thing this build is showing successful every time.
In TFS build service I found this strange stuff why it is referencing to v2.0 sdk.
Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
If everything else fails, and the correct DLL is deployed in the bin, try adding an assembly binding redirect in the web.config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.WindowsAzure.ServiceRuntime" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="2.0.0.0" newVersion="1.8.0.0" />
</dependentAssembly>
Change the binding version numbers as needed.
This happened to me because I updated the references from 2.0 to 2.2 but I still had the version 2.0 dll referenced in my web config:
<system.diagnostics>
<trace autoflush="true">
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
<filter type="" />
</add>
</listeners>
</trace>
This happened to me when i upgraded to 2.3.0.0.
To fix it i went in to references -> right clicked the dll -> clicked Properties -> set copy local to true.
I believe I've hit the exact same issue as you (if I remember correctly). The 1.8 SDK contained a reference to the old StorageClient dll. Try adding a reference in your project to:
Microsoft.WindowsAzure.StorageClient version 1.7.0.0
Let me know if this helps!
I had this issue as well recently.
Based on my research this can be caused by a multitude of reasons.
The best way to resolve this is to first diagnose it. To get a better diagnosis, enable all CLR exceptions from your Exceptions window. Now your Visual Studio will break on any kind of exception that is thrown. From here you should be able to see the inner details of the exception.
So I updated the Azure SDK to the 2.0 version yesterday and upgraded my projects. Everything worked fine in local, so I published to Azure. Surprise: the worker role didn't start because of the following exception
Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=1.0.0.0
Something similar happened when I updated to 1.8 but I don't remember the exact solution. I've tried to remove and readd the assembly, referencing to the DLL in my system, updating the NuGet packages... everything yields the same result.
Anyone has any solution to this?
Thanks!
I've not done the migration to 2.0 yet but it is on the cards.
When I last upgraded 1.7 => 1.8 I had to add the following entry to my web.config because of other external projects still referencing the old runtime
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.WindowsAzure.ServiceRuntime" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.7.0.0-1.8.0.0" newVersion="1.8.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
If you have checked your own projects and they don't refer to the old version it could be that some nuget package still contains references to the old versions.
In my case the problem was the Azure Storage Client library, which was referring to the older version of configuration package which was then referring to these version 1.8 DLLs.
Don't know what would be the best way to debug these, but the Nuget package dependency visualizer might help: Tools -> Library Package Manager -> Package Visualize
(looks like you can only create the visualizations in Visual Studio ultimate)
We have webparts that use dll's which are in the GAC.
In the *.webpart file the dll is refered to in the type name tag. Here it is spesified with the version number.
Is it possible to get the web part to use a different version of the dll, without having to redeploy the webpart?
We have many pages that use the webpart. If we were to redeploy the webpart would we need to update all pages that used the webpart?
This question is very similar
SO - SharePoint features: How can I use wildcard assembly versioning?
Whilst you can use a Publisher Policy file to redirect assembly versions this is a bit of a pain to administer.
Perhaps a better way is to reserve this for major version (e.g. SharePoint v11 to v12 or .net core libraries) and for minor versions (e.g. service packs etc) use the same AssemblyVersion but a different file Version. This is exactly what Microsoft themselves use and recommend.
KB556041 - How to use Assembly Version and Assembly File Version
Suppose you are building a framework assembly for your project which is used by lot of developers while building the application assemblies. If you release new version of assembly very frequently ... and if assemblies are strong named, Developers will have to change the reference every time you release new assembly ... A better option in such closed group and volatile scenarios would be to fix the 'Assembly Version' and change only the 'Assembly File Version'.
You can tryout assembly binding in the web.config file
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.SharePoint" publicKeyToken="71e9bce111e9429c" culture="neutral" />
<bindingRedirect oldVersion="11.0.0.0" newVersion="12.0.0.0" />
</dependentAssembly>