Making ./build.sh --with... work better

[omajid]

(This is a WIP issue where I am collecting issues that I am running into when trying to use our various ./build.sh --with-.... options on Fedora)

--with-sdk tries to modify a read-only SDK

I tried using --with-sdk with a /usr/lib64/dotnet (that's where the previously built SDK is installed) and the build blows up:

  /home/dotnet/dotnet3.1/dotnet-v3.1.102-SDK/tools-local/init-build.proj(35,5): error MSB3021: Unable to copy file "/home/dotnet/dotnet3.1/dotnet-v3.1.102-SDK/tools-local/tasks/Microsoft.DotNet.SourceBuild.Tasks.XPlat/bin/Debug/netstandard2.0/Microsoft.DotNet.SourceBuild.Tasks.XPlat.dll" to "/usr/lib64/dotnet/sdk/3.1.101/SdkResolvers/SourceBuild.MSBuildSdkResolver/SourceBuild.MSBuildSdkResolver.dll". Access to the path '/usr/lib64/dotnet/sdk/3.1.101/SdkResolvers/SourceBuild.MSBuildSdkResolver' is denied.

It's trying to mutate the copy of the SDK at /usr/lib64/dotnet/ which only root can write to.

TODO

[dagood]

Sorry for butting in, but want to get into this one early:

SourceBuild.MSBuildSdkResolver.dll is a workaround to let us override the SDK package versions of global.json files and specify where to load them from (to avoid package cache). It doesn't seem like MSBuild lets us load it in any other way than putting it in this directory inside the SDK itself:

https://github.com/microsoft/msbuild/blob/acff60145c49281a35fb4492b08d95b19da87495/src/Build/BackEnd/Components/SdkResolution/SdkResolverLoader.cs#L29-L30

@rainersigwald did I miss something?
(It's been quite a while since I implemented the sb resolver, there might also be new things. 🙂)

• We could give up on this: mutate the global.json, get rid of our resolver. We already mutate global.json for other reasons. Avoiding "live" mutations might not be worth fighting for. (Yet?)
• We could add a more user-friendly extension point to the product (or a complete env-based resolver), and patch it in for earlier versions of the SDK to help with N-1 flow.

[omajid]

We could also just copy over the sdk directory before mutating it 😆

[rainersigwald]

@dagood No, installing a resolver does require copying into the MSBuild installation directory. You could copy a different file (a manifest pointing to your resolver elsewhere) but that doesn't really help you.

We could of course add command-line/API surface to change that. Let us know if that would help a bunch; as is I think I lean toward either of the options you're mentioning.

[dagood]

Well, copying over the SDK is the workaround I think we'd go with (transitioning over to use the nupkg flow + nuget.config + global.json is extra effort) so it'd save an SDK worth of build-time disk space to do one of the product-side suggestions.

It looks like this old but popular issue actually covers this request already: dotnet/msbuild#2278.

[MichaelSimons]

[Triage] Related to #1478