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