Being able to make a portable build of the software you are creating is such a basic feature it's baffling you have to fetch extra data to do that. Also nowhere in "dotnet publish -o ./publish -r win-x64" I said "Connect to the internet and fetch megabytes of binaries"
What I miss is the old model for installing software. Give me the yearly ISO, optionally provide a service pack or two if some huge problem went under the radar in testing.
`dotnet publish` performs an implicit `dotnet restore`. So, yes, you did.
If you don't want it to download anything then you use the `dotnet publish --no-restore` flag, which is used a lot in CI/CD pipelines. If you don't have the package dependencies cached it will then simply fail.
The opposite side of that coin is a required up-front install of every package that might ever be needed for every possible scenario... in which case people would complain (even more) about massive installs.
The internet exists, the industry has evolved, software has dependencies, and yes you have to download them (just like you had to download the SDK ISOs back in the day). But it's just one command, run it and get it over with, and after that up-front one-time pain you'll have a nice offline workflow.
I'm not OP, so interpreting: I don't think OP is asking for an up-front install of every package under the sun that might ever be needed for any kind of development. He's just asking that, out of the box, the build tools can build software with no dependencies into an executable without having to hit the Internet. And, if he has particular dependencies he needs, allow him to download them (ONCE) onto that machine, and again, he can build software into an executable without having to hit the Internet again. This doesn't seem that unreasonable a request. Every other compiler I've ever used has had this feature. It wasn't even a feature. It's just the way software has always worked.
I should be able to take my computer to a remote cabin with no Internet, and use all the software on it. The only software I'd expect to not work is software whose purpose is to access data stored on the Internet, like web browsers. I don't think this is such a crazy user expectation.
> make a portable build of the software you are creating is such a basic feature
That is easily doable. However users often don't want a copy of a large runtime for each and every program they use, so it often makes sense to move common things (like DLLs, runtimes, your OS) to libraries that can be shared.
You can easily make dotnet apps in either flavor to your liking. And not every developer is going to make their apps to appeal the your needs.
What I miss is the old model for installing software. Give me the yearly ISO, optionally provide a service pack or two if some huge problem went under the radar in testing.