Related
We have an application written against .NET 4.0 which over the weekend crashed, putting the following message into the event log:
Application: PnrRetrieverService.exe Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in
the .NET Runtime at IP 791F9AAA (79140000) with exit code 80131506.
This is on a Windows Server 2003 R2 Standard Edition box. Googling this error hasn't turned up anything pertinent. For example, this isn't occurring in VS Studio, but instead on a production box; when the service was eventually restarted, it experienced no further problems.
How does one go about diagnosing a bug in the .NET Runtime?
with exit code 80131506
That's a nasty one, ExecutionEngineException. Starting with .NET 4.0, this exception immediately terminates the program. The generic cause is corruption of the state of the garbage collected heap. Which in turn is invariably caused by unmanaged code. The exact location in code at which this exception is raised isn't helpful, the corruption usually occurred well before the damage is detected.
Finding the exact cause for this is going to be difficult. Review any unmanaged code your service might be using. Suspect environmental problems if there is no obvious candidate, misbehaving malware scanners are notorious. If it repeats very poorly then suspect hardware problems like soft RAM errors.
A bug in the concurrent implementation of the Garbage Collection on x64 .Net 4 can cause this as stated in the following microsoft KB entry:
ExecutionEngineException occurs during Garbage Collection
You should first make a deep minidump exploration to be sure that the problem occured during a Garbage collection.
The minidump location can usually be found in a Windows Error Reporting entry in the event log following the crash entry.
Then, have fun with WinDbg !
The latest documentation on the use of the <gcConcurrent/> configuration element, to disable concurrent or (in .NET 4 and later) background garbage collection, can be found here.
I've experienced "internal errors" in the .NET runtime that turned out to be caused by bugs in my code; don't think that just because it was an "internal error" in the .NET runtime that there isn't a bug in your code as the root cause. Always always always blame your own code before you blame someone else's.
Hopefully you have logging and exception/stack trace information to point you where to start looking, or that you can repeat the state of the system before the crash.
For those arriving here from google, I've eventually come across this SO question, and this specific answer solved my problem. I've contacted Microsoft for the hotfix through the live chat on support.microsoft.com and they sent me a link to the hotfix by email.
Had the same exact error on WinXP box with latest build of my .NET 4 code. Checked previous builds - now they crash too! Ok, so it's not me :). No suggestions here/above helped.
Much more recent (2018-05-09) report of the same problem: Application Crash with exit code 80131506.
A: We were receiving a similar error, but we believe ours was caused by the Citrix memory optimizer.
The resolution was to force a regeneration of the .Net core libraries on the host(s) where the issue was occurring:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force
Root cause is still unknown (machine is not being updated and has little use), but that did it for me!
After years of wrestling with this issue in a number of applications, it appears that Microsoft has finally accepted it as a bug in .NET 4 CLR that causes this to occur. http://support.microsoft.com/kb/2640103.
I had previously been "fixing" it by forcing the garbage collector to run in server mode (gcServer enabled="true" in app.config) as described in the Microsoft article linked to by Think Before Coding. This in essence forces all threads in the application to pause during the collection removing the possibility of other threads accessing the memory being manipulated by the GC. I am happy to find that my years of searching in vain for a "bug" in my code or other 3rd party unmanaged libraries were only fruitless because the bug lay in Microsoft's code, not mine.
Could be a bug with concurrent GC
http://support.microsoft.com/kb/2679415
In my case this exception was occured when disk space was over and .NET can't allocate memory in Windows Virtual Memory.
In event log I saw this error:
Application popup: Windows - Virtual Memory Minimum Too Low : Your system is low on virtual memory. Windows is increasing the size of your virtual memory paging file. During this process, memory requests for some applications may be denied.
And previous error:
The C: disk is at or near capacity. You may need to delete some files.
In my case the problem was a C++/CLI library in which there was a call to the NtQuerySystemInformation; for some kind of reason sometimes (and under mysterious circumstances), when it was called the CLR heap got corrupted and the application crashed.
I've resolved the problem using a "custom heap" created with HeapCreate and allocating there the buffers used by that function.
This might be an exception occurring in the finalizer. If you are doing the Pattern of ~Class(){ Dispose(false); } check what are you disposing as an un-managed resource.
Just put a try..catch there and you should be fine.
We found the issue as we had this mysterious failure with no logs
We did the usual recommended pattern of using a "void Dispose(bool disposing)".
Looking at the answers on this question about the finalizer we found a possible place where the Disposal of the unmanaged resources could throw an exception.
It turns out somewhere we did not dispose the object properly thus the finalizer took over the diposal of unmanaged resources thus behold an exception occurred.
In this case was using the Kafka Rest API to clean up the client from Kafka. Seems that it did threw exception at some point then this issue occurred.
I am not sure it may help everyone, but I could get around this by running
devenv.exe /ResetSettings
...in the path {Visual_Studio_root}\Common7\Ide
I had the following errors in the event log and VS was just crashing and restarting all the time:
Faulting application name: devenv.exe, version: 14.0.25123.0, time stamp: 0x56f22f32
Faulting module name: clr.dll, version: 4.7.2115.0, time stamp: 0x59af88f2
Exception code: 0xc0000005
Fault offset: 0x0015f90e
Faulting process id: 0x3a7c
Faulting application start time: 0x01d353463eaf0c36
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: a232f984-6e80-4f61-9003-e18a035c8f93
Faulting package full name:
Faulting package-relative application ID:
Every 5-10 minutes my application pool kept crashing with this exit code. I do not want to ruin your trust of the Garbage Collector, but the following solution worked for me.
I added a Job that calls GC.GetTotalMemory(true) every minute.
I suppose that, for some reason, the GC is not automatically inspecting the memory often enough for the high number of disposable objects that I use.
In my case the issue was due to duplicate binding redirects in my web.config. More info here.
I assume it was because of NuGet modifying the binding redirects, but for example it was looking like this:
<dependentAssembly>
<assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
<bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
<bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
Removing all the duplicates solved the problem.
In my case the problem was related to "Referencing .NET standard library in classic asp.net projects" and these two issues
https://github.com/dotnet/standard/issues/873
https://github.com/App-vNext/Polly/issues/628
and downgrading to Polly v6 was enough to workaround it
In my case this error occured when logging in SAP Business One 9.1 application. In Windows events I could find also another error event in addition to the one reported by the OP:
Nome dell'applicazione che ha generato l'errore: SAP Business One.exe, versione: 9.10.160.0, timestamp: 0x551ad316
Nome del modulo che ha generato l'errore: clr.dll, versione: 4.0.30319.34014, timestamp: 0x52e0b784
Codice eccezione: 0xc0000005
Offset errore 0x00029f55
ID processo che ha generato l'errore: 0x1d7c
Ora di avvio dell'applicazione che ha generato l'errore: 0x01d0e6f4fa626e78
Percorso dell'applicazione che ha generato l'errore: C:\Program Files (x86)\SAP\SAP Business One\SAP Business One.exe
Percorso del modulo che ha generato l'errore: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
ID segnalazione: 3fd8e0e7-52e8-11e5-827f-74d435a9d02c
Nome completo pacchetto che ha generato l'errore:
ID applicazione relativo al pacchetto che ha generato l'errore:
The machine run Windows 8.1, with .NET Framework 4.0 installed and without the 4.5 version. As it seemed from the internet that it could be also a bug in .NET 4, I tried installing .NET Framework 4.5.2 and I solved the issue.
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Reflection.TargetInvocationException
I have faced this Error, Application was working fine on some PCs and on some PCs giving the above error. I uninstall the Framework 4.5 and re-install this resolved my problem.
Cheer.
I never figured out why this was happening for me. It was consistently reproducible for one of my applications, but went away after simply rebooting.
I am running Windows 2004 Build 19582.1001 (Insider Preview) with .net-4.8 and I also would not be surprised if this were due to something like a hardware memory error. Also, my application does load some unmanaged code and initialize it, so I can’t prove that the crash didn’t come from that.
I had same issue on Windows 2016 while installing SQL server 2017. Error was
"ScenarionEngine.exe Crashes With "Internal Error In The .NET Runtime"
First check the Microsoft .NET Framework version if it is 4.5 then upgrade is to latest version. Currently it is Microsoft .NET Framework 4.8. If this not work for you then try the next step.
Next Step: Please uninstall KB4486129, and then download the Microsoft .NET Framework 4.8. Same error has been resolved for me.
I'm trying to reference Oracle.DataAccess from a .NET 4.0 project, written on Visual Studio 2013. My machine's GAC has two versions of Oracle.DataAccess installed: 4.112.1.2 (provided by Oracle version 11gr2) and 4.121.2.0 (provided by Oracle version 12c).
I want to reference version 4.112.1.2 (my project must run with %ORACLE_HOME% set to 11gr2's install location, and referencing 4.121.2.0 causes runtime failures when this is the case). I do not have an admin account on my machine, so I can't just uninstall the 12c dll.
I have tried the following steps to force the executable to load the 4.112.1.2 dll at runtime:
Reference the dll in my .csproj file using the strong name:
<Reference Include="Oracle.DataAccess, Version=4.112.1.2, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86"/>
Updating my App.Config file to force a redirect:
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral"/>
<codeBase version="4.112.1.2" href="C:\Path\To\11gr2\Oracle.DataAccess.dll"/>
<bindingRedirect oldVersion="4.121.2.0" newVersion="4.112.1.2"/>
<publisherPolicy apply="no"/>
</dependentAssembly>
I modified my PATH to make the 11gr2 Client's bin directory first on my path:
set PATH="C:\path\to\11gr2\BIN;%PATH%"
No matter what I do, however, the executable loads the 4.121.2.0 dll from the GAC at runtime. Here's what it says when I attach a debugger:
'MyApp.exe' (Managed (4.0.30319)): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_32\Oracle.DataAccess\v4.0_4.121.2.0_89b483f429c47342\Oracle.DataAccess.dll'
I've read through Microsoft's documentation on assembly binding (here and here). I've also read the StackOverflow answers that seem to be related to my issue (here and here), but nothing has worked.
How do I force .NET to load the correct DLL version at runtime from the GAC?
EDIT:
Wernfried's answer leads me to think I may be looking at this the wrong way. Here's exactly what's happening:
I run my application with ORACLE_HOME=C:\ORACLE\ora12c, everything works as normal (database accesses succeed, application is happy)
I run my application with ORACLE_HOME=C:\ORACLE\ora11gr2 (the required version). Application crashes with following exception:
Oracle.DataAccess.Client.OracleException ORA-12557: TNS:protocol adapter not loadable.
<stacktrace follows>
Following the stacktrace, I discovered that the error occurred in the call my application made to create a database connection. I've checked my connection string and verified that it is correct (and that it is the same connection string that was succeeding with 12c). I then discovered that version of the Oracle.DataAccess dll I was calling was the 12c one, not the 11gr2 one. From this, I concluded that I needed to modify the call to load the dll to "force" the 11gr2 one. If I'm barking up the wrong tree, please let me know!
As far as I know, ODP.NET provider 4.112.1.2 works only with Oracle Client 11.2, resp. ODP.NET provider 4.121.2.0 requires Oracle 12.1 Client.
Do you have both versions of Oracle Client installed on your machine?
In order to use one or the other you must also set your PATH environment variable accordingly. PATH must include folder of Oracle client binaries you like to use in your application.
Note, the architectures (i.e. 32-bit vs. 64-bit) have to be all the same at your application, the Oracle Client and the ODP.NET provider.
But why do you like to force a particular version of ODP.NET? I recommend to use this reference
<Reference Include="Oracle.DataAccess">
<SpecificVersion>False</SpecificVersion>
<Private>False</Private>
</Reference>
then your application will load automatically the correct version of ODP.NET no matter what is installed on your machine (or the machine of your customer).
Anyway, in case you like to run test and force particular version of ODP.NET you can use dynamic binding. For this your code like this:
using (OracleConnection con = new OracleConnection(connString))
{
con.Open();
...
}
has to be re-written like this one:
var DLL = default(Assembly);
DLL = Assembly.LoadFrom(#"C:\Path\To\11gr2\Oracle.DataAccess.dll");
// resp for GAC:
// DLL = Assembly.Load(String.Format("Oracle.DataAccess, Version={0}.{1}.*.*, Culture=neutral, PublicKeyToken=89b483f429c47342", 1, 112));
var type = DLL.GetType("Oracle.DataAccess.Client.OracleConnection", true, false);
using ( dynamic con = Activator.CreateInstance(type, connString) ) {
con.Open();
...
}
I believe I have it fixed.
What got it working for me was to unset the ORACLE_HOME environment variable, and to put C:\Path\to\11gr2\bin at the beginning of my path, like so:
set PATH=C:\Path\to\11gr2\bin;%PATH%
I have a project that works locally, on our dev server, and on our production server.
When I try to run it on the test server, I get the error below, and I don't know what to do about it beyond stare at my screen blankly. Hints? Process to trace the issue to its source?
I've installed the NuGet package for Oracle 12.2, etc.
Could not load type 'OracleInternal.Common.ConfigBaseClass' from
assembly 'Oracle.ManagedDataAccess, Version=4.121.2.0,
Culture=neutral, PublicKeyToken=89b483f429c47342'. 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.TypeLoadException: Could not load type
'OracleInternal.Common.ConfigBaseClass' from assembly
'Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral,
PublicKeyToken=89b483f429c47342'.
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.
Stack Trace:
[TypeLoadException: Could not load type
'OracleInternal.Common.ConfigBaseClass' from assembly
'Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral,
PublicKeyToken=89b483f429c47342'.]
Oracle.ManagedDataAccess.EntityFramework.EntityFrameworkProviderSettings.Oracle.ManagedDataAccess.EntityFramework.EFProviderSettings.IEFProviderSettings.get_TracingEnabled()
+0 Oracle.ManagedDataAccess.EntityFramework.EFProviderSettings.InitializeProviderSettings()
+111 Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices..ctor()
+629 Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices..cctor()
+28
[TypeInitializationException: The type initializer for
'Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices'
threw an exception.]
Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices.get_Instance()
+24
The Web.Config has the following blocks in it:
<configSections>
<!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
</configSections>
AND
<oracle.manageddataaccess.client>
<version number="*">
<dataSources>
<dataSource alias="PVMDataSource" descriptor="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=pdxcludds108.pacificorp.us)(PORT=11086))(CONNECT_DATA=(SERVICE_NAME=DDS1086.PACIFICORP.US))) " />
</dataSources>
</version>
</oracle.manageddataaccess.client>
<connectionStrings>
<add name="OracleDbContext" providerName="Oracle.ManagedDataAccess.Client" connectionString="User Id=USERID;Password=WORKINGPASSWORD;Data Source=PVMDataSource" />
<add name="PVMEntities" connectionString="metadata=res://*/Models.PVMModel.csdl|res://*/Models.PVMModel.ssdl|res://*/Models.PVMModel.msl;provider=Oracle.ManagedDataAccess.Client;provider connection string="DATA SOURCE=pdxcludds108.pacificorp.us:11086/DDS1086.PACIFICORP.US;PASSWORD=XXXXXXX;PERSIST SECURITY INFO=True;USER ID=XXX"" providerName="System.Data.EntityClient" />
</connectionStrings>
NOTE: There are other projects working on this server, they're just using a different version of the Oracle client for .Net. None of the others is using only the Managed driver. I am looking for a way to dig into this error, some hint as to where that type is sourced and loaded from.
There is a conflict between Oracle.ManagedDataAccess from NuGet and the one that is installed (by Oracle client installation) on a server and that is registered in GAC.
Unregister Oracle.ManagedDataAccess from GAC and you will get rid of the error: Run command line and navigate to the directory:
{Oracle home}\product\{version}\client_64\ODP.NET\managed\x64
There you should find OraProvCfg.exe file. Run the following command to unregister Oracle.ManagedDataAccess from GAC:
OraProvCfg /action:ungac /providerPath:Oracle.ManagedDataAccess
You have to remove the Oracle.ManagedDataAccess assembly in your GAC (C:\Windows\Microsoft.NET\assembly...)
Use the command tool gacutil to remove the assembly:
C:\Program Files (x86)\Microsoft SDKs\Windows\YOUR_VERSION\bin\NETFX
4.6.1 Tools> gacutil /u Oracle.ManagedDataAccess
Was able to fix it by replacing references in the project to Oracle.ManagedDataAccess and Oracle.ManagedDataAccess.EntityFramework from those installed by the package manager to those installed by the oracle client installer. The versions are the same but the build number is different on those DLLs
As others said you need to remove Oracle.ManagedDataAccess from GAC.
I run {Oracle home}\product\12.1.0\dbhome_1\ODP.NET\managed\x64\unconfigure.bat and {Oracle home}\product\12.1.0\dbhome_1\ODP.NET\managed\x836\unconfigure.bat and it worked
We had the exact same problem as Dylan above. The issue appears to be with that specific Oracle version (4.121.2.0).
The solution was simple: Just go into Nuget and move up to the next version of your Nuget package for the Oracle.ManagedDataAccess.Client, 4.122.1.0.
Once we did that we could have mixed Oracle client or no-client environments or servers with or without the GAC Oracle installed, keep older apps that still use the GAC, and add new projects that use the Nuget packages. Its always a bad idea in these blogs to ask people to uninstall legacy stuff - like remove the Oracle dll in the GAC on a server - when you have environments with many legacy dependancies that still might reference it.
If removing the DLL from the GAC is not an option, consider getting the next version of oracle.managedData.access 12.2.1 and just put them on the server in the bin directory.
Afterwards you need to add an assemblyBinding to your web.config file.
This way you get arround pulling the 12.1.2 version from the GAC during runtime that will case the error.
You do not need to recompile your app against the new version.
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-12.1.2.0" newVersion="12.2.1.0" />
</dependentAssembly>
There is definitely something weird with this issue. I was developing an app on my local server which ran fine but got this error when I uploaded the app to our server. The server has oracle client installed. After looking at this thread I copied the two DLLs (Oracle.ManagedDataAccess.dll & Oracle.ManagedDataAccess.EntityFramework.dll) from within oracle client and replaced the versions in my app bin directory. That fixed the issue.
In my scenario, i have a console application consuming a class library database utility.
I had to reference the Oracle.ManagedDataAccess also on the console application so it can find the dll on runtime.
I don't know if this is the best approach, but worked for me.
good afternoon
I want to share how I solved this same error:
I started by starting visual studio 2019 cmd as administrator.
I ran the following command line in cmd: gacutil -u Oracle.ManagedDataAccess
Basically this command line will remove the Oracle reference from the GAC (Global Assembly Cache), this way it will only get the reference from the package that is in the project (which nuget installs) and not from the oracle client.
You need to install the Oracle Client drivers. The .NET packages don't contain them; they provide a translation from the managed world to the unmanaged. The drivers are in the unmanaged world and need to be installed properly.
After upgrading mvc nuget package from version 5.1.0 to 5.2.2 our machine (webrole) on Azure refuses to start the web role. It was in recycling state. I found an error in event log :
The description for Event ID 1007 from source Windows Azure Runtime 2.4.0.0 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
820
WaIISHost
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=5.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)
File name: 'System.Web.Mvc, Version=5.1.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)
the message resource is present but the message is not found in the string/message table
I tried to search over the internet, but with no useful answer.
I wasn't able to solve it otherwise than downgrade. Luckily package version 5.1.1 is working.
Update 1:
After some trial and error I found, that asp.net mvc packages are OK up to version 5.1.3
It looks like packages from 5.2.0 upwards are not supported.
Update 2:
We have decided to split our web and web.api, so I didn't have this problem anymore. My best guess is, that there was indeed nuget, which was referencing older asp.net mvc package.
I had a similar problem. We inherited a project and updated the ASPNET MVC version to 5.2.2.0. We couldn't deploy to Azure. The only error we could find was the one you mentioned here.
We corrected every web.config file so older versions were redirected to a newer version but we still had the same problem.
Then we wrote a small test method that iterated over every Assembly and we saw that one NuGet package was still using Asp.net MVC 4.0. This package was an old version and hadn't been updated for a while. I downloaded the source, updated the Mvc Nuget and manually inserted the dll.
We deployed again and everything went flawless.
Here is are test method.
private void TestAssemblies()
{
var allAssemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly item in allAssemblies)
{
PrintAssembly(item);
}
}
private void PrintAssembly(Assembly assembly)
{
foreach (var item in assembly.GetReferencedAssemblies())
{
if (item.FullName.Contains("System.Web.Mvc"))
{
Debug.WriteLine(item);
Debug.WriteLine("Parent: " + assembly.FullName);
Debug.WriteLine("------------------------------------------------------------");
}
}
}
MVC 5.2.2 works perfectly fine in Azure. Your role recycling is most likely an indication that either you have not properly deployed your application properly or that you have a hidden dependency on an older version of MVC that a binding redirect may not handle.
I would strongly suggest that you read all of the entries in Kevin Williamson's great series on trouble shooting Azure deployments.
There are a ton of things that can go wrong, so rather than try to create a generic one-size-fits-all list, review the blog posts and then post a comment if you are unable to figure out what specifically is happening.
Given the error that you did post, assuming you have the proper binding redirect that #Yishai Galatzer mentions, you might have a DLL in your deployment that has a hidden dependency on MVC 5.1.0.0. I would suggest using a program like Jetbrains DotPeek to inspect all of your DLLs in your package and look at their references. I suspect you'll find one that itself depends on 5.1.0.0.
I have also face similar problem with mvc5.2.2 azure deployment..
the ultimate solution is we need to add this web.config
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
</dependentAssembly>``
From the looks of it, looks like you are missing a binding redirect to MVC 5.2.2 in your web.config. This should just work.
We are working on verifying this scenario. But let us know if this works for you. In your web.config please take a look at the following section, and makes sure it matches with this xml below:
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
</dependentAssembly>
I had exactly similar problem couple of days back. Please refer to this post.
You need to add <dependentAssembly> section to WaIISHost.exe.config which is generally # 'E:\base\x64' on your VM.
Many times I've found the problem to be in the ~\Views\Web.config file. It keeps a reference to the old MVC version. Just manually update it.
If that doesn't work do a full text search of your solution in Sublime Text or some other tool outside of VS and search for the version string causing you issues.
I had the same issue, where it worked fine on my Dev machine, but when deployed I was getting the assembly error. To resolve this, I had to change the "oldVersion" from version 0.0.0.0 to version 1.0.0.0
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
</dependentAssembly>
To
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
</dependentAssembly>
I am using visual studio 2010 ultimate. I have got the following error when I try to import a dynamic data linq to sql website project on my computer:
------ Rebuild All started: Project: C:...\TestVersion99Website\, Configuration: Debug Any CPU ------ Validating Web Site Building
directory '/TestVersion99Website/App_Code/'. Building directory
'/TestVersion99Website/DynamicData/Content/'. Building directory
'/TestVersion99Website/DynamicData/FieldTemplates/'.
C:\Users\Test\Documents\Visual Studio
2010\WebSites\TestVersion99Website\DynamicData\FieldTemplates\MultilineText_Edit.ascx(7):
Build (web): Could not load file or assembly 'System.Web.DynamicData,
Version=99.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system cannot find the file specified.
... C:\Users\Test\Documents\Visual Studio
2010\WebSites\TestVersion99Website\DynamicData\FieldTemplates\Text_Edit.ascx(7):
Build (web): Could not load file or assembly 'System.Web.DynamicData,
Version=99.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system cannot find the file specified.
Validation Complete
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
The website was written using .net 3.5 sp1 framework. The System.Web.DynamicData assembly was from DynamicData 4 preview project from codeplex.
To identify the error, I have created a new dynamic data linq to sql website project using .net 3.5 framework. Once the website is built, I removed the reference to "System.Web.Dynamicdata 3.5.0.0". I created a new Bin folder, and copied the assembly "Microsoft.Web.Extensions 99.0.0.0, System.ComponentModel.DataAnnotations 99.0.0.0, System.Web.DynamicData 99.0.0.0" into the Bin folder. I then made sure that in web.config the assembly versions are changed to 99.0.0.0. However, When I tried to build the solution, I still had the same error messages. I have no idea why this is happening and am really really very frustrated.
Check for any bindingRedirect you have in your web.config.
<dependentAssembly>
<assemblyIdentity name="System.Web.DynamicData" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="3.5.0.0" newVersion="99.0.0"/>
</dependentAssembly>