If PublishSingleFile=true is set in the project file it changes the behavior of dotnet build and similar

[vitek-karas]

Setting PublishSingleFile=true in the project file has implication on how dotnet build and dotnet run operates which are unexpected.

It will:

• Build as self-contained - this makes the build slower - it requires the RID specific runtime pack (which is not part of the default SDK install) and it copies all of the runtime into output (lot of files and quite large)
• Build for a specific RID (so not portable which is the default without PublishSingleFile=true - the effect of this is that the output is in a different location (the output directory has the RID subdirectory appended to it)
• Use single-file host even for the dotnet build output, but without appending anything to it. Honestly it's surprising this even works at all. It's definitely not intended as the right behavior.

I assume some of this is related to the "RID defaulting" behavior introduced in 7.0, but it's questionable if it's a good behavior or not.
The single-file host is just a bug - we should NOT be doing that under any circumstances.

Note that this has effect on dotnet run which will use the wrong host to run the app. It seems to mostly work, but it's unclear if there are corner cases where it will break.

[vitek-karas]

@VSadov @elinor-fung @sbomer - FYI. Specifically the single-file host issue is something we should definitely look into.

[vitek-karas]

This is likely one of the reasons why dotnet run sometimes just doesn't work at all - see #29658.

[elinor-fung]

I assume some of this is related to the "RID defaulting" behavior introduced in 7.0

Maybe fixed by #29031? I have a recent 8.0 installed and didn't see the building as self-contained behaviour.

Use single-file host even for the dotnet build output, but without appending anything to it. Honestly it's surprising this even works at all. It's definitely not intended as the right behavior.

Wow. Looking at the code, it is working (ish?) because the bundle marker/placeholder doesn't get updated - singlefilehost determines it is not single-file, so tries to run like normal apphost.

[elinor-fung]

Apparently we explicitly check that you can use singlefilehost - updated to embed the managed dll to run, but not marked as a bundle - to run on app:
https://github.com/dotnet/runtime/blob/3f5210dca709def1e1253916e4244c82b2177e9c/src/installer/tests/Microsoft.NET.HostModel.Tests/AppHost.Bundle.Tests/StaticHost.cs#L21-L35

I can't think of the scenario for this behaviour (aside from this issue - where singlefilehost is being used, but we don't want it to be).

@VSadov @vitek-karas do either of you know if there is an scenario for this / why we seem have some attempt at enabling it?

[vitek-karas]

I think this is just history. The test was added when we first build a "static host" which was just apphost with hostfxr and parts of hostpolicy linked in. dotnet/runtime#36230. Since such a host did not have the runtime in it, it made sense to allow it to load the runtime from disk - we basically had to anyway since single-file back then simply unpacked the runtime to disk. Later on we switch to superhost and this behavior makes little sense anymore...

[marcpopMSFT]

We changed a bunch of the default self-contained behavior in 8. Is this still an issue needing investigation? (@vitek-karas @agocke @elinor-fung @dsplaisted )

[elinor-fung]

This is still an issue. The changes to default self-contained made it a bit less egregious (since just setting PublishSingleFile=true won't make it self-contained - users have to actually specify self-contained), but the single-file host is still incorrectly being used for build instead of just publish.

[vitek-karas]

Maybe a bigger change (for 9 only) would be to decouple apphost creation for build from single-file apphost creation. Basically the "publish single file" step would start over with the executable. Completely independent of the build stuff. Although I don't know how complex it will be to wire it up with restore (since we need to download the right singlefile host).

[elinor-fung]

Basically the "publish single file" step would start over with the executable. Completely independent of the build stuff.

This is the only option I could think of at this point. Just trying to detect build vs. publish when choosing the apphost (which was my initial thought) wouldn't be enough, since the publishing for single-file just assumes that an apphost has already been created (stamped with the app assembly) in an intermediate location as part of build - then just takes that and bundles files into it.

Restore: I think currently restore still needs to happen (explicitly or default where build/restore happens as part of publish) for publish to work correctly (single-file or regular apphost). So maybe there wouldn't be extra wiring needed.