Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Thanks for the feedback. We'll take a close look at the feedback here.

We don't have one yet. Hard links ought to work but don't due to the inability to replace a file with multiple hard links atomically.

Can you place the apphost (blah.exe) in the target directory, and symlink everything else?

Can you place the apphost (blah.exe) in the target directory, and symlink everything else?

Well that's what I get for working late; the apphost is 147 KB not 7MB. It will take a day to find out if it works at all but it's not a prohibitive copy.

Oh yes; this only works well if the apphost can tolerate the root dll being swapped out behind its back (which I haven't tried since .net 1.1). Emergency patches are applied to the shared copy and all instances restarted. This is very fast; but depends on the symbolic link tree working as intended.

The change only really affects the load resolution -- so if the app is restarted and it goes through resolution, it will likely find everything it needs next to the app, at which point it will load as it always has. If this worked before (we didn't know people were actually using this in prod!) then I think it should work again.

That said, we would definitely appreciate an update on whether that works for you!

So it passed a preliminary test. I'm surprised this works at all because of the nice line:

                var myjson = typeof(Program).Assembly.AssemblyDirectory() + "appsettings.json";

only ten lines into main. (AssemblyDirectory() is a custom extension method; it's just Path.GetDirectoryName(this.Location) on .NET Runtime targets; on .NET Framework it contains a bunch of junk because Assembly.Location is broken in .NET Framework)

This means the only symbolic link that's being followed is the symbolic link to the executable itself.

So now the instance installer needs to deal with a whole host of issues that used to be impossible that all stem from the same root cause: CopyFile is not and cannot be atomic so it has to handle truncated executables. And I need to ship a list of affected filenames (matching *.exe isn't actually right...) In all ways, very ugly.

And I thought my LD_PRELOAD to fix it on Linux was ugly; this is uglier.

Hilariously if there were a backout switch in *.launchsettings.json I would be able to set it. The launchsettings.json found by following symbolic link out of the exe is the real one. It's the framework dlls that aren't there, as that's a package dependency and resolved as such by the symtree builder.

FYI, based on feedback from users who were depending on the previous symlink behavior, we're considering reverting the change in .NET 9 and returning to .NET 8 behavior in perpetuity.