Visual Studio Debug IISExpress with FDE application

[Frankwayne]

At least I think its an FDE application. I have a .exe and I'm using

    <TargetFramework>netcoreapp2.2</TargetFramework>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>

on my Web Application project.

Describe the bug

Moving From an out of process to an inprocess model and uplifting the target framework from .net47 to .netcoreapp2.2 we ran into an issue where we could no longer launch in visual studio to debug via the IIS Express debug profile. We would always get the 500.30 webserver error response. ANCM In-Process Start Failure

event view log
Application '/LM/W3SVC/2/ROOT' with physical root 'C:\Users\A750501\git\csg-hie-broker\Src\Services\HieBroker\' hit unexpected managed exception, exception code = '0xe0434352'. Please check the stderr logs for more information.

exception in visual studio

Exception thrown: 'System.FormatException' in Microsoft.Extensions.Configuration.CommandLine.dll

when trying to run the lines

        public static IWebHost BuildWebHost(string[] args) =>
          WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .UseIIS()
            .Build();

The args array has one entry and the value is below.

%LAUNCHER_ARGS%

To Reproduce

Steps to reproduce the behavior:
1.Create an ASP.NET Core Web Application project
1.Open the .csproj file and add in the win10-x64
under the netcoreapp2.2 node
1.Delete the bin and obj folder and run dotnet restore in the solution directory

1. Add a web.config file with the following content

<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" arguments="%LAUNCHER_ARGS%" hostingModel="InProcess">
      <environmentVariables>
        <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="44320" />
        <environmentVariable name="COMPLUS_ForceENC" value="1" />
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
      </environmentVariables>
    </aspNetCore>
  </system.webServer>
</configuration>

1. update your project references to the ones below

 <PackageReference Include="Microsoft.ApplicationInsights" Version="2.10.0" />
    <PackageReference Include="Microsoft.AspNet.WebApi.Client" Version="5.2.7" />
    <PackageReference Include="Microsoft.AspNetCore.Authentication" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Authentication.Cookies" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.2.5" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Formatters.Json" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Server.IIS" Version="2.2.6" />
    <PackageReference Include="Microsoft.Azure.Services.AppAuthentication" Version="1.2.0-preview2" />
    <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="2.2.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.AzureKeyVault" Version="2.2.0" />
    <PackageReference Include="Microsoft.IdentityModel.Tokens.Saml" Version="5.5.0" />
    <PackageReference Include="Microsoft.Practices.ServiceLocation" Version="1.4.11.0" />
    <PackageReference Include="Newtonsoft.Json" Version="12.0.2" />
    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.2" />

Expected behavior

Be able to launch the webserver in debug mode with IISExpress and hit your breakpoints.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

