Aspnetcore: unable to control web.config processPath and dotnet is not working

[drobertson123]

Looking for advice on a web.config/IIS deploy issue/bug.

I am deploying an ASP.NET core 2.0 based API to an IIS 10 server on Windows Server 2016 using WebDeploy in Visual Studio 2017. It wants to create/overwrite the Web.Config settings I have with whatever Core 2.0 thinks is correct

The issue is that it forces processPath="dotnet" into the file no matter what I do, but that always gives me a 502.5 error. If I add the full path for dotnet.exe everything works fine.

Fails:
<aspNetCore processPath="dotnet" arguments=".\MyServer.Server.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

Works:
<aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\MyServer.Server.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

I have checked all my system paths and permissions but nothing seems to be wrong. This is forcing me to manually edit the web.config file every time I publish because the generated file breaks my server.

Does anyone know what is going on or how to fix this? Alternately, does anyone know how to override ASP.NET core 2.0 generation of the web.config file, specifically the processPath value?

[rockerinthelocker]

Maybe the path to dotnet.exe is not set on the production server? Usually, the installer would add the paths for the x86 and x64 version of dotnet.exe to the 'path' environment variable. However, only the first path found is picked up so the only way to switch between x86/x64 versions of dotnet.exe seems to be via web.config.

So, either add the preferred (x86 or x64) path to dotnet.exe to the 'path' environment variable on the production server or add a web.config file with your preferred settings (i.e. full path to dotnet.exe to use) to the project folder and add the following setting to the project file (i.e. myWebApp.csproj).

<ItemGroup>
  <Content Update="web.config" CopyToOutputDirectory="Always" />
</ItemGroup>

Possible values for 'CopyToOutputDirectory' can be found at msdn.microsoft.com/en-us/library/bb629388.aspx.

[Eilon]

@shirhatti / @jkotalik / @Tratcher - any idea on this issue? Or where it should go?

[drobertson123]

Few updates for everyone on this.

First, dotnet.exe is properly updated, loaded and the PATH settings are correct. I can even use dotnet directly from the command prompt from the root of the website. I have also made sure that the Identity(user) has permission to run dotnet.

The main issue is that for some reason dotnet can't be called as it is being set in the web.config file.

At this point, I don't believe it is a bitness issue, although there may be further issues with that. This seems to be directly tied to having a full path to dotnet.exe in the web.config file.

Works: processPath="C:\Program Files (x86)\dotnet\dotnet.exe"
Works: processPath="C:\Program Files\dotnet\dotnet.exe"
Fails: processPath="dotnet"

But I can call dotnet fine;

F:\WebSites\api.mysite.com>dotnet --info

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

[Tratcher]

Sounds like you haven't rebooted after installing dotnet for IIS to pick up the path change.

[drobertson123]

Sorry, getting a bit tired of hearing that from everyone. This server has been rebooted numerous times during this process.

Plus, if you noticed, to avoid this suggestion I actually copied the output of running "dotnet --info" from the path of the root of my website above. If the path had not been active then this command would not have worked.

Additionally, it is my understanding, but I may be wrong, that changes to the PATH environment variables take effect the first time you browse a folder after saving the change and do not require a reboot to have an effect. So why would a reboot even be needed?

But yes, it has been rebooted. Just to satisfy anyone who is still skeptical I just rebooted again and tested it;

Works: processPath="C:\Program Files (x86)\dotnet\dotnet.exe"
Works: processPath="C:\Program Files\dotnet\dotnet.exe"
Fails: processPath="dotnet"

and when I run "dotnet --info" from the website root directory that does not have a copy of dotnet.exe in it I get this;

F:\WebSites\mywebsite.com>dotnet --info

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

[rockerinthelocker]

Having more details certainly helps to troubleshoot this issue..

1) From cmd prompt.. What does where dotnet return?
2) From PS prompt.. What does Get-CimInstance -ClassName Win32_Product | Select Name,Version | Where {$_.Name.Contains(".NET")} return?
3) Version of Visual Studio (i.e. 15.5.3)?
4) Any error details in the event viewer?

[drobertson123]

Ok, this is something I can get. Note - the website root directory name has been changed to protect the less than innocent.

