There are two projects in solution.One is API and other is for OrganizationServiceCall.
I have installed one nuget package called Microsoft.CrmSdk.XrmTooling.CoreAssembly it has installed default package Microsoft.IdentityModel.Clients.ActiveDirectory, Version=3.19.8.1660 with it.
But I have installed Microsoft.IdentityModel.Clients.ActiveDirectory, Version=2.22 in other project.While Call API I got this error :
{"Could not load file or assembly 'Microsoft.IdentityModel.Clients.ActiveDirectory, Version=3.19.8.16603"}.
How can i done work while same Solution have different version of nuget pacakge conflicts?
Some work arounds that you can try
If second project api has no issue with latest version ,Also try Upgrading it to Microsoft.IdentityModel.Clients.ActiveDirectory version 3.19.8
Or Update all NuGet packages to the latest if its ok.
Or one may need to edit your csproj manually to add that specific version in thart particular project.
Use a single assembly version with Binding Redirect in config file
i) NuGet won't handle the references in the program. It just
manages packages. We may have to force our project to use the
loaded assembly with binding redirect.
ii) This specifies which version of assembly to use instead of old
version. It is not necessarily requires later version be specified
in newVersion, earlier version can be provided as well in
newVersion. If there are different versions, try make them uniform
across projects. Issue should be solved.
Here oneproject is referred to ActiveDirectory versions > 3.0, other
project needs less version that that. Adding a binding redirect to
the app.config can help fix problem in some cases. But before that
please make sure that particular dlls are present in the
configuration file.
Note that the runtime section is the one to be added.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
...
<runtime>
....
<dependentAssembly>
<assemblyIdentity
name="Microsoft.IdentityModel.Clients.ActiveDirectory" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="3.0.0.0-3.19.8.16603" newVersion="3.19.8.16603" />
</dependentAssembly>
.....
</runtime>
</configuration>
And try to explicitly set Specific Version for whatever DLL giving you version issues(Microsoft.IdentityModel.Clients.ActiveDirectory) to False from Visual Studio.
Other way, you can try is to auto-generate binding redirects.
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
References:
azure-sdk-for-media-services :issues(github)
How to resolve “Could not load file or assembly | by Chirag
Rupani | Medium
Troubleshooting NuGet Package Restore in Visual Studio | Microsoft
Docs
I have a QT app which uses a LIB that depends on the 2008 C++ MSVCR90.dll.
When I deploy my app, on some computers the following error is presented:
how can I solve this issue?
someone mentioned to me that if I include a manifest file, this should help. so I prepared the following manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="*" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
in the .pro file I've added the following:
CONFIG += embed_manifest_exe
win32:CONFIG(release, debug|release) {
QMAKE_POST_LINK = $$quote(C:/Program Files (x86)/Windows Kits/8.1/bin/x64/mt.exe -nologo -manifest \"ISHEmulauncher.exe.manifest\" -outputresource:$(DESTDIR_TARGET);1)
}
else:win32:CONFIG(debug, debug|release) {
QMAKE_POST_LINK = $$quote(C:/Program Files (x86)/Windows Kits/8.1/bin/x64mt.exe -nologo -manifest \"ISHEmulauncher.exe.manifest\" -outputresource:$(DESTDIR_TARGET);1)
}
but the manifest that is created is different from the one I prepared and does not include the VS90 dependency and therefor I'm still facing the same error.
any suggestions?
thanks!
Redistributables are pretty annoying to manage. Typically what I have needed to do is to run the MSVC C++ redistributable installer on every deployment machine (as part of the install process) to avoid this error.
The article here may shed some light on the situation:
http://msdn.microsoft.com/en-us/library/ms235299(v=vs.90).aspx
https://qt-project.org/doc/qt-5.0/qtdoc/deployment-windows.html#application-dependencies
I have tried to get the right dll's off my development machine and just deploy it into my application's folder. If you don't mind having another step in your installer of installing the redistributable package, the links below should help.
http://www.microsoft.com/en-us/download/details.aspx?id=29
http://www.microsoft.com/en-us/download/details.aspx?id=26368
Also if your app is compiled for 32 bit, you only need the 32 bit redistributables. If you compiled your app in x64, then you need the 64 bit redistributables.
Related:
Qt5 Deployment on Windows
Hope that helps.
I solved the problem by unchecking the "shadow build" option in QT.
after that, the manifest file I defined wasn't ignored and the library was loaded correctly.
I have a bit of a weird problem.
I developed an app with MVC 4 and the new Web API and it works fine locally.
I installed MVC4 on the server and deployed the app. Now I get the following error:
Could not load file or assembly 'System.Net.Http, 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)
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
Funny enough, the version of System.Net.Http that I locally have either in my package folder or in the ASP.NET MVC 4\Assemblies folder is 1.0.0.0.
I actually removed the reference to System.Net.Http from my project, but I still get the same message. I'm a bit confused about where it gets the 2.0.0.0 reference from and why it would work locally but not on the server.
Looking at the nuget dependencies:
ASP.NET WEb API Core Libraries (Beta) depends on System.Net.Http.Formatting.
And System.Net.Http.Formatting depends on System.Net.Http.
I guess that is where this comes from. But I do have Version 2.0.20126.16343 of this package installed, it's just that the dll inside has version 1.0.0.0
Am I missing something?
UPDATE:
This is a sub-application of another ASP.NET app, but the other one is still based on WebForms. So, something is getting messed up. But if I do a clean under the assembly section in the web.config if does not even find the app itself anymore.
I had the same error while deploying previously converted (from .NET 4.5 to 4.0) web app on IIS 6.0.
In the web.config runtime section I've found
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
which I've changed to
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
Now works like charm.
I had the same problem with deployment my app to appharbor. The problem it does not support .NET 4.5 yet. What I did.
Switched my project to .NET 4.0 profile.
Uninstalled Web API NuGet package.
Installed Web API (Beta) NuGet package again.
Verified that .csproj file contains for ALL referenced assemblies, so it will always take it from Bin folder, instead of GAC.
Mine worked with:
Note the redirect of 1-4 to 2.0
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
In your project's References folder there should be a reference to this dll, and the version should be 2.0.0.0. Make sure this is set to Copy Local = true. And then make sure it finds its way to your server app's bin folder.
This is one of the libraries that is now managed by nuget. So open Nuget and make sure everything is up to date. And in your projects packages directory the file should be here:
\packages\System.Net.Http.2.0.20126.16343\lib\net40
You could also try creating a new MVC4 app and see if the file shows up for that one.
In my case I fixed it in a much easier way, just give a HintPath to the reference to the nuget package:
<Reference Include="System.Data.Entity" />
<Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
</Reference>
<Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
</Reference>
<Reference Include="System.Numerics" />
<Reference Include="System.Security" />
In my case I unintentionally added a dependency to System.Net.Http version 2.1.10.0 through NuGet. I couldn’t get rid of it in the NuGet Package Manager (because other packages seemed to be dependent on it). However those packages aren’t dependent on this particular version.
Here's what I did in order to get rid of it (you can also use the NuGet console instead (using the –force parameter):
Change version of Microsoft.Net.Http in packages.config from 2.1.10.0 to 2.0.0.0
Uninstall BCL Portability Pack in NuGet Package Manager
Manually get rid of dependent libraries (System.Net.Http.* which have version 2.1.10.0)
Add a reference to System.Net.Http 2.0.0.0
In file config I deleted dependent Assembly:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
Now it works fine.
I was facing this issue on a test server (Windows 2008 R2) which was supposedly "ready" for deployment ;)
The hint was that when I checked the versions of System.net between my DEV machine and deployment server, they did not match.
Fixed using the steps below:
Downloaded .NET Framework 4.5 Standalone installer from HERE
Ran the installer on the deployment machine
Post installation of the framework, server wanted a reboot, so did that and volla! We are good to go!!
We are using VS 2013, created a new MVC 4 Web API and had a problem with the system.net.http.dll not being the correct version when built on our TeamCity server but it builds fine on our local developer machines that have VS 2013 installed.
We finally determined the problem.
When creating a new MVC 4 Web API and choosing the framework 4.0 on project creation we found the the correct NuGet package version for DLL was being put in:
..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll
However the .csproj file for this project said the path for this system.net.http.dll file is:
..\packages\Microsoft.Net.Http.2.0.30506.0\lib\net40\System.Net.Http.dll
So when the build is attempted is fails on this path difference but is finding the correct framework version of the file elsewhere on the developer machine but not on our TeamCity build server.
So far this is the only difference we found. Changing the path in the .csproj file and building on local Dev machine with VS2013 still works find.
Checking that into version control and having our TeamCity build server (without VS 2013 installed locally) now finds the correct version of the .dll in its NuGet package folder for the solution and builds successfully rather than searching for another version of system.net.http.dll and finding a newer version which doesn't match the framework hence causing build failures.
Not sure if this helps.
Check your project file path for the DLL and make sure it matches your package folder path for the DLL.
Just simplifying the other answers for what worked for me.
I went to the NuGet manager, uninstalled the related packages (In my case, "Microsoft ASP.NET Web API 2.1 Client Libraries" and "Json.NET") and reinstalled them. Just took a few clicks.
Close the project, Open it again. Then, Clean Solution + Build. Works for me
For version 2.2.15.0, I did this:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>
I had this exact same issue! I took a look at my Warnings tab in VS and noticed that one of my nuget packages was INDIRECTLY referencing .NETFramework Version 4.5.0.0. I had to uninstall this package and then reinstall the 4.0 version but be sure to specify the package versions that support 4.0(it'll default back to 4.5 i believe if you don't specify when installing the package). Hope this helps!
We had this happening on a server after deployment. It was caused either by:
A) Old files in the bin folder still hanging around that ought to have been deleted
or
B) Not having read access to the folder for the Application Pool Identity user.
In other words, for us this was resolved by fixing permissions on the folders for the site and wiping out the bin folder and redeploying.
I had the same issue with Gembox.spreadsheet.dll version 31.
" Could not load file or assembly 'GemBox.Spreadsheet,
Version=39.3.30.1095, Culture=neutral,
PublicKeyToken=b1b72c69714d4847' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040) "
I tried almost everything from these articles and none of them worked. It just got fixed with simple step.
I tried building individual projects that basically set up the correct version reference to the dll and the error was entirely gone from the solution.
Go a similar issue and the directive mentionned in many comments worked fine
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
Although, you have to ensure the old version coverage is high enough otherwise newer versions may not be redirected to the specific version you need and location using that newer reference won't work properly since the older reference is already in the bin directory.
For this error (and similar) it's worth going through NuGet Consolidate (Solution > Manage NuGet Packages...) to ensure the same referenced component versions are consistent in each class library referenced in the solution, since even a slightly older version may have dependencies on other older components. It's straightforward to use in conjunction with Updates and can save a lot of pain.
This solved this issue for me and I would say it's a must to get familiar with if you're creating helper libraries that also reference MVC or other web-based NuGet components.
Windows allows use of a COM object without having to register the COM dll.
The mechanism is to include a "dependent assembly" in the application's manifest:
MyProgram.exe.manifest
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity type="win32" name="myapp.exe" version="1.2.3.4" />
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Contoso.Frobber" version="5.1.81.4" />
</dependentAssembly>
</dependency>
</assembly>
And then your folder contains:
MyProgram.exe
MyProgram.exe.manifest (if you're using an external manifest; could also be embedded at RT_MANIFEST resource)
Contoso.Frobber.manifest (the COM DLL manifest)
confrob.dll (the dll containing the COM classes we want to use)
with the COM dll's assembly manifest containing:
Contoso.Frobber.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="Contoso.Frobber" version="1.0.0.0" />
<file name = "confrob.dll">
<comClass
progid="Frobber.Gizmo"
clsid="{00028C00-0000-0000-0000-000000000046}"
description="Gizmo Frobber by Contoso"
threadingModel = "Apartment" />
<typelib
tlbid="{00028C01-0000-0000-0000-000000000046}"
version="1.0"
helpdir=""/>
</file>
</assembly>
Excellent. i can now use a COM object from a (native or .NET) executable without having to register the COM object.
Now i want to use a COM object from an ASP.NET web-site, without registering the COM object.
Possible?
Bonus Chatter
Windows also allows an exe to call a .NET library, without having to install the .NET assembly into the Global Assembly Cache.
Although I can't test it right now I am pretty sure that this works:
IF the manifest for a DLL is external it will usually be ignored when the DLL is loaded via LoadLibrary (according to MSDN). IF the manifest is embedded into the DLL it is usually honored.
Embed the manifest into the ASP.NET application (i.e. code-behind DLL) - for some ways on how to do this see here and here and here.
UPDATE - as per comments:
The above is a workaround as there is no general way to do this (isolation), at least the ASP.NET creators haven't intended this to be possible - for example the above workaround won't work in cases where the application does not compile to a DLL...
Recently we were handling a similar case that we needed to enable Side by Side COM(reg-free COM) in IIS hosted ASP.NET core application, and we made it like:
embed the manifest to an assembly(.dll)
use CreateActCtx() to activate the manifest.
This approach works fine and it's recommended by MS .NET Runtime Interop Team.
I have a mixed-mode DLL built in visual studio 2005. In dependency walker, my DLL is showing a dependency of the following CRT Dlls. Note this is on my Windows 7 developement machine.
c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5\MSVCP80.DLL
"\MSVCR80.DLL
"\MSVCM80.DLL
8.0.50727.4927
On my Windows 7 dev machine using Visual Studio 2005 this compiles and runs just fine. the problem is it wont run on my Windows XP test machine with the latest CRT installed.
When I drag the DLL into depenency walker on the XP machine it seems to be searching for the DLLs in \System32... (I went to show full path and there was no paths for them, just a yellow exclamation mark)
The problem is that this version (build 4927) of the crt in WinSxS is not installed on the XP test machine. it has Visual Studio 2005 with the latest CRT installed (sp1?).
8.0.50727.4053 is the latest version I could find on MSDN.
I realize this is not the most exciting question posted on SO, but does anyone know what is up with this 4927 runtime?
*
EDIT
*
The manifest generated by MT.exe:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
So, there is 3 different versions it is targeting...
Revision 4927 is a Windows 7 specific version, probably used by Microsoft binaries. Your build should not create a dependency on it, 4053 is the last one for VS2005. Don't troubleshoot this with depends.exe btw, it isn't good at tracking winsxs dependencies.
Start troubleshooting this by double-checking what dependency your build generates. First look in vc\include\crtassem.h, the _CRT_ASSEMBLY_VERSION macro generates the manifest entry. Next is to check the manifest that's embedded in your executable. Your project's Release directory contains the .embed.manifest file that was embedded. And File + Open + File on your executable lets you peek at the actual embedded RT_MANIFEST resource.