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

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?

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 5
Comments: 38 (15 by maintainers)

Commits related to this issue

Extract bitshift helper code, Frame cleanup #2773 — committed to dotnet/aspnetcore by Tratcher 6 years ago

Most upvoted comments

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.

mcurko on Apr 5, 2019

disable Transform web config in publish profile

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

guardrex on Feb 19, 2019

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

shirhatti on Aug 1, 2018

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., 🎸 @shirhatti @jkotalik @Tratcher ROCKSTAR ENGINEERS! 🎸].

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 👉

<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.

guardrex on Jan 16, 2018

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.

drobertson123 on Jan 16, 2018

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.
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.

rockerinthelocker on Jan 15, 2018