I'm working with an MVC2 app that had migrated from an MVC1 app quite a while ago. Things have been working - i've been able to compile and deploy a number of iterations without any problems (...yeah right...but not problems relevant to _this question...)
I've noticed that the version info - that bit in the footer of runtime errors - i've received during the normal course of development reads:
Version Information: Microsoft .NET Framework Version:2.0.50727.4952; ASP.NET Version:2.0.50727.4955
despite the fact that the project's Properties | Application tab shows the target framework to be .net 3.5. I _think 3.5 is required for mvc2 apps, isn't it?
Shouldn't I expect to see runtime error pages pointing to version info at the 3.5 version?
UPDATE: As that this isn't a simple matter of a framework mismatch, here's the error - but given other factors, I'll assume I need to repair/refresh the workstation's framework installs. The same code works on another ws.
=== Pre-bind state information ===
LOG: User = STUDIO11\steve
LOG: DisplayName = System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
(Fully-specified)
LOG: Appbase = file:///_mvc2/foo/
LOG: Initial PrivatePath = C:\_mvc2\foo\bin
Calling assembly : App_Web_enim_j6d, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\_mvc2\foo\web.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
thx
It's a bit complicated, but essentially the version you are seeing is the version of the CLR runtime. The 2.0, 3.0, and 3.5 releases of .NET share the same CLR runtime. If MVC runs then everything is fine.
Related
In the BizTalk Console Administration I often see exceptions like the following:
There was a failure executing the response(receive) pipeline: "[pipelineName], [BizTalk projectName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=35805574d24305bf" Source: "Unknown " Send Port: "[sendPortName]" URI: "[sqlServerConnString]" Reason: Failed to get pipeline: [pipelineName], [BizTalk projectName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=35805574d24305bf. Please verify that the pipeline strong name is correct and that the pipeline assembly is in the GAC.
I think the problem is how I deployed the pipeline and the project because I have developed my solution on a Virtual Machine (that have Visual Studio) and then I deployed my solution on another Virtual Machine (that does not have Visual Studio installed).
For the deploy I put the dll needed in a folder and then I added them from BizTalk Administration tool (Resources). Another strange thing I noticed is that in Resources I have:
[pipelineName], Version=1.0.0.0, Culture=netrual, PublicKeyToken=60cf10bb1a125a7
[BizTalk projectName], Version=1.0.0.0, Culture=netrual, PublicKeyToken=35805574d24305bf
I have no idea how to solve this issue. Can you help me?
Please check:
pipelineName is a pipeline inside the project (and the DLL)
[BizTalk projectName], Version=1.0.0.0, Culture=netrual, PublicKeyToken=35805574d24305bf
Your DLL have to be in the GAC, please check that the DLL is in the GAC, If not, add the DLL from BizTalk Administration tool (Resources) with "Add to the global assembly cache on add resource (gacutil)" option checked.
On resources you only need this:
[BizTalk projectName], Version=1.0.0.0, Culture=netrual, PublicKeyToken=35805574d24305bf
The other one ([pipelineName], Version=1.0.0.0, Culture=netrual, PublicKeyToken=60cf10bb1a125a7) is another DLL that you added to this BizTalk application.
You have to properly deploy the Pipeline Component Assembly.
This article explains the entire process: BizTalk Server: Deploying Custom Pipeline Components in BizTalk Server 2006 and Higher
I had to restart the associated hosts and the standard BizTalkServerApplication host to refresh the in-memory data.
Sounds strange, I know... and I've poured over every post I could find relating to this :( However, my website worked just fine and then all of the sudden it is failing on:
Could not load file or assembly 'DotNetOpenAuth.Core, Version 4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies. The located assembly's manifest definition does not match the asembly reference. (Exception from HResult: 0x80131040).
I don't see any references to it at all in the project and it has never used authentication ever. What is the lowest level I can get to in order to find out where it is trying to call this assembly and remove it?
It's frustrating as heck... I know it is because I'm not an every-day programmer - so maybe its easy to find, but I have looked over hundreds of posts here and elsewhere trying to resolve and nothing has worked so far :(
I also grabbed an unused reference tool called ResolveUR to try to do it... still same result :(
FYI - I'm using Visual Studio 2013 for this one because Installshield LE is part of it and that was how the application was initially deployed.
Thanks in advance!
** ADDED error I get from page **
=== Pre-bind state information ===
LOG: DisplayName = DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246
(Fully-specified)
LOG: Appbase = file:///C:/inetpub/wwwroot/MedsAdmin/
LOG: Initial PrivatePath = C:\inetpub\wwwroot\MedsAdmin\bin
Calling assembly : Microsoft.Web.WebPages.OAuth, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/medsadmin/4efeacc2/d291dc53/DotNetOpenAuth.Core.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/medsadmin/4efeacc2/d291dc53/DotNetOpenAuth.Core/DotNetOpenAuth.Core.DLL.
LOG: Attempting download of new URL file:///C:/inetpub/wwwroot/MedsAdmin/bin/DotNetOpenAuth.Core.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
* EDIT: Replaced Old Web.Config *
Somehow my web.config file got written over - so that is the reason for the OpenAuth issue.
NOW: It seems to be trying to load MySQLMembershipProvider from my machine.config file (which fails). Why is it doing this?
We have a web application which we host, where we deploy the same application to 100+ "tenants" on the same machine(s).
Managed DLL's memory is not shared between processes by default, that means we load the same DLL 100+ times into memory. Goal is to avoid this, and NGen seems to be the way to go for this, as it specifically allows this to happen.
The ASP.NET application is pre-compiled and all DLL's have been NGen'ed, but it seems that they are not used.
Fusion Log Viewer gives us the following output:
* Assembly Binder Log Entry (20.06.2017 # 16:53:11) *
The operation was successful. Bind result: hr = 0x0. The operation
completed successfully.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under
executable c:\windows\system32\inetsrv\w3wp.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = SD.LLBLGen.Pro.ORMSupportClasses, Version=5.1.0.0, Culture=neutral,
PublicKeyToken=ca73b74ba4e3ff27 (Fully-specified)
LOG: Appbase = file:///E:/WebHotel/tenant/ItemService/ LOG: Initial PrivatePath =
E:\WebHotel\tenant\ItemService\bin LOG: Dynamic Base = E:\Temporary
ASP.NET Files\itemservice\081f93f5 LOG: Cache Base = E:\Temporary
ASP.NET Files\itemservice\081f93f5 LOG: AppName = fd860966 Calling
assembly : Product.Core.Library, Version=2.5.12456.0,
Culture=neutral, PublicKeyToken=null.
=== LOG: IL assembly loaded from E:\Temporary ASP.NET Files\itemservice\081f93f5\fd860966\assembly\dl3\08cf29cf\00893e3e_afe9d201\SD.LLBLGen.Pro.ORMSupportClasses.dll.
* Assembly Binder Log Entry (20.06.2017 # 16:53:11) *
The operation was successful. Bind result: hr = 0x0. The operation
completed successfully.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under
executable c:\windows\system32\inetsrv\w3wp.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = SD.LLBLGen.Pro.ORMSupportClasses, Version=5.1.0.0, Culture=neutral,
PublicKeyToken=ca73b74ba4e3ff27 (Fully-specified) LOG: Appbase =
file:///E:/WebHotel/tenant/ItemService/ LOG: Initial PrivatePath =
E:\WebHotel\tenant\ItemService\bin LOG: Dynamic Base = E:\Temporary
ASP.NET Files\itemservice\081f93f5 LOG: Cache Base = E:\Temporary
ASP.NET Files\itemservice\081f93f5 LOG: AppName = fd860966 Calling
assembly : Product.Core.Library, Version=2.5.12456.0,
Culture=neutral, PublicKeyToken=null.
=== LOG: IL assembly loaded from E:\Temporary ASP.NET Files\itemservice\081f93f5\fd860966\assembly\dl3\08cf29cf\00893e3e_afe9d201\SD.LLBLGen.Pro.ORMSupportClasses.dll.
As you can see it does not load the native image from C:\Windows\assembly\NativeImages_v4.0.30319_64...
Using:
NGen display "SD.LLBLGen.Pro.ORMSupportClasses, Version=5.1.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27"
gives us:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319>ngen display
"SD.LLBLGen.Pro.ORM SupportClasses, Version=5.1.0.0, Culture=neutral,
PublicKeyToken=ca73b74ba4e3ff2 7" Microsoft (R) CLR Native Image
Generator - Version 4.6.1087.0 Copyright (c) Microsoft Corporation.
All rights reserved.
NGEN Roots:
\server\e$\Template\2.5.12456.0\ItemService\bin\SD.LLBLGen.Pro.ORMSuppor
NGEN Roots that depend on "SD.LLBLGen.Pro.ORMSupportClasses,
Version=5.1.0.0, Cu lture=neutral, PublicKeyToken=ca73b74ba4e3ff27":
\server\e$\Template\2.5.12456.0\WS\bin\SD.LLBLGen.Pro.ORMSupportClasse
s.dll
Native Images:
SD.LLBLGen.Pro.ORMSupportClasses, Version=5.1.0.0, Culture=neutral,
PublicKeyTok en=ca73b74ba4e3ff27
Not sure if this is the issue, but c:\windows\system32\inetsrv\w3wp.exe seems to be a 32-bit executable, and you're using the 64-bit ngen.exe. If your app is 32-bit, you'll need to use the 32-bit ngen.exe, or the 64-bit w3wp.exe if it's the other way around.
If this is not the issue, you may want to check this blog post (if you haven't already):
https://kceiw.me/net-native-image-troubleshooting
I have a Web API I created in ASP 5 MVC 6 (FULL CLR). The web API references a standard .net class library, which has the entity framework 6 NUGET package installed. If I launch the web api locally (IIS express) and then try to run a method which contacts the database, everything works fine.
When I deploy the web API (I set it up in IIS), using the "Publish" command, to my DEV server (Windows Server 2012) and try to contact the same method, but on the server, I get the following exception (any other method that doesn't touch the database works):
{
"$id":"1",
"ClassName":"System.IO.FileNotFoundException",
"Message":"Could not load file or assembly 'EntityFramework,
Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
or one of its dependencies. The system cannot find the file specified.",
"Data":null,
"InnerException":null,
"HelpURL":null,
"StackTraceString":"
at CMAllocation.Web.Data.InvestorRulesRepository..ctor()\r\n
at CMAllocation.Web.CMAllocationWebApi.Controllers
.InvestorRulesController.GetInvestors()
in E:\\CMAllocation\\WebServices\\CMAllocationWebApi
\\Debug\\approot\\src\\CMAllocation.Web.CMAllocationWebApi
\\Controllers\\InvestorRulesController.cs:line 45",
"RemoteStackTraceString":null,
"RemoteStackIndex":0,
"ExceptionMethod":
"1\n.ctor\nCMAllocation.Web.Data, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null\nCMAllocation.Web.Data.InvestorRulesRepository\nVoid .ctor()",
"HResult":-2147024894,
"Source":"CMAllocation.Web.Data",
"WatsonBuckets":null,
"FileNotFound_FileName": "EntityFramework, Version=6.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089",
"FileNotFound_FusionLog":
"WRN: Assembly binding logging is turned OFF.\r\n
To enable assembly bind failure logging, set the registry value
[HKLM\\Software\\Microsoft\\Fusion!EnableLog] (DWORD) to 1.\r\n
Note: There is some performance penalty associated with
assembly bind failure logging.\r\n
To turn this feature off, remove the registry value
[HKLM\\Software\\Microsoft\\Fusion!EnableLog].\r\n"
}
Any help would be appreciated.
UPDATE I can clearly see the EF 6 dll's in the approot/packages folder:
Your server is missing 'EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
Build on the server with msbuild.
Run NuGet restore. Dave Ebbo has a good article. It is nuget restore from the cmd line.
If that doesn't work, install the EntityFramework package into the GAC on your server.
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.