I am setting up my first Windows IoT Core background application that is running on a Raspberry Pi, but I am running into a problem with conflicting assembly versions and I have been unable to resolve them.
Specifically, I am getting an error message that states:
No way to resolve conflict between "System.Data.Common, Version=4.2.1.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Data.Common,
Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing
"System.Data.Common, Version=4.2.1.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" arbitrarily.
Upon closer inspection, there are two versions of the System.Data.Common.dll that my application is referencing.
The first is coming from the installed package Microsoft.NETCore.UniversalWindowsPlatform (v 6.2.8). The assembly version of System.Data.Common here is 4.2.1.0 (which is the version I want to use):
Assembly System.Data.Common version 4.2.1.0
C:\Users\mikel\.nuget\packages\Microsoft.NETCore.UniversalWindowsPlatform\6.2.8\ref\uap10.0.15138\System.Data.Common.dll
The second is apparently being included as a dependency with the .netstandard:
Assembly System.Data.Common version 4.1.0.0
C:\Users\mikel\.nuget\packages\System.Data.Common\4.3.0\ref\netstandard1.2\System.Data.Common.dll
I am having a little harder time pinpointing exactly what is forcing NuGet to download and install the second package. Perhaps one of my other packages that I need is referencing it as a dependency (not sure).
Either way, I would like to setup assembly binding remapping so that any attempt to reference 4.1.0.0 will redirect and use 4.2.1.0.
When I do a build of my project, I get this warning:
1> Consider app.config remapping of assembly "System.Data.Common, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.0.0"
[C:\Users\mikel\.nuget\packages\System.Data.Common\4.3.0\ref\netstandard1.2\System.Data.Common.dll]
to Version "4.2.1.0"
[C:\Users\mikel\.nuget\packages\Microsoft.NETCore.UniversalWindowsPlatform\6.2.8\ref\uap10.0.15138\System.Data.Common.dll]
to solve conflict and get rid of warning.
However from what I have read, Universal Windows Projects do not support the use of app.config files. At any rate though, I added an app.config file to the root of my project, set the build action to Embedded Resource, selected Copy Always and put this in the file (to no affect):
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Data.Common" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="4.1.0.0" newVersion="4.2.1.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
I have also tried setting the NuGet project management format to PackageReference and added <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to each PropertyGroup in my .csproj file. This did not have any impact.
My Universal Windows project targets are as follows:
Target version: Windows 10 Fall Creators Update (10.0; Build 16299)
Minimum Version: Windows 10 Fall Creators Update (10.0; Build 16299)
I should also state that I want to use the 4.2.1.0 version of the assembly, as 4.1.0.0 is missing a few things I need to implement the wrapper I am using around SQLite. My preference is to not have to re-write those wrappers.
At this point I am very confused as to how to resolve this conflict. How do I enable binding redirects to resolve this error?
Any help would be greatly appreciated.
When i build locally it works, but my VSTS hosted 2017 instance build fails with the following message:
[error]apps\Ascend.Identity\AccountController.cs(126,17): Error CS0012: The type 'HttpRequestMessage' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Locally, there is also a yellow triangle in the reference list.
but it still builds
and the reference is there in csproj
and the package is restored from nuget (packages.config)
<package id="System.Net.Http" version="4.3.3" targetFramework="net472" />
In your local, try the steps below:
Delete packages folder in your source directory.
Remove System.Net.Http reference.
Right click References, select Manage Nuget Packages, browser and install package System.Net.Http.
Build your project and check the result. Make sure there is no yellow triangle in the reference list.
Check in the changes and queue a build.
Getting started with creating NuGet packages for various common libraries, that were up to now typically added as a project to a solution.
Using TFS 2017 to build and deploy the NuGet packages to the Package Manager built into TFS 2017.
I have an issue with dependencies and don't fully understand how to resolve it. It's also a little complicated to detail; so here goes.
I have built a class library that has a NuGet package installed - The package is SharpRaven 2.2.0
SharpRaven has a dependency on NewtonSoft.Json >= 6.0.8
This results in Newtonsoft.Json being added to my class library. By default NewtonSoft.Json 6.0.8 is installed.
I then package up my class library as a NuGet package - Called it TestNuGet
TFS is building the nuget by using the .csproj file and not the nuspec
When I use this new package in projects I see there are dependencies for SharpRaven and Newtonsoft (if neither of those are currently installed in the project).
My problem starts with Newtonsoft.Json.
Take the following projects:
Solution A and B
- Already has Newtonsoft 9.0.1.
- Install TestNuGet, so SharpRaven is also added
- Project is fine, no errors when using TestNuGet
Solution C
- Already has Newtonsoft 9.0.1.
- Install TestNuGet, so SharpRaven is also added
- Errors when calling TestNuGet; error below:
Solution C
- Remove Newtonsoft 9.0.1
- Install TestNuGet, SharpRaven and Newtonsoft 6.0.8 installed
- Project is fine. No errors
- Update Newtonsoft
- Get Errors again as before
If i update NewtonSoft to 9.0.1 in TestNuget and rebuild it I get exactly the same issues above.
There are no projects within Solution C that are referencing anything other than 9.0.1.
It seems to me that when adding a NuGet package NuGet looks at all of the packages within and uses those dependencies, ignoring what is already added to the TestNuget.
So the question, i think - Is there a way to instruct nuget to use the newtonsoft version i added to TestNuget and to not try and meet the dependency sharpraven is calling for? Something to add to the Packages.config perhaps?
Would I be better using a nuspec file? is there more that can be set in this to control how the package is built?
Or is there something I'm missing in my usage of these packages.
Error being thrown when trying to use the package is:
Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Binding Redirect from the web.config of the solution that will not run looks as this:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0" />
</dependentAssembly>
I also tried adjusting the redirect to encapsulate 9.0.1
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-9.0.1.0" newVersion="9.0.1.0" />
</dependentAssembly>
The issue here is that an assembly has a reference to a version 6 of NewtonSoft.Json which is not found at runtime since only a higher version is present.
This is usually worked around with binding redirects. NuGet should automatically generate the necessary binding redirects into runnable (exe, web apps) projects using packages.config when installing packages.
For PackageReference based projects it is sometimes (test projects, plugin-library, …) required to also tell msbuild to automatically generate the needed binding redirects based on the resolved assemblies. This can be done by adding this to the csproj file:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
However this does not protect against actual breaking changes that could have occurred in new major versions of a library.
Also note that these binding redirects may be overwritten by the binding redirects of other applications re-using the built assembly (parent projects, plugin-system etc).
Could not load file or assembly 'Microsoft.VisualStudio.Web.PageInspector.Loader, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The module was expected to contain an assembly manifest.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\11.0\WebDev.WebServer40.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = TTLWIN2K\miralp
LOG: DisplayName = Microsoft.VisualStudio.Web.PageInspector.Loader, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/SVN/temp/components/src/MasterpassProxy/src/Webservice/
LOG: Initial PrivatePath = C:\SVN\temp\components\src\MasterpassProxy\src\Webservice\bin
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\SVN\temp\components\src\MasterpassProxy\src\Webservice\web.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Microsoft.VisualStudio.Web.PageInspector.Loader, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
I just ran into the same problem, and the culprit was my uninstalling of Visual Studio Express 2012. It's possible that it might be any version of Visual Studio, as comments on this answer are indicating the issue still happens with Visual Studio 2019. My overall order of operations was:
Installed Visual Studio Express 2012 (long time ago)
Used Visual Studio Express 2012 happily for many months
Installed Visual Studio 2013 Premium
Used Visual Studio 2013 Premium happily for weeks
Uninstalled Visual Studio Express 2012
ERROR
I'm not 100% certain on the cause of it, or what combinations of Visual Studio versions would exhibit this behavior. But the solution for me was to edit the root web.config files in the framework directories:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
(For different framework versions you may have different folders.)
And remove the nodes:
<remove assembly="Microsoft.VisualStudio.Web.PageInspector.Loader, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<add assembly="Microsoft.VisualStudio.Web.PageInspector.Loader, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Be careful not to remove any opening/closing parent nodes which are also on the same line(s) as these.
This resolved the issue for me.
No need to remove those lines
Just close and reopen the Visual studio with Admin privileges.
I got the same problem but not on my development machine but on hosting server.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
I was able to fix it by adding below code to my web.config
<compilation targetFramework="4.5">
<assemblies>
<remove assembly="Microsoft.VisualStudio.Web.PageInspector.Loader,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
</compilation>
or by removing reference to this assembly from web.config files in framework directories.
I never installed VS there and i never had PageInspector installed there. Any idea why those configs reference them?
Update: fixed in Visual Studio 2019 Version 16.0.3 according to this page.
If this happens after upgrading to Visual Studio 2019 RC, the following workaround helped:
Find the download cache directory
Use Explorer or better to find the AspNetDiagnosticPack.msi within this directory.
Run (double-click) the AspNetDiagnosticPack.msi file (this will force the installation of this MSI).
Workaround found here
I had this issue after installing Visual Studio 2019 (whilst 2017 was still installed). It's caused by a missing component - AspNetDiagnosticPack.msi - that fails to install a required package into C:\ProgramData\Microsoft\VisualStudio\Packages\
The solution that worked for me was this:
Close Visual Studio
Download the package from:
https://download.visualstudio.microsoft.com/download/pr/e13d544f-5a3c-4bb3-9a7c-1e56b1f90e10/f8e5888ff01a7009ef8c2ef16aa02ab9/aspnetdiagnosticpack.msi
Run the installer and install.
This should fix it.
More information can be be found: https://developercommunity.visualstudio.com/content/problem/398640/could-not-load-file-or-assembly-microsoftvisualstu-7.html
For those who might end up here, try removing the following line in the Web.Config file of your Project while debugging
<identity impersonate="true" userName="blah" password="blah">
It took time until I finally came across the following thread:
Could not load file or assembly or one of its dependencies. Access is denied. The issue is random, but after it happens once, it continues
I've ran into this error while trying to run an ASP.NET project in VS2013 after having uninstalled a VS2015 preview. Repairing the VS2013 installation seems to have solved the problem.
I got this answer is perfect for me
No need to remove those lines
Just close and reopen the Visual studio with Admin privileges.
I removed the dll from gac and it started working. I am not sure where those dlls came from. If you have 2 or more versions of visual studio, reinstall the last version.
Try updating your Microsoft.ApplicationInsights nuget package. This also installs other dependencies. I ran into this problem when I had to change my Target Framework.
Tools > NuGet Package Manager > Manage NuGet Packages for
Solution...
search for "applicationinsights"
or run
Install-Package Microsoft.ApplicationInsights
Had a similar problem (another assembly) and for me it was a missing line in the web.config on the machine. A line that I think lets the web server load (any?) dll.
I had to add "*" to the compilation-assemblies list in the web.config:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
Like this
<compilation>
<assemblies>
...
<add assembly="*" />
</assemblies>
</compilation>
To find it I had to compare the file with one from a working server.
So it seems to me that It really is a load failure, but to determine why it fails, we need to be Sherlook H..
Normally I use a tool like ProcessMonitor to find out why I get a Load Failure, but this time, of course, it gave me no useful output.. IIS never tried to load the assembly!
If you don't see web.config in both of paths:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
file "Web" is in "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\" what I really want to show you, It's Web.config, you should open it with: notepad++... and remove:
//<remove assembly="Microsoft.VisualStudio.Web.PageInspector.Loader,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />"
I finish my problem with them.
Our project had (incorrectly) reference to the PageInspector.Loader.dll in the GAC for a long time:
<ItemGroup>
<Reference Include="Microsoft.VisualStudio.Web.PageInspector.Loader">
<HintPath>..\..\..\..\..\..\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.Web.PageInspector.Loader\v4.0_1.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Web.PageInspector.Loader.dll</HintPath>
</Reference>
</ItemGroup>
It worked for some time, but recently deployment to Azure caused the error "Can not find compilation library location for package Microsoft.VisualStudio.Web.PageInspector.Loader".
We found and deleted the reference from .csproj file and the problem was fixed.
I opened today a 10 year old project and encounter this issue in VS 2019 (16.9.1), in my case it was
<trust level="Medium"/>
removing above line from the web.config or setting <trust level="Full"/> solved this issue.
I know this is an old one but I ran into this error when debugging with Visual Studio 2010 (I also run 2013, 2017 and 2019 on the same machine...I have a few legacy apps :oP). In my case, I debug using local IIS as webserver (not express) and I ended up having to recycle the websites Application Pool which did the trick to clear the error (after restarting 2010).
Dave
it solved the problem on at my end by applying the approved solution in this thread.
modifying the following two files, and removing Microsoft.VisualStudio.Web.PageInspector.Loader resolved the issue.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
In one of my websites, I have added a reference to IBM.DATA.DB2.dll (which is in GAC, version 9.0.0.2) as shown in the text below from web.config:-
But when I build my project, it tries to point it to a different version of the dll, as shown below in the error mrssage:-
"Could not load file or assembly 'IBM.Data.DB2, Version=9.7.4.4, Culture=neutral, PublicKeyToken=7c307b91aa13d208' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
I checked in GAC (C://Windows/Assemblies) and I cannot see any reference to version 9.7.4.4 there. I would appreciate any help I can get on this.
Thanks,
Abhi.
I was able to solve my problem using fuslogvw.exe. From the log I found out that there was a version redirect in the machine.config file in path "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config", which was redirecting the reference 9.0.0.2 to 9.7.4.4.
<dependentAssembly>
<assemblyIdentity name="IBM.Data.DB2" publicKeyToken="7c307b91aa13d208" culture="" />
<bindingRedirect oldVersion="8.0.0.0-9.0.0.4" newVersion="9.7.7.4" />
</dependentAssembly>
Changing 9.7.4.4 to 9.0.0.2 solved the probem.
Thanks,
Abhi.
Do you have the "specific version" property set to true? Does it need to be that version? If you can link to any version then set that property to false. This will allow your project to link to any version of the assembly.
It could also be a dependency of a one of your other dependencies that's pulling in this particular version.
If you do need the older version and the newer is being pulled in by some other reference then you've got a different problem. This can only be solved by upgrading your application or finding a version of the 3rd assembly that references the older version too.
Double check to see if you've got the latest version (it doesn't look like it if you have version 9.0.0.2 and Visual Studio is looking for version 9.7.4.4). Download and install that version.