search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.66k stars 1.06k forks source link

`dotnet build` should not publish self-contained when given a runtime identifier #12616

Closed agocke closed 1 year ago

agocke commented 4 years ago

dotnet build appears to produce a self-contained application when passed a runtime identifier via -r for compatibility with .NET Core 1.0. This looks like it should be publish-specific behavior.

To improve UX here I think we need a much clearer delineation between build and publish. Build should be about producing binaries for running and testing on the local machine. Publishing should be about producing binaries for deploying on other machines.

agocke commented 4 years ago

I propose that we disable this behavior for .NET 5+

agocke commented 4 years ago

@KathleenDollard @marcpopMSFT Do you have any concerns about removing the legacy self-contained publish behavior in .NET 5?

This shouldn't be a breaking change, since users will have to upgrade to net5 explicitly, and the same behavior should be achievable by doing a publish.

pranavkm commented 4 years ago

@agocke would the behavior during build remain unchanged if a project explicitly sets SelfContained=true? Blazor WebAssembly requires rid specific runtime assets are copied to the build output directory for an app to function as part of dotnet run.

agocke commented 4 years ago

rid specific runtime assets are copied to the build output directory

I think this should still happen. That is, if you have runtime-specific dependencies, build should copy them to the output directory for the build. I just don't see why it should do a self-contained deployment instead of a framework dependent deployment. My rule would be: do as little as possible to successfully run on the local machine. Since the native dependencies are necessary even to run locally, they would be copied out, but copying over the entire framework is unnecessary because we, by definition, already have it on the machine.

marcpopMSFT commented 4 years ago

@agocke It's still a change in behavior, just one the customer has to opt into by targetting 5.0. That being said, as discussed offline, I think we agree that build should be for local development and publish for running externally. @KathleenDollard has final say in the matter on. We don't think many people specify a RID on the command line during the build command so this may be low impact.

nagilson commented 1 year ago

It seems like this came up again in our email thread about https://github.com/dotnet/sdk/pull/29031

marcpopMSFT commented 1 year ago

Completed in 8.0.100