1. CMD prompt "where dotnet" [didn't know this command existed, thanks]

F:\WebSites\mysite.com>where dotnet
C:\Program Files (x86)\dotnet\dotnet.exe
C:\Program Files\dotnet\dotnet.exe

2.

PS C:\Users\Administrator> Get-CimInstance -ClassName Win32_Product | Select Name,Version | Where {$_.Name.Contains(".NET")}

Name                                                      Version
----                                                      -------
Microsoft .NET Framework 4.5.1 Multi-Targeting Pack       4.5.50932
Microsoft .NET Framework 4.5.2 Multi-Targeting Pack (ENU) 4.5.51209
Microsoft ASP.NET Core 2.0.5 Runtime Package Store (x86)  2.0.12421.0
Microsoft .NET Core Host - 2.0.5 (x64)                    16.20.26021
Microsoft .NET Core Host - 2.0.3 (x64)                    16.12.25816
Microsoft .NET Framework 4.5 Multi-Targeting Pack         4.5.50710
Microsoft .NET Framework 4.5.1 Multi-Targeting Pack (ENU) 4.5.50932
Microsoft .NET Core Host - 2.0.3 (x86)                    16.12.25816
Microsoft .NET Framework 4.5.2 Multi-Targeting Pack       4.5.51209
Microsoft .NET Core Host FX Resolver - 2.0.0 (x86)        16.0.25521
Microsoft .NET Core Host - 2.0.0 (x64)                    16.0.25521
Microsoft ASP.NET MVC 3                                   3.0.20105.0
Microsoft .NET Core Host - 2.0.5 (x86)                    16.20.26021
Microsoft .NET Core Runtime - 2.0.5 (x64)                 16.20.26021
Microsoft .NET Core Host FX Resolver - 2.0.5 (x64)        16.20.26021
Microsoft .NET Core Host FX Resolver - 2.0.3 (x64)        16.12.25816
Microsoft .NET Framework 4 Multi-Targeting Pack           4.0.30319
Microsoft .NET Core Runtime - 2.0.3 (x86)                 16.12.25816
Microsoft .NET Core Runtime - 2.0.0 (x86)                 16.0.25521
Microsoft .NET Core Host - 2.0.0 (x86)                    16.0.25521
Microsoft .NET Core Host FX Resolver - 2.0.0 (x64)        16.0.25521
Microsoft .NET Core Runtime - 2.0.3 (x64)                 16.12.25816
Microsoft .NET Core Runtime - 2.0.5 (x86)                 16.20.26021
Microsoft .NET Core Runtime - 2.0.0 (x64)                 16.0.25521
Microsoft ASP.NET Core Module                             1.0.1989
Microsoft .NET Core Host FX Resolver - 2.0.5 (x86)        16.20.26021
Microsoft ASP.NET Core 2.0.5 Runtime Package Store (x64)  2.0.12421.0
Microsoft .NET Core Host FX Resolver - 2.0.3 (x86)        16.12.25816
Microsoft .NET Framework 4.5.1 SDK                        4.5.51641
Microsoft ASP.NET Web Pages                               1.0.20105.0
Microsoft .NET Core SDK - 2.1.4 (x64)                     8.17.7260

3.

1. Event Viewer Errors - I got two distinct errors that repeated 4 times each. The error was exactly the same each time. This all happened with processPath="dotnet"
   

Application 'MACHINE/WEBROOT/APPHOST/API.OPTIONSEDU.COM' with physical root 'F:\WebSites\mysite.com\' failed to start process with commandline 'dotnet .\OptionsEDU.GraphQL.Server.dll', ErrorCode = '0x80004005 : e0434352.

Faulting application name: dotnet.exe, version: 2.0.26021.1, time stamp: 0x5a3b028a
Faulting module name: KERNELBASE.dll, version: 10.0.14393.1532, time stamp: 0x5965adf8
Exception code: 0xe0434352
Fault offset: 0x000da9f2
Faulting process id: 0x144c
Faulting application start time: 0x01d38d61347496ca
Faulting application path: C:\Program Files (x86)\dotnet\dotnet.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 918131db-cc34-42be-865a-fce7d51f3f8d
Faulting package full name:
Faulting package-relative application ID:

Extra info: I changed bvack to processPath="C:\Program Files\dotnet\dotnet.exe" and it worked fine. This was in the event log.

Application 'MACHINE/WEBROOT/APPHOST/MYSITE.COM' started process '2408' successfully and is listening on port '29247'.

[drobertson123]

Maybe this does lead back to a bitness issue. The DLL is being forced to x64 but it is calling the x86 version of dotnet.

[rockerinthelocker]

1) Indeed, only the first path to the x86 version of dotnet.exe will ever picked up if processPath contains just 'dotnet'. Due to this, ASP.NET Core applications depending on 64-bit require the full path to the x64 dotnet.exe being set in processPath.

