Over the last 2 days i twisted my head around deploying my WEB API.
App specification: WEB API .NET CORE 3.0 Preview 4
Firstly i tried to deploy on Azure using App Services.
Seems like they don't support .net core 3.0 but i don't really understand this since you can wrap everything in your package, wasn't this done in order to be deploy-able everywhere ?
When i'm trying to access the websitei get a
HTTP Error 500.0 - ANCM In-Process Handler Load Failure which i didn't managed to fix.
--I tried to do the same with a clean project, still same issue--
Secondly i created a virtual machine (VM) and deploy on VM.
Here i get a internal server error and i cannot debug (any tips are welcome)
Third I deployed on local IIS, here i get the following error:
"Cannot read configuration file due to insufficient permissions"
I added the permissions to IIS_IUSRS but after this i get a infinite loop
--The same i get with the clean project--
Am i doing something wrong , what could i do to deploy my Web Api Project.
The documentation suggests that it is possible to deploy preview versions, although I haven't tried it. This blogger encountered the same problem you did, and resolved it using these instructions. He says:
This document covers two different ways to fix this issue – you can
either install the preview site extensions for ASP.NET Core 3, or you
can simply change your deployment to be a self-contained application.
In this case we’re going to go with deploying a self-contained
application, since this reduces any external dependencies which seems
sensible to me.
So it seems you are correct that building a self-contained package is one way of solving this, but you have to specifically ask for that when you publish.
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.
I have tried to set up continuous integration to deploy my Azure Service Fabric cluster automatically on git push events in Team Services. I followed the default template for a Team Services Build Definition and a Team Services Release Definition based on this guide:
Set up continuous integration for a Service Fabric application by using Visual Studio Team Services
Here are my settings:
For the most part everything works for the first deployment. After that it throws the following error:
An application with name 'fabric:/<APP>' already exists, its type is '<APP>Type' and version is '1.0.0.20160812.7'. You must first remove the existing application before a new application can be deployed or provide a new name for the application.
From that it appears as though it is trying to completely redeploy the service instead of just upgrading the service. I have searched through all of the settings and tried creating and recreating the tasks but have not been able to resolve.
Has anyone encountered this before?
You need to add or update a publish profile to enable the upgrade mode and use that profile to deploy the Service Fabric after the first deployment is succeed.
To do this quickly, you can right click on your project and select "Publish" from Visual Studio, check "Upgrade the Application" option and click "Configure Upgrade Settings" if needed, and then click “Save Profile" link and commit/push the changes.
Though there is an accepted answer, I would still like to add to this thread. In the approach below we need to edit only the Azure Devops Task. Hopefully this will be useful to others who may encounter the same issue: One simple workaround when you encounter this issue is to change the "Overwrite Behavior" under the Advanced Setting for the build task to "Always". However, care must also be exercised so that if there are services which may already be running - all of them do get upgraded via a rolling upgrade (see second image).
To ensure that rolling upgrade is applied to all the services, in addition to the above, also ensure that the upgrade settings are configured as below:
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