All,
My Project - (VS 2010 / .NET 4 / ASP.NET application, my web application lives inside Sitefinity as a Sitefinity application)
I have two versions of the MongoDB assemblies. I would like to run these side-by-side in my web application. Here's my setup:
\bin\AuxFiles\[1.8.3.9] assemblies
\bin\[1.4.x.x] assemblies
Web config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MongoDB.Bson" publicKeyToken="f686731cfb9cc103" culture="neutral" />
<codeBase version="1.4.2.4500" href="bin\MongoDB.Bson.dll" />
<codeBase version="1.8.3.9" href="bin\AuxFiles\MongoDB.Bson.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="MongoDB.Driver" publicKeyToken="f686731cfb9cc103" culture="neutral" />
<codeBase version="1.4.2.4500" href="bin\MongoDB.Driver.dll" />
<codeBase version="1.8.3.9" href="bin\AuxFiles\MongoDB.Driver.dll" />
</dependentAssembly>
</assemblyBinding>
When the application starts, it loads the 1.4.x.x assemblies by default. When I go to the page that uses the 1.8.3.9 version of assemblies I get an error:
Server Error in '/' Application.
Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' 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 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Source Error: ....
Source File: ...... Line: 18
Assembly Load Trace: The following information can be helpful to determine why the assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' could not be loaded.
=== Pre-bind state information ===
LOG: DisplayName = MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103
(Fully-specified)
LOG: Appbase = file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/
LOG: Initial PrivatePath = C:\DEV\Visual Studio 2010\WebStoreApp\WebStoreApp\bin
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\DEV\Visual Studio 2010\WebStoreApp\WebStoreApp\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: MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/bin/MongoDB.Driver.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Stack Trace:
[FileLoadException: Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +51
System.Web.UI.Control.OnLoad(EventArgs e) +92
System.Web.UI.Control.LoadRecursive() +54
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint
UPDATE 1:
I have tried to rename my new 1.8.x.x assemblies from MongoDB.Driver.dll to MongoDB.Driver.exe so the files can co-exist under same directory (the older assemblies have extension .dll, the new version of the assemblies have extension .exe) but the loader seems not to pickup the assemblies. My understanding is that the loader always tries .dlls first, then tries .exes second. I am a bit puzzled.
UPDATE 2:
I have created a console application w/ exactly identical setup of my dual references and the app config entries that you see here,- and the application works, it executes 2 versions of the Mongo dll. The question is now, why doesn't this setup work in my Web application? Are my directories wrong? If you look below at the probing for the assemblies, it never checks my AuxFiles directory, it appears it simply ignores my configuration for side-by-side execution in web.config.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/bin/MongoDB.Driver.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
UPDATE 3:
Found the issue but I am not sure of the details of this solution. The web.config file has 'configuration' root element w/ the following namespace declaration - 'xmlns=http://schemas.microsoft.com/.NetConfiguration/v2.0'.
The root element is fine but the specified namespace is causing my 'runtime' element to be ignored. Removing the namespace from the configuration element fixes everything.
Found the issue:
The 'configuration' root element in the web.config file contains the following namespace declaration - 'xmlns=http://schemas.microsoft.com/.NetConfiguration/v2.0'. Removing the namespace from the configuration element fixes everything.
Why the ns? It is more of a bug then anything in VS and has really no real purpose but mess up your intellisense and in my case the runtime configuration. Read more about it:
http://weblogs.asp.net/scottgu/archive/2005/12/02/432077.aspx
Related
My project is using Nuget package Atlassian.SDK 10.6.0.
When calling
var jc = Atlassian.Jira.Jira.CreateRestClient(_jiraBaseUrl, _jiraApiUsername, _jiraApiPassword);
I have the error
System.IO.FileLoadException: Could not load file or assembly
'Newtonsoft.Json, Version=10.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)
My web.config already has the bindingRedirect
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
I also checked the fusion log
Calling assembly : Atlassian.Jira, Version=10.6.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: F:\Titan\AutoLedgers\Facade\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary
ASP.NET Files/facade/a6115f90/89f913a7/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary
ASP.NET
Files/facade/a6115f90/89f913a7/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///F:/Titan/AutoLedgers/Facade/bin/Newtonsoft.Json.DLL.
LOG: Assembly download was successful. Attempting setup of file: F:\Titan\AutoLedgers\Facade\bin\Newtonsoft.Json.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Setup failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
I really have no idea how can I resolve this issue now. Does anyone has any idea?
I'm working on an ASP.NET Web Forms web site and frequently get run-time exceptions like the following:
Could not load file or assembly 'Newtonsoft.Json, Version=4.5.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)
=== Pre-bind state information ===
LOG: DisplayName = Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
(Fully-specified)
LOG: Appbase = file:///C:/Code/MyProject/
LOG: Initial PrivatePath = C:\Code\MyProject\bin
Calling assembly : System.Net.Http.Formatting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Code\MyProject\web.config
LOG: Using host configuration file: \\foo\bar\Profile.v2\simonm\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.5.0.0 redirected to 11.0.0.0.
LOG: Post-policy reference: Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: Attempting download of new URL file:///C:/Users/simonm/AppData/Local/Temp/Temporary ASP.NET Files/vs/8d6ca9e7/1d38a78a/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/simonm/AppData/Local/Temp/Temporary ASP.NET Files/vs/8d6ca9e7/1d38a78a/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Code/MyProject/bin/Newtonsoft.Json.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
They're invariably because the "wrong" version of an assembly (it always seems to be Newtonsoft.Json) gets copied to the Bin directory despite the fact that the packages.config in the root of the site has:
<package id="Newtonsoft.Json" version="11.0.2" targetFramework="net45" />
and the web.config contains:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>
Can somebody please explain what dictates which assembly gets copied to the Bin directory, why this keeps happening and how to prevent it from happening in the future?
I guess, that some of your used frameworks/libraries are using different versions of Newtonsoft.Json. First, check your frameworks/libraries if they are requiring different versions of the Newtonsoft.Json library.
When you detected which is the (minimum) required version of Newtonsoft.Json try to reinstall this version through Nuget.
This seems to be cause by a number of factors, but ultimately boils down to having a .refresh file in the Bin directory that points to a different version of the assembly than the one referenced in the web.config.
It looks like these .refresh files get added when you (either manually or automatically due to e.g. Update-Package) add a reference to an ASP.NET project. If you look at the contents of a .refresh file, it's just the path to a .dll file. When you build, MSBuild (I assume) checks whether the Foo.dll in your Bin directory matches the one referenced by Foo.dll.refresh and, if they don't, copies the one referenced by the .refresh file into your Bin.
I think this combined with switching branches in Git to one that has a reference to a different version referenced in the web.config combined with the .refresh files not being in version control is what causes these problems.
My ASP.Net MVC Application works fine when run locally on IIS, but gives the following error when deployed to Azure:
Could not load file or assembly 'Microsoft.Owin, Version=2.1.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)
This is the piece of the stack trace that led me to believe that SignalR is a potential culprit:
[FileLoadException: Could not load file or assembly 'Microsoft.Owin, Version=2.1.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)]
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, String path, HubConfiguration configuration) +0
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, HubConfiguration configuration) +12
QuikWorx.O365Web.Startup.Configuration(IAppBuilder app) +169
According to NuGet, I have version 3.0.1 of Microsoft.Owin installed on the application, but apparently something (SignalR) requires version 2.1.0. I would have thought that the following bindingRedirect would force SignalR to use the installed version 3.0.1 (verified present, version 3.0.1 in /bin on Azure):
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
</dependentAssembly>
...but alas, this is not the case.
I've also tried the following without success:
Forced reinstall of Microsoft.Owin 3.0.1 with NuGet.
Forced reinstall of the SignalR component (Microsoft.AspNet.SignalR.Core) that requires Microsoft.Owin 2.1.0 with NuGet
Changing the oldVersion of the bindingRedirect for Microsoft.Owin to "0.0.0.0-2.1.0.0" (this makes no sense)
Removing the bindingRedirect for Microsoft.Owin
Deleting all files and folders in the site directory using rd /Q /S in Kudu
Is there anything else that I could attempt?
Would love to get to the root cause of the issue, as in why it works locally, but not in Azure, but based on this answer you should probably try to install Microsoft OWIN itself - via NuGet, directly to the project that's failing.
I am seeing some really odd behavior that I have not been able to correct related to references for Newtonsoft.Json.dll. I have a sample solution set up with the following projects:
JsonProblem.Core
JsonProblem.CauseProblem (references JsonProblem.Core)
JsonProblem.Web (references JsonProblem.Core and JsonProblem.CauseProblem)
In JsonProblem.Core and JsonProblem.Web I have added the "Microsoft ASP.NET Web API 2.2" NuGet package. In JsonProblem.Core I have created a web api. If I build JsonProblem.Core and run a page from JsonProblem.Web everything works as expected.
Now if I build JsonProblem.CauseProblem and try to view a page in JsonProblem.Web, I get the following error.
Could not load file or assembly 'Newtonsoft.Json' or one of its
dependencies. The located assembly's manifest definition does not
match the assembly reference. (Exception from HRESULT: 0x80131040)
If I rebuild JsonProblem.Core the error goes away. And again if I build JsonProblem.CauseProblem without building JsonProblem.Core afterward (even though JsonProblem.CauseProblem depends on JsonProblem.Core) I get the error. Somehow the build of JsonProblem.CauseProblem is causing version 4.5.11 of Newtonsoft.Json to get copied to the JsonProblem.Web bin directory, overwriting version 6.0.3. I'm pretty sure I have binding redirects setup correctly, as I have the following in the JsonProblem.Web web.config and in the app.config files for JsonProblem.Core and JsonProblem.CauseProblem:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
So I am at a loss as to the cause of this strange behavior. I have reproduced it in 2 projects. It seems that the binding redirects are ignored when I build JsonProblem.CauseProblem. I can work around it, but I'm concerned that whatever bug or feature is causing this behavior may be altering other references in the background that might cause problems down the line.
EDIT - as tizzy suggested I used the fuslogvw tool. Here is what was generated in the log. I'm not sure how to interpret this, however, because the log does not tell me what happens at build time to overwrite the version of Newtonsoft.Json.dll in my the app's website directory.
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Program Files\IIS Express\iisexpress.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = Newtonsoft.Json
(Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: Newtonsoft.Json | Domain ID: 5
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Users/John/Desktop/JsonProblem/JsonProblem.Web/
LOG: Initial PrivatePath = C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\bin
LOG: Dynamic Base = C:\Users\John\AppData\Local\Temp\Temporary ASP.NET Files\vs\3661babd
LOG: Cache Base = C:\Users\John\AppData\Local\Temp\Temporary ASP.NET Files\vs\3661babd
LOG: AppName = 3b3fd45
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\web.config
LOG: Using host configuration file: C:\Users\John\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/Desktop/JsonProblem/JsonProblem.Web/bin/Newtonsoft.Json.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\bin\Newtonsoft.Json.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: A partially-specified assembly bind succeeded from the application directory. Need to re-apply policy.
LOG: Using application configuration file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\web.config
LOG: Using host configuration file: C:\Users\John\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.5.0.0 redirected to 6.0.0.0.
LOG: Post-policy reference: Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: GAC Lookup was unsuccessful.
LOG: The post-policy assembly reference requires probing again.
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/Desktop/JsonProblem/JsonProblem.Web/bin/Newtonsoft.Json.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\bin\Newtonsoft.Json.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Setup failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
I had the exact same behavior as the above problem description, except that when I rebuilt my class library (i.e. JsonProblem.Core), it would pull in Newtonsoft.dll 4.5.11, even though this class library had no direct reference or Nuget package that indicated a reference to NewtonSoft.
In what could be considered a Visual Studio 2015 bug, the class library rebuild copies the invisibly referenced DLLs into referencing project bin folders (not currently being built), overwriting the DLLs in referencing projects, breaking them.
IOW, for example, build project Y (referencing JsonProblem.Core), apparent success. Build project X (ref to JsonProblem.Core) which breaks project Y. Build Project Y and now this breaks Project X. Infinite loop: while( sane ) { build(); }
In my case, the only 3rd party libraries that I was referencing in this library were Gibraltar.Agent and Gibraltar.Agent.Web.Mvc (which reported no dependency on NewtonSoft. Right clicking on these in project References and selecting "Find Code Dependent on this module" revealed that I didn't need to reference the 2nd one.
I uninstalled Gibraltar.Agent.Web.Mvc in Nuget, and all problems went away. Two days of DLL Hell heartache have ended.
You may be dealing with a handful of different scenarios here. My advice to you would be to use the fuslogvw tool to show you which dll it's trying to load, and where it's looking for it. It is possible that there is another dependency problem that is being masked here, since your assembly binding redirect looks correct on the surface. The fuslogvw tool will just allow you to see the assembly binding behavior, and what's happening. It's great to have for assembly binding issues.
I am trying to deploy my ASP.Net MVC4 application to Azure but it is crashing during deployment. Apparently this is because something is requesting assembly 'System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' . This all works perfectly locally and is a nightmare to debug on Azure as deployment takes 25-30 minutes for me.
I had thought I had configured CLR to not require MVC3 even if something wanted it by using:
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
If I look at the ObjectBrowser nothing seems to be requiring MVC3. What is the best way to figure out what is requesting it? I have various Nuget packages in the project. I guess one of them is requesting MVC3? Is there anyway to see a list of all dependencies etc?
I get:
CLR exception type: System.Reflection.ReflectionTypeLoadException
"Unable to load one or more of the requested types. Retrieve the
LoaderExceptions property for more information."
Microsoft.WindowsAzure.ServiceRuntime Critical: 201 : ModLoad:
000007fc906a0000 000007fc907a9000
D:\Windows\Microsoft.NET\Framework64\v4.0.30319\diasymreader.dll Role
entrypoint could not be created: System.TypeLoadException: Unable to
load the role entry point due to the following exceptions:
-- System.IO.FileLoadException: Could not load file or assembly 'System.Web.Mvc, Version=3.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) File name:
'System.Web.Mvc, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'
WRN: Assembly binding logging is turned OFF. To enable assembly bind
failure logging, set the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There
is some performance penalty associated with assembly bind failure
logging. To turn this feature off, remove the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog].
---> System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property
for more information. at
System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) at
System.Reflection.RuntimeModule.GetTypes() at
System.Reflection.Assembly.GetTypes() at
Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetRoleEntryPoint(Assembly
entryPointAssembly) --- End of inner exception stack trace ---
at
Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetRoleEntryPoint(Assembly
entryPointAssembly) at
Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CreateRoleEntryPoint(RoleType
roleTypeEnum) at
Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.InitializeRoleInternal(RoleType
roleTypeEnum) ModLoad: 000007fca2f00000 000007fca2f96000
D:\Windows\SYSTEM32\clbcatq.dll ntdll!ZwTerminateProcess+0xa:
000007fc`a2fa2eaa c3 ret
and
Exception object: 00000000017e0070 Exception type: System.TypeLoadException Message: Unable to load the role
entry point due to the following exceptions:
-- System.IO.FileLoadException: Could not load file or assembly 'System.Web.Mvc, Version=3.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) File name:
'System.Web.Mvc, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'
WRN: Assembly binding logging is turned OFF. To enable assembly bind
failure logging, set the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There
is some performance penalty associated with assembly bind failure
logging. To turn this feature off, remove the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog].
InnerException: System.Reflection.ReflectionTypeLoadException, Use
!PrintException 00000000017dcf08 to see more. StackTrace (generated):
StackTraceString: HResult: 80131522
You can use Reflector to load the Nuget packages and look at their dependencies. Should be fairly easy to spot whether one is dependent upon MVC3. Your assembly binding looks fine though. Do you have multiple projects in your solution? Could one of those be taking a dependency on a Nuget package that depends on MVC3?
This post may help: How can I build a 'dependency tree diagram' from my .NET solution