2) If you don't require the .NET Core SDK on the production server, you can safely uninstall. Same for previous .NET Core runtimes, hosts, and host resolvers.

No doubt, the ASP.NET Core module could be smarter and pick up the proper dotnet.exe via worker process bitness detection.

[drobertson123]

I think the issue must go beyond just the Path issue and bitness.

I can hard wire in either the x86 path or the 64bit path to the web.config file and both actually work. So the code will actually work using the x86 dotnet.exe version.

This works;
<aspNetCore processPath="C:\Program Files\dotnet\dotnet.exe" arguments=".\mysite.Server.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

and this works:
<aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\mysite.Server.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

but this fails
<aspNetCore processPath="dotnet" arguments=".\mysite.Server.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />

I was just surprised that it defaulted to the x86 version.

What is different in this process if I give it a full path vs just "dotnet" and how do I test that?

[rockerinthelocker]

@coolcsh , Maybe you can have the right people look into this? Thank you!

[guardrex]

@drobertson123 I've been following along. Just wanted to jump in and say 'thanks' for how much effort you've been putting into surfacing this ... whatever it turns out to be. Once we have a handle on the ultimate cause if there's anything I can do in the docs, I'll get it covered for the community going forward.

[drobertson123]

I appreciate the chance to get this sorted out, so I guess we are even. I can probably hard code my way around it with the full paths, but that doesn't feel like the right answer. Just hoping we get to the bottom of this at some point.

[guardrex]

hard code my way around it with the full paths

Ultimately, it shouldn't be necessary. Let's see where it goes.

You have the best eyes on it here [e.g., :guitar: @shirhatti @jkotalik @Tratcher ROCKSTAR ENGINEERS! :guitar:].

Gut feel'in ... Windows OS PATH resolution problem. I can tell you that after a few years of following issues on IIS config that this is a very strange problem. I don't recall one like it in two years.

RE: Stopping the Sdk.Web bits from transforming the file, use this in your project file :point_right:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

... that will permit you to have a custom web.config with your hardcoded processPath and the Sdk.Web target won't change your file ... the Sdk will still move the file from the content root of your project to the published output, but it won't change your processPath.

[Eilon]

Pinging @shirhatti and @jkotalik again.

@drobertson123 BTW it's a 3-day weekend here due to MLK Day so sorry for some of the delay.

[drobertson123]

People need a break. :-)

Wish I had vacation days, but the startup life doesn't give you many days off.

[shirhatti]

Could you try a sample app that dumps all environment variables and share your results?

https://github.com/aspnet/IISIntegration/blob/dev/samples/IISSample/Startup.cs#L68-L73

[rockerinthelocker]

@shirhatti , Would you mind to name the variables you're interested in? Thank you!

[drobertson123]

@shirhatti Is there a PS script I could use to get that info. This is a production environment I am dealing with and running a script would be far easier than loading a test project.

[jkotalik]

@drobertson123 Sorry for the late reply. I haven't seen this happen before.

I was just surprised that it defaulted to the x86 version.
What is different in this process if I give it a full path vs just "dotnet" and how do I test that?

When "dotnet" is specified, we directly will call "dotnet mysite.Server.dll" like you would on command line. As the x86 version of dotnet is the first one on your path, it will be the one use when you type dotnet mysite.Server.dll.

From the feedback, it seems there could be some sort of bitness issue here. Could you try swapping the order of dotnet.exe on your path (such that C:\Program Files\dotnet\ is before C:\Program Files (x86)\dotnet)?

[jkotalik]

Also, when you run dotnet --info, where does it say the runtime environment is?

[shirhatti]

@rockerinthelocker @drobertson123
While a PS script could get that info, I'm more interested in the PATH as observed by the w3wp.exe and dotnet.exe.
I'm also interested in whether in what kind of identity you're running as and whether you've loaded the user profile and if there's another dotnet in the USERPROFILE of the worker process identity which you don't see when you ran where dotnet

[rockerinthelocker]

