Support VBCSCompiler being compiled with --self-contained (or equivalent)

[khyperia]

Seems like @jaredpar is the one who touches this file the most, hi!

When building vbcscompiler (and presumably csc and vbc too) with dotnet publish --self-contained, we should prefer to use that version first.

The File.Exists is really nasty and I'd love to do that another way, but I'm not sure how. There's other uses of File.Exists in the vicinity, though, so it might be okay?

roslyn/src/Compilers/Shared/BuildServerConnection.cs

Line 415 in 0e10735

if (!File.Exists(serverInfo.toolFilePath))

---

(the reason we need to do a --self-contained publish is because the license for the windows dotnet sdk build explicitly disallows redistribution, so it's much easier to use the dotnet bundled with a self-contained app)

[jaredpar]

Small comment on the choice of "standalone" as a name prefix here.

This will eventually impact more than standalone projects. The default starting in netcoreapp3.1, maybe netcoreapp3.0, is to produce a native executable beside the tool dll. For example the build of VBCSCompiler.csproj should natively produce VBCSCompiler.dll and VBCSCompiler.exe on windows.

That is disabled for the moment via 5184394. Eventually though we are going to start producing these native app host binaries again. Probably as a function of building our installers in the https://github.com/dotnet/core-sdk repository. The native app host binaries are advantages because it means in the process list you see VBCSCompiler.exe not dozens of dotnet.exe processes.

That being said this is the right change to make. It will work for both the standalone case as well as the native app host one. The name "standalone" is specific to one of them though. That being said I can't think of a better name to use here. 😕

[khyperia]

Maybe NativeToolFilePath?

[jaredpar]

That works for me'

[jaredpar]

Seems like @jaredpar is the one who touches this file the most, hi!

Hi @khyperia ! 😄

The File.Exists is really nasty and I'd love to do that another way, but I'm not sure how. There's other uses of File.Exists in the vicinity, though, so it might be okay?

If you've already used git blame on this file then I'm sure it's already labeled me as the guilty party for the other File.Exists. 😄

[jaredpar]

@dotnet/roslyn-compiler for a second review

[richlander]

@khyperia -- can you share the text about SDK distribution you are referring to? Just want to be on the same page. We've had cases where our licenses restrict legit scenarios that we didn't see at the time of license writing. We may be in that spot again.

[khyperia]

@richlander I'm not 100% sure on the exact legalese (I wasn't the one who made the "we can't use this" decision), but I think it's this section of the LICENSE.txt included in the both the .net core sdk download and .net core runtime download (only the windows version), from here https://dotnet.microsoft.com/download/dotnet-core/3.1 :

MICROSOFT SOFTWARE LICENSE TERMS
MICROSOFT .NET LIBRARY
[...]
You may not [...] transfer the software or this agreement to any third party.
DISTRIBUTABLE CODE. You may copy and distribute the object code form of the software [... but ...] you must add significant primary functionality to it in your programs

I'm guessing the windows download is not MIT (which the mac and linux downloads are MIT) due to:
https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/copyright.md

There are some cases where that isn't possible because a given component includes a proprietary Microsoft binary. This is typically only the case for Windows distributions.

Our use case is that we (Unity) obviously need to ship the compiler to users, and so, it seems like we can't bundle the runtime as a simple copy of the sdk download.

[richlander]

Like I said, we've been using this particular license for a long time and it works well for some things and then we discover it doesn't work well for others. This isn't the first time we've had to update this license.

I recommend we take this offline (you can mail me @ rlander@ms). I want to better understand what Unity wants to accomplish (not workarounds) and then we'll ensure the license allows for that.

[jaredpar]

Irrespective of how the license plays out I do want to take this PR forward. Standalone is a valid use case (even if it's one we don't actively support). But we definitely will be supporting native app host in the future. This PR solves both.

[agocke]

Welcome back @khyperia! LGTM