---Easy Fix---
Remove the
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
node in the csproj file of your web application. This should change it from an FDE application to either SCD or FDD application. (I'm not exactly sure on the terminology)

--- Hard and dirty fix -----

I took some time to debug what was going on in my .vs folder in my applicationhost.config file
I noticed that my virtualDirectory@physicalPath was set to something like

{GitRepoLocation}{ProjectPath}

and not to

{GitRepoLocation}{ProjectPath}\bin\Debug\netcoreapp2.2\win10-x64

I set the value in the applicationhost.config to the correct path which will allow me to edit my web.config file

In my web.config file I update the following values

arguments="%LAUNCHER_ARGS%" to arguments=""

and I'm able to start debugging my application.

of course with this fix you will be updating your web.config every single build.

[Frankwayne]

It also appears to fix this you can use the nuget get reference

<PackageReference Include="Microsoft.AspNetCore.App"/>

but I'm not a big fan of pulling in a bunch of stuff that my application will not be using.

[mjamin]

Ran into this issue as well and it had me guessing for a while. Our application runs a web host when no parameters are passed, otherwise it executes a command and then exits. Since %LAUNCHER_ARGS% is not a valid command in that context it complained and I didn't immediately recognize the error message as coming from our app.

[jkotalik]

@Frankwayne for your specific scenario, do you need to add a package reference to Microsoft.Extensions.Configuration.CommandLine? That may unblock the publish issue near term, however I'd like to clarify some things you are doing.

In general, since 2.1, we recommend publishing your application targeting Microsoft.AspNetCore.App. It guarantees that issues you hit like this won't happen when not targeting all necessary packages.

Also, based on the csproj, I don't think you are publishing FDE, rather SCD (self-contained). The only difference between a FDD and FDE is that there is an exe produced with FDE.

Why do you want to publish your application as standalone (SCD)? In general, we recommend publishing FDD or FDE as it allows the application to get patch updates without having to update the deployment. Especially if you are concerned about deployment size, FDD significantly reduces the size of your app if you are worried about that as well.

Let me know if you have other questions as well.

[analogrelay]

Exception thrown: 'System.FormatException' in Microsoft.Extensions.Configuration.CommandLine.dll

Is there a message associated with the exception at all? This error usually means the arguments couldn't be parsed properly. Could you dump out Environment.CommandLine to somewhere in your program main and see if anything looks suspicious there? (Share it with us if you can?)

[analogrelay]

%LAUNCHER_ARGS%

Oh, hang on. Is this the literal value in the args array? That would definitely cause the exception above. That variable is supposed to be filled in via environment variables when running F5, or during publish.

[mjamin]

Is this the literal value in the args array?

Yup!

[analogrelay]

Adding @BillHiebert for VS thoughts.

@mjamin I'd like to get super clear about what's happening. Does this only occur when you F5-launch IIS Express in VS? What does the web.config look like if you publish to a file system path (via the Publish dialog or dotnet publish)? My suspicion is that it will work in that situation.

It could be the case that VS isn't setting the environment variable properly and that's why the token isn't getting replaced.

[BillHiebert]

What happens if you get rid of the web.config? Unless you need customization, and I don't see any in the web.config above, VS will configure ANCM in the applicationhost.config file it creates for the solution.

[BillHiebert]

I can't reproduce this creating a new Asp.Net core 2.2 application, using the web.config above, and adding the win10-x64 RuntimeIdentifier.

Note that the physical path in the applicationhost.config file should point to the root of the project, not the bin folder.

[Frankwayne]

@BillHiebert You need to remove the packages and use the ones I listed.

[Frankwayne]

@jkotalik

Thanks for the response, you are right its an SCD not FDE. I would have to set the --self-contained false on the dotnet publish command to get an FDE ( just learning about this stuff so thanks for the correction)

we will be moving to an FDD deployment to take advantage of the patch updates. We have also include the .app nuget reference and removed the other ones since we only saw a .1kb size increase of the application dll

this may be a random question, and I havent been able to find any good resources on if dotnet will only pull in the nugets that are used by the applications instead of all of the referenced ones like .Net Framework used to.

[Frankwayne]

@jkotalik

I just tested adding in the package

Microsoft.Extensions.Configuration.CommandLine and it worked like a charm. I'm going to close this case out.

[mjamin]

@anurse I just created a new empty web api project, set a breakpoint in Main and hit F5...

[analogrelay]

Interesting, I get the exact opposite:

I presume you are launching in IIS Express? Can you share the project?

[mjamin]

Yes, IIS Express.

Here's the unmodified template project: WebApplication1.zip

I'd suspect it's a system/setup issue then, though. Maybe previously installed (and subsequently removed) previews of dotnet core 3? Or locale related (de-DE)?

C:\>dotnet --info
.NET Core SDK (gemäß "global.json"):
 Version:   3.0.100
 Commit:    04339c3a26

Laufzeitumgebung:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100\

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  3.0.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Microsoft Visual Studio Professional 2019
Version 16.3.1
VisualStudio.16.Release/16.3.1+29324.140
Microsoft .NET Framework
Version 4.8.03752

Installed Version: Professional

ASP.NET and Web Tools 2019   16.3.283.64955
ASP.NET and Web Tools 2019

ASP.NET Web Frameworks and Tools 2019   16.3.283.64955
For additional information, visit https://www.asp.net/

C# Tools   3.3.1-beta3-19461-02+2fd12c210e22f7d6245805c60340f6a34af6875b
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

[...]

[analogrelay]

Something is indeed fishy here. I can't repro this with a brand new project but I can with the attached project. There's no web.config but there is a .vs/config/applicationHost.config with the following content related to ANCM

<configuration>
  <!-- ... -->
  <location path="WebApplication1" inheritInChildApplications="false">
    <system.webServer>
      <modules>
        <remove name="WebMatrixSupportModule" />
      </modules>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" hostingModel="InProcess" startupTimeLimit="3600" requestTimeout="23:00:00" />
      <httpCompression>
        <dynamicTypes>
          <add mimeType="text/event-stream" enabled="false" />
        </dynamicTypes>
      </httpCompression>
    </system.webServer>
  </location>
</configuration>

@BillHiebert any thoughts here?

[analogrelay]

Deleting the applicationHost.config didn't fix anything.

[BillHiebert]

This works for for me. I unzipped the attached project, added the win10-x64 runtimeIdentfier property and ran the project.
What happens if you run Kestrel rather than IIS Express. Does the output indicate any issues?

[CodingGorilla]

I am running into this same issue with an 3.0 application that was upgraded from 2.2. When hitting F5 within visual studio and testing with Postman I get an ANCM In-Process Start Failure, with a log indicating that %launcher_args% is not a command. Running with dotnet run in the console seems to work just fine.

[analogrelay]

added the win10-x64 runtimeIdentfier property

I didn't do that. That was what the original poster did but I don't believe it's what @mjamin did (this is part of what makes it confusing to post similar issues on closed issue threads 😉)

[BillHiebert]

I couldn't reproduce it either way

[BillHiebert]

Note that ANCM also logs errors to the Windows Event Application logs so you may want to check there. You can also enable Enhanced Diagnostics as described here

[CodingGorilla]

@BillHiebert I enabled logging on the ANCM and the error was similar to the original post. I get:

'%launcher_args%' is not a command. See available commands.

I believe this error is coming from some of my code, which is attempting to look for runtime commands. However, as I understand from this converation, the %launcher_args% should be replaced by visual studio when I launch the debugger. As a short term work around, I added some code to my Program.Main, that filters the args[] for that specific argument.

[analogrelay]

However, as I understand from this converation, the %launcher_args% should be replaced by visual studio when I launch the debugger.

Yes, this is supposed to be happening.

I'll do a quick diff on my machine and see what's different between the attached project (which does repro on my machine) and my File > New project (which does not) and see what that leads to.
@BillHiebert wasn't able to repro with the attached project, which is suspicious to me.

[analogrelay]

I tried this again and can now repro it on a completely clean File > New Project for ASP.NET Core (the ASP.NET Core 3.0 Empty template, specifically).

I'm not sure why this is popping up now and seems to be hard to repro but the problem is pretty straightforward.

For whatever reason, VS launches iisexpress but only sets LAUNCHER_PATH, not LAUNCHER_ARGS. Possibly, this is because it doesn't need to provide any args. In 2.2 and earlier, there were always LAUNCHER_ARGS because the launcher was dotnet.exe and you had to specify the app dll as an argument. In 3.0, the app itself is an exe and there's no need for args.

Since VS isn't setting the variable, when we use ExpandEnvironmentStringsW in ANCM it doesn't expand %LAUNCHER_ARGS% at all and leaves it as-is. This results in the literal string %LAUNCHER_ARGS% from being added to the arguments.

We could consider trying to filter this out better.

@mjamin what I'm not seeing is an error when this happens. Is your site failing with the 500 error described above?

[jkotalik]

@BillHiebert did we stop setting %LAUNCHER_ARGS% if the variable would be empty? That the only thing I can see that would affect this behavior.

[BillHiebert]

@jkotalik Not that I am aware of. If someone could share a repro that would be the best way to debug this.

[analogrelay]

I can consistently repro getting the %LAUNCHER_ARGS% string in args[0] like this:

1. In VS: Create New Project > ASP.NET Core Web App.
2. Choose "ASP.NET Core 3.0" and any template.
3. Set a breakpoint in Main
4. F5
5. Check the value of args[0] in the debugger

I think we know the issue, it's that pre-3.0 the F5 scenario always involved setting LAUNCHER_ARGS because the app you launched was dotnet WebApplication.dll. In 3.0, building produces an exe, so generally there is no need for arguments. VS is just launching WebApplication.exe. As a result, the LAUNCHER_ARGS value isn't set.

It's not clear to me the best way to go forward. I think all the components are working as expected. It sounds like VS is still "setting" LAUNCHER_ARGS, but of course it's setting it to an empty string since there are no args. ANCM is expanding environment variables, which in Windows means that empty vars are just not replaced (Source).

None of the "solutions" I see are particularly clean... I don't know that VS can do anything to "force" the environment variable to exist even though it's empty. For ANCM to do something, it would have to completely rewrite the environment variable expansion (and it would be a risky breaking change).

I've yet to encounter an error in the default template when doing this though. So It may be that the best thing to do here is nothing. As long as whomever is reading the args is prepared to expect this value (and it seems our default template is), the scenario isn't broken.

[mjamin]

At the very least that needs to be documented. And that's going to be a very ugly paragraph. 🤔

[mjamin]

How about removing arguments="%LAUNCHER_ARGS%" from the applicationhost.config when there are no application arguments defined in the project settings? VS already seems to be updating the file on every launch anyway.

@mjamin what I'm not seeing is an error when this happens. Is your site failing with the 500 error described above?

Yeah, but it's the same scenario @CodingGorilla described above. My code tried to parse the %LAUNCHER_ARGS% string as a command line argument, failed, complained and exited which resulted in a 500.30 in the browser.

[analogrelay]

How about removing arguments="%LAUNCHER_ARGS%" from the applicationhost.config when there are no application arguments defined in the project settings? VS already seems to be updating the file on every launch anyway.

@BillHiebert would this be feasible? It seems like the only way to suppress this behavior

@mjamin I'd suggest, for now, adding logic to ignore this value. It's unfortunate but it's going to be a tricky fix.

[analogrelay]

I've confirmed that setting the environment variable to an empty string does not work:

#include <iostream>
#include <Windows.h>

int main()
{
    wchar_t buf[4096];
    auto size = ExpandEnvironmentStrings(L"%ENVVARTEST_FIRST%|%ENVVARTEST_SECOND%|%ENVVARTEST_THIRD%", buf, 4096);
    if (size == 0) {
        std::wcerr << L"Failed to expand strings" << std::endl;
    }
    else {
        std::wcout << L"Expanded string: " << buf;
    }
}

> $env:ENVVARTEST_SECOND=""
> .\x64\Debug\ConsoleApplication.exe
%ENVVARTEST_FIRST%|%ENVVARTEST_SECOND%|%ENVVARTEST_THIRD%

Trying in cmd doesn't even work because set ENVVARTEST_SECOND= is how you unset a variable.

So in general, I don't think there's anything we can do from the runtime/ANCM side to handle this better. Special-casing this feels wrong to me.

I think this might be better resolved as VS Feedback.

[BillHiebert]

@Frankwayne can you open an issue on the VS feedback site for this issue? Thanks.

[Frankwayne]

@BillHiebert My issue was resolved and I attempted to close the case. I have no idea why it continued or the issues that they were trying to work through here on.

[BillHiebert]

@Frankwayne are you referring to an issue you opened on the VS Feedback site? Can you send me a link to it? Thanks.

[analogrelay]

No, @Frankwayne is the original poster and closed this issue earlier. @mjamin was discussing the VS issues here.

In general, let's just say this. For anyone on this thread or who finds this thread and is encountering this problem: Please file a VS feedback item and link it here.

[mjamin]

I opened an issue on the VS feedback site a few weeks ago: https://developercommunityapi.westus.cloudapp.azure.com/content/problem/845413/aspnet-core-web-project-gets-passed-a-launcher-arg.html

[analogrelay]

@mjamin thanks! I've found the internal tracking ticket for that and provided some additional context. We'll work to try and get some progress on it.