@shirhatti , Thanks for clarifying! Well, then we certainly can use where /R C:\ dotnet instead to find all locations (outside the 'Path' variable) where dotnet.exe exists on the system; and run the following PowerShell lines (replace DefaultAppPool with the proper application pool name) to get the other details.

Import-Module WebAdministration
$appPool = Get-WebConfiguration '//*[@name="DefaultAppPool"]//.' -PSPath IIS:
$appPool.identityType
$appPool.loadUserProfile

Does it work for you @drobertson123 ?

[glennc]

@drobertson123 Did you work around this for now by adding a web.config to your app? That way you don't actually have to edit it each time you deploy as we will not do the generation.

[Eilon]

Hi. We're closing this issue as no response or updates have been provided in a timely manner. If you have more details and are encountering this issue please add a new reply and re-open the issue.

[poblahblahblah]

We are running into this. Is there a way to just override the processPath so we can just move on? Restarting the computer after installing dotnetcore in an autoscaling situation seems like a non-starter.

[shirhatti]

We are running into this. Is there a way to just override the processPath so we can just move on? Restarting the computer after installing dotnetcore in an autoscaling situation seems like a non-starter.

YES! If you include a web.config with your project, the websdk will not generate a new web.config at publish time.

@poblahblahblah We don't normally monitor closed issues, so please free to open an issue on https://github.com/aspnet/websdk if you're continuing to have problems

[ZombiesWithCoffee]

I have been installing ASP.NET Core 2.2 on an IIS system, and experiencing the exact same issue as the original poster. I'm quite sad that I don't see a valid fix for this issue.

[guardrex]

a valid fix for this issue

The fix is to include a web.config file in the project. Do you have a limitation in your scenario that prevents you from adopting that approach?

[ZombiesWithCoffee]

Frankly, I'd have liked it to have worked without having to search Google for a few days. This is a kludge, not a fix. Including the web.config also isn't enough, you also need to include

<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>

[guardrex]

you also need to include

It depends ... if you need to set the configuration of the <aspNetCore> element explicitly, yes, it must be set because the SDK will overwrite your settings on transformation. However if you just need to add settings to web.config and the SDK can transform normally in the process, it works without that property.

This has been documented in the IIS topic for quite a long time ... https://docs.microsoft.com/aspnet/core/host-and-deploy/iis/#webconfig-file

I'll take another look tho on the next doc update to see if it can be improved ... where it's described and what it says.

[EDIT] I think it can be made a bit more obvious by promoting the web.config section content to an H2 in the topic and thus promoting it to appear in the sidebar TOC. The content itself looks ok.

[taburetkin]

i faced with the same issue, and already spent few hours struggling with this
There is a small thing with web.config approach
i create web.config with hardcoded processPath
disable Transform web config in publish profile
and test how it will deploy. everything good.
but then, i start to develop and rebuild my project with Cntrl + f5 (start without debug)
after that my web.config was completely overriden
with this: <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout"
how can i prevent of overriding my web.config?

[guardrex]

disable Transform web config in publish profile

@taburetkin Disable the transformation _in the project file_ (.csproj), not in the publish profile.

[mcurko]

I had the same problem, and solved it by placing 64-bit dotnet.exe path before the 32-bit one in the system PATH variable on the web server. Though, it's not a path problem by itself, rather it seems that something is parsing the path to be able to launch the correct dotnet.exe.

This problem should be seriously dealt with, everything proposed so far is just a quick fix; programmers will keep spending hours again and again, until this issue is definitively fixed.

[anandmurali]

Thank you @mcurko Your solution worked for me.
I tried hardcoding the processPath but it didn't work for me.

[DocVirus]

I also spent much timr trying all the things mentioned here. But it was a simple server restart after .Net Core installation what helped me in the end.

[llyons]

I had this same issue and it turned out that I had not installed the .NET Core Windows Server Hosting bundle. Once I installed that, the ProcessPath issue in the web.config was no longer an issue.

additional info on this.

https://blogs.msdn.microsoft.com/rohithrajan/2018/03/13/500-19-error-or-502-5-error-when-hosting-asp-net-core-2-application-inside-iis/

[atalpatidar56]

I had exactly the same problem, and I solved it last week. We had 2 ASP.Net Core projects, one showing the issue, the other didn't have the issue.

firstly check C:\Program Files\dotnet path, if sdk folder not available then u need to install asp.net core sdk. if u install this package then problem is resolved. and app is running with <aspNetCore processPath="dotnet" arguments=".\yourapp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout"/>