I have a .NET Core application which is invoked from my NodeJS web application (this .NET Core app is migrated from .NET Framework to run it on a Linux server to perform some specific tasks).
So far it works fine, but every time I overwrite the .dll file (to update the app) all running instances of the app are being automatically shut down without any exceptions or anything. As if I would call Environment.Exit(). All work in progress is gone and the calling NodeJS service is receiving just an empty response.
I don't quite understand the need for that as Linux allows to overwrite the file while it's running...
Probably it's working like this to make sure web servers are restarted if their .dlls are updated. But this behavior is undesired in my case and I hope there is a way to disable it.
Tried to google it up but cannot find anything on the matter.
Thanks in advance for any advices :)
I've ended up with writing some kind of shadow copy system.
When my NodeJS app is noticing a new version of the .NET Core app uploaded to the server it renames the folder with the current version ('active') to something like 'old' + timestamp, then renames the new version to 'active'. It is blocking any attempts to launch the app while this renaming process is happening.
This approach helped to completely solve the issue.
The deployment of an Azure Statefulservice is failing with the following output:
Service Status:
fabric:/Cloud.Application/MyServiceStateless is ready.
fabric:/Cloud.Application/MyServiceStateful is not ready, 1 partitions remaining.
Something is taking too long, the application is still not ready.
Finished executing script 'Get-ServiceFabricApplicationStatus'
This is strange since no other member of my team has seen this problem. To help diagnose it, I set a breakpoint at Program.Main(), but the breakpoint was not hit. Instead, the message "The breakpoint will not currently be hit. A copy of Program.cs was found in StatelessServiceXYZ.exe, but the current source code is different from the version built into StatelessServiceXYZ.exe" when the mouse is hovered over they whited out breakpoint circle. This indicates the assembly isn't loading.
Because no one else can reproduce this problem even though our environments are seemingly identical (we're all using Visual Studio 2017, Microsoft Azure ServiceFabric CoreSDK, .Net Frameword 4.5, and Windows 7), it appears there is some configuration difference or problem with my machine. The other solutions to this problem that I've found online, such as lack of disk space, etc., are not applicable to my situation. I've also tried resetting the local cluster to no avail. Deploying a test StatefulService also worked.
I find a similar issue in the github. if updating the netcore runtime is acceptable, you could have a try to update projects to the 2.0.3 runtime service.
This is the strangest programming issue I have seen in a long time.
I am using Microsoft Visual C# 2010 Express, C# and .NET 2.0 to develop an application. This application references a couple of dll/assemblies (those dlls are all generated on my machine).
Below is part of the code (it is all basic stuff):
public class PowerManagement
{
[TestCase]
public void PrepareTest(){
// Configure according to pre-conditions
Preconditions precondition = new Preconditions();
precondition.SetupPreconditions();
...
}
[TestCase]
public void PerformTest(){
TestcaseData testcaseData = new TestcaseData();
// Set Trigger and perform check
switch (testcaseData.triggerNumber){
case (1):
if ((new Trigger1(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
...
case (4):
if ((new Trigger4(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
default:
Report.TestStepFail("Not yet implemented");
break;
}
}
}
This application is then generated into a dll from Visual C# 2010 Express and used elsewhere and all is fine. The problem surfaces when I add another case to the switch-statement above (see below)
...
case (4):
if ((new Trigger4(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
case (5):
if ((new Trigger5(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
default:
Report.TestStepFail("Not yet implemented");
break;
I can still build without a single issue and generate the dll but when I use the generated dll I get the following error:
A .NET exception (InvalidProgramException) occured in the module PowerManagement
Error message: Common Language Runtime detected an invalid program.
Throwing method: PowerManagement.PerformTest
(the issue happens even if I copy case(4) and paste it as a new case, so it has nothing to do with Trigger5-class)
What is happening here? I have looked through the other InvalidProgramException and Common Language Runtime in Stackoverflow but none seemed related.
I know this issue is strange so please let me know and I will provide more information. I am using a 64-bit Windows 8 machine, if that matters. I have already checked for any updates on VS and .NET updates. I havet also regenerated all the dlls a couple of time ans also created the solution from scratch a couple of times.
Just wanted to add my experience for this...
In my case, I am hosting my C# Web API on Azure and I encountered this message when trying to log in to my API.
I had to go into my Azure management portal (portal.azure.com), go to App Services, choose my Web API program and click Restart from the Overview screen.
After this, the program worked as normal again.
Did not find any further clues in my logs.
I finally managed to solve this issue.
I unchecked code optimization in C# Express and that solved the issues. Still the weirdest thing, but since we are using old tools and framework we can not really blame anyone.
Try enabling 32-bit applications in your application pool advanced settings.
I had this problem after upgrading to Visual Studio 2017 v15.8.6. The problem went away when I removed the assemblyPostProcessorType attribute in the compilation tag in web.config.
According to MSDN: "Generally this indicates a bug in the compiler that generated the program."
I would start by making sure you have all the updates installed on Windows, .NET and Visual Studio.
You should also check out Q312544 on Microsoft Support.
I've occasionally encountered this error after a deployment to an Azure WebApp using MSDeploy. The error has always disappeared after redeploying for a second time.
Our build and deployment are two different steps, the the redeployment is sending over the exact same files each time - this suggests the problem is not uniquely a compiler issue as suggested elsewhere in this question's responses.
Could be a bug in MSDeploy, or in the version of IIS used for WebApps in Azure perhaps...
Such problem could be caused by bugs in tools manipulating the IL of assembly after compilation, for example if you are using Fody and its plugins. At least there is a bug in Fody MethodDecorator which causes such effect, see
https://github.com/Fody/MethodDecorator/issues/8
If you are having this issue specific to Azure Web Apps - check for installed extension Microsoft.ApplicationInsights.AzureWebSites - or it's friendly name Application Insights extension for Azure App Service and remove it via kudu.
We found this extension was potentially interfering with msdeploy pushes - there was a process snapshotholder_x64.exe running under the IIS w3wp.exe process. Someone likely enabled this extension via the azure portal.
If your issue pertains to a web api dotnetcore deployed to an azure app then this could be caused by application insights. Setting the application insights at the blade level should fix the problem. Also note that there seems to be an unresolved issue with setting it at the blade level as recommended settings vs basic. Basic being the value that works.
Running into this issue deploying a Web Api as an API App on Azure. An initial request to any endpoint would result in the expected response; however, subsequent requests would return the same Common Language Runtime error. I figured out the problem started when I enabled Recommended collection level on the Application Insights blade on my web app. I set recommended and enabled all radio buttons. Reverting this change stopped the error. For reference, the API I am running is running Microsoft.ApplicationInsights 2.8.1
For reference:
https://github.com/dotnet/coreclr/issues/18323
I was doing some powershell automation in a console application using .net core 3.0 when i started receiving this error. I guess .net core is not compatible with System.Management.Automation so i changed it to .net framework 4.7, everything worked well after that
I resolved this issue by doing the following:
Rename C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.exe to C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.exe.broken
Rename C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.legacy.exe to C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.exe
Rebuild the solution
-uncheck "code optimization" (referenced dlls included)
-Upgrade to .net framework 4.6
Out of nowhere we started getting XXX webservice Exception , System.InvalidProgramException: Common Language Runtime detected an invalid program.
Copied compiled website to a different environment - works just fine.
Copied to a different server - works just fine.
I noticed that this exception started when server was reset (either rebooted or app pool reset). When researching this issue, I noticed comment by Brian Reichle on Jun 6 '16 at 12:33
I would expect a bitness mismatch to result in a
BadImageFormatException rather than the InvalidProgramException
described in the question.
I was not familiar with InvalidProgramException exception but I was familiar with BadImageFormatException and the symptom is very similar to the one I get with BadImageFormatException issue. I can't say 100% why either exception happens, current running theory is its a 32-bit application running on a 64-bit machine, but we couldn't prove it nor could we perma-fix it. Enabling 32-bit applications on app pool did not fix the issue.
The only fix we know of, albeit temporary, is to simply recycle App Pool. No need to recompile or anything. Luckily, this happens not too often, maybe once a month or two.
I just ran into this problem myself. Even though VS created the virtual directory for me, it had vb as the default language, but I have a C# application. Changing this setting solved it.
This is an interesting exception that i came across while hosting on IIS. I solved it after finding out that my .NET Framework version on IIS was different from the .NET Framework version that my project was using. Please note if you happen to have other referenced projects/ddl(s) make sure you update their .NET Framework version too.
In my case it was Hasp protection (google: hasp sentinel protection key) SW which ruined the dlls.
To share my experience: had the same issue on x86 computer with my WindowsForms app, found out I've forgotten to copy .exe.config file with all dll redirections, after that everything worked like a charm.
In my case, the exception was caused by datadog tracer after upgrading from 3.1 to NET 6, by upgrading to their latest version, the issue was fixed.
Here is the diff in my dockerfile.
-RUN curl -LO https://github.com/DataDog/dd-trace-dotnet/releases/download/v1.12.0/datadog-dotnet-apm_1.12.0_amd64.deb
-RUN dpkg -i ./datadog-dotnet-apm_1.12.0_amd64.deb
+RUN curl -LO https://github.com/DataDog/dd-trace-dotnet/releases/download/v2.14.0/datadog-dotnet-apm_2.14.0_amd64.deb
+RUN dpkg -i ./datadog-dotnet-apm_2.14.0_amd64.deb
https://github.com/DataDog/dd-trace-dotnet
I have a .net win app that seems to work for all our of test machines but the client is getting this error after installation. So the install seems to be working but the app running creates an issue.
The exception unknown software exception (0xc06d007e) occured in the application at location 0xfd96aa7d
Any ideas how to fix or troubleshoot without going back to the customer for techie debug
Idea for troubleshooting - there may be an entry in Administrative Tools->Event Viewer (look inside Windows Logs->Application) that could help you narrow down the reason for the failure.
The issue was that some of the resources where being blocked by the end user downloading from the web. FTP solved it
All,
I have a console application which is written in .NET 3.5 which retrieves data from a database, does some calculations and post messages in a message queue.
I run the .exe on my PC which runs without any problems. Deploying the .exe in a 64 bit server the application suddenly stops without any errors and when I use the DebugView utility I can see the below error.
[6276] Fatal Execution Engine Error (7A09C12F) (80131506)
I tried compiling with x64, x86 and Any CPU but still the same problem. I tried deploying to another server and still same situation. Anyone has an idea how I should proceed to determine the root cause?
Many Thanks,
MK
Capture a crash dump and analyze it for the root cause.
Link
If you like, open a support case via http://support.microsoft.com