The exception when running as the console application as Azure webjob:
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Azure.Core, Version=1.0.2.0, Culture=neutral, PublicKeyToken=92742159e12e44c8' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Locally this works and runs.
Referencing:
Azure.Identity version 1.3.0 which has a dependency to Azure.Core version >= 1.6.0
Azure.Security.KeyVaults.Secrets version 4.1.0 which has a dependency to Azure.Core version >= 1.0.2
So of course based on these nuspec specifications it should resolve to Azure.Core 1.6.0. Which it locally does and runs without a problem.
Yet when I deploy this using VS publish profile to our cloud as Azure Webjobs and run the application I get the exception mentioned above. (of course the file version deployed is the same as local, version 1.6.0)
I know I can fix this with an assemblybinding. Stating that version 0.0.0.0 to 1.6.0.0 should resolve to version 1.6.0.0.
But I find this very frustrating because it imposes manual labor and keeps us from updating packages whenever a newer version arrives because then we also have to remind ourselves to update the assemblybindings.
I feel like there is a better solution, or we are doing something wrong. But I simply do not know where to begin searching for a solution. I hope to get some insights from you guys!
PS:
This phenomenon is driving me nuts because we face similar issues when using packages:
Unity
Unity.Interception
Because they both depend on Unity.Container. Forcing us to either use assemblybinding to resolve this issue, or only use versions which depend on the same packages
Try doing the following steps because the approach you are taking is correct:
Uninstall both Azure.Identity and Azure.Security.KeyVaults.Secrets nuget packages.
Remove all the associated Assembly Bindings.
Delete bin and obj folders in your project folder.
Install Azure.Core version >= 1.6.0 and rebuild the solution.
Deploy the solution.
These should work ideally. I think that there are some stale dependencies which are getting deployed. You can also try deploying through pipelines, if not already doing.
Related
I'm assisting a colleague who's working on a new WPF app. He's using .NET Framework 4.5.2. We generate a ClickOnce deployment for users to run. I can install the app using the ClickOnce installer, but users can't. They're getting this error:
I looked up Microsoft.VisualStudio.Data.Core on NuGet. I did that because when I brought up package manager I couldn't find it. So, I looked for everything that starts with "Microsoft.VisualStudio". This is what I found:
I can't find a Microsoft.VisualStudio.Data.Core.dll in the project. So, I figure Microsoft.VisualStudio.Data.Core must be in one of those other assemblies. Of course, it might not be in any assembly that starts with "Microsoft.VisualStudio". But clearly, since the ClickOnce deployment is trying to install it in the GAC, it's in the solution somewhere. Is Microsoft.VisualStudio.Data.Core a part of some other package? If so, what other package? Looking at NuGet, I've not been able to find out what might be using it.
Heyya,
We recently went through with upgrading all our projects from .NET Core 3.0 to 3.1, as well as most of the associated NuGet packages. The projects themselves are hosted as services and function-apps on portal.azure.com, and is transferred via a Bitbucket repository (pushed up from development, pulled down automagically by Azure).
This worked great for two out of three services, but the last one have proved to be difficult. The service itself is working fine, and it's (seemingly) doing what it should when testing it via localhost, but the associated Function-app is throwing "System.Private.CoreLib: Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=5.0.0.0>'. The system cannot find the file specified." at us.
After some investigating, it would seem there was no Microsoft.Extensions.Logging.Abstractions package installed at all according to our NuGet Manager, but it was still being used by ILogger in the code (explanations for this one are very welcome). Nevertheless, we forced a downgrade to Microsoft.Extensions.Logging.Abstractions version 3.1.10, tested the application via localhost before deploying it, and this time we got the exact same error message, thrown in Program.cs. Guessing this wouldn't make things better even if we tried pushing it up.
The target version of the function-app is ~3 (only ~3 and ~1 is available, not ~2), and it has worked prior to this. The AzureFunctionVersion (available in the project's configuration files) is v3. Re-creating the function-app on the Portal does not seem to have made any difference.
This usually happens when a Nuget package version is used by different nuget packages internally and is incompatible for at least one of them.
It means, there is a Nuget package in your project which requires Microsoft.Extensions.Logging.Abstractions version 5.0.0.0, but Azure Function latest version as of now installs version 2.1.1.
So, the solution is to upgrade Microsoft.Extensions.Logging.Abstractions version to 5.0.0.0 as SDK supports > 2.1.1:
OR
downgrade the dependent nuget package so that it uses 2.1.1 (or whichever version is installed in your project)
Background: I developed a .NET Standard 2.0 Nuget package (local) for a class library with a dependency on Microsoft.Extensions.Configuration, Version=2.1.1.0. It passed unit tests and ran fine when invoked from a .NET Core 2.0 console app. However, when I added my package to an Azure Function project it caused an exception to be thrown whenever I attempted to run the azure function from the VS2017 debugger.
System.Private.CoreLib: Could not load file or assembly 'Microsoft.Extensions.Configuration, Version=2.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Question: How can I fix the problem?
Copied from OPs question:
Answer: The problem goes away when I downgraded to Microsoft.Extensions.Configuration, Version=2.0.0. in my package, republished it and then reinstalled it in my Azure Function. This seems to be another example of the packages-dependency-crisis. The Nuget package manager should have caught any dependency problems with v2.1.1 when my package was added to the Azure Function project, but it didn't so it only became apparent at runtime. This is sub-optimal.
I provide the above information in the hope that others will not waste a day tracking down the same issue. It also raises the question as to how you decide what version of a package to add. Clearly in the case of Microsoft.Extensions.Configuration adding the latest stable version isn't always the best idea.
I know this is an older question but ran into the same issue downgrading a project from 2.2 to 2.1. And removed the user of ASPNetCore.All to ASPNetcore.App. This showed me how many packages we really had to depend on, as well as this issue eventually came up. My error came from the Usersecrets retrieval. Since I was missing: Microsoft.Extensions.Configuration.UserSecrets
hope this can help someone like me who was stuck on this. Should have known it would be a missing package.
Solution below
I'm trying to implement PayPal payment in an ASP.NET website, but when I run it on Azure, it tells me the assembly being referred to by RestApiSDK 0.1.1.0 is wrong. Local it all works.
Could not load file or assembly 'PayPalCoreSDK, Version=1.5.2.0, Culture=neutral, PublicKeyToken=5b4afc1ccaef40fb' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I checked with .NET Reflector and the assembly being referred to is indeed 1.5.2.0, though the latest version in NuGet Packages is 1.6.0.0. I also uninstalled both packages and re-installed them, but no luck.
So, I have two questions:
Why does this work on my localhost?
How do I fix this to work on Azure Websites as well?
Edit: As #JasonZ suggested, I installed a new version of the PayPal SDK for .NET and that worked. Thanks!
My first thought would be 32 bit local machine vs 64 bit azure?
If that's not the case, I would try manually adding them to the GAC via a webjob as stated here:
http://blogs.infosupport.com/adding-assemblies-to-the-gac-in-windows-azure/
When you "uninstall and Reinstall" do you see them in the GAC on your azure vm?
=Devon
Answer by #JasonZ: The PayPal .NET SDK has since replaced the RestApiSDK library and removes the dependency on PayPalCoreSDK.
Upgrade the nuget package
PM> install-package PayPalCoreSDK -version 1.7.0
(To upgrade the package using visual studio [Top Menu] -> Tools -> NuGet Package Manager -> Package Manager Console)
Please follow the following link for more information. https://www.nuget.org/packages/PayPalCoreSDK/
Maybe Relevant information: I have a web application I built with .net 4.5. I wanted to deploy to Azure's Web Sites but it only supports .net 4.0 so I downgraded the project to .net 4.0.
It still works when run locally.
When I publish to Azure, i get this error:
Could not load file or assembly 'System.Net.Http' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have tried removing the Web API with nuget and readding it, as another question on SO suggested but I still have the same problem.
I have tried close/open VS, and clean/build.
I solved a similar problem (System.Web.Http and System.Net.Http.Formatting) error by removing the reference to problem reference (which was pointed to my .Net installation folder) and replacing it with the reference file in my packages folder that was installed by the Microsoft.AspNet.WebApi NuGet package.
I had the same problem. However, updating assembly versions, copy local, and specific version settings alone did not solve my problem. In my application configuration I deploy a web and a worker role to a cloud service. After creating the service, on the configure tab I set the Operating System to Windows Server 2012 R2 to get the support for .Net Framework 4.5.1. But the error still occured.
Upon further research, I found that the *.cscfg file for my cloud service overrode the portal setting with an obscure osFamily setting of "3". When I started my project it was on MVC3 and did not yet have WebAPI and framework 4.5.1. osFamily 3 was the latest at the time.
In my latest deployment I had upgraded my site to 4.5.1 framework and MVC5. I verified it worked locally on my development machine. But it didn't work after deployment with the error referencing System.Net.Http.Formatting version 4.0.0.0 not being found. I later saw the deployment log that showed the source error
"The feature named NetFx451 that is required by the uploaded package is not available in the OS * chosen for the deployment."
Here is the blog article that led me to the solution to change the osFamily setting to 4. Then my site worked after a fresh deployment.
http://tech.trailmax.info/2014/02/azure-deployment-the-feature-named-netfx451-that-is-required-by-the-uploaded-package-is-not-available-in-the-os-chosen-for-the-deployment/
System.NET.HTTP.dll only depends on System.dll, System.Core.dll and mscorlib.dll.
Make sure you have this DLL (System.NET.HTTP.dll) in your deployment package (you can do RDP connect and check deployment folder). Play with "Copy to Local" property of reference, or include this dll in your project on root level and set type "content" in properties.
Also System.Net.Http.dll is also supported for .NET 2.0 as i see - that might cause an issue. So additionally to above try to set property of reference "Specific version" = true
Azure Now supports .Net 4.5 on the configuration tab you can select .Net framework version V3.5 or V4.5 I have several MVC Web Apps with Numerous supporting DLLs all all compiled in V4.5. What Azure does not support is V 4.5.1 (from the VS 2013 RC release).
I had the same issue with an asp.net application with some Web Jobs which deployed to the same Azure App Service. It was solved by referencing the same System.Net.Http (nuget package) from all projects.
If all of the options you did didn't work, please try restarting (close / open as "admin") your visual studio, then clean / rebuild. This has fixed my problem.
Though this is only for my local machine, haven't tried yet with other environments like in azure or in any server.
I had the same experience with missing System.Net.Http issue.