Hacker News Reader

Comment by ddek | Hacker News Reader

You can, but I wouldn't. The dotnet CLI contains its own version manager, so you need to have more precise control over the versions of the runtime & sdk you have installed. You can have multiple versions installed simultaneously, dotnet then chooses the runtime based on the project. IME linux package managers mess this up bad.

Fortunately MS provides a better alternative: the dotnet install scripts. [0] Make sure you add the install directory to $PATH.

[0] - https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-in...

View on HN

> so you need to have more precise control over the versions of the runtime & sdk you have installed

Oh, this doesn't sound good at all.

One thing I positively hate about Java is always having to worry about which version of this and that (sdk, vm, headless, etc...) you run on top of. The claim of write once run anywhere has not really happened in my book.

Even C++ is better in that regard these days.

I am certainly hoping the .NET / F# environment didn't inherit that attribute from the Java ecosystem, that'd be a major downer.

My goal is only to learn F# / experiment with it, and I'm certainly hoping never to have to spend a second thinking about "versions of the runtime & sdk".

If you just want to learn, install the latest version of the SDK (.NET 6, currently in RC) and it will be able to build code or reference libraries from every older framework version.

Runtime versions are something you worry about when you are actually deploying / distributing applications.

I did some tinkering with F# this week, and found out you can use this command (even from a Windows desktop):

dotnet build "myproject.fsproj" --runtime linux-x64 --self-contained

...it will compile your project with dotnet bundled together. So you don't need to "install" dotnet on the destination systems running your program.

It worked on some Debian and CentOS/cpanel servers that I have (never installed dotnet on them).

That command alone gives you a whole directory of files that you need to deploy. But I think it's also possible to have to completely bundle all of it into a single file.

I think this guide tells you how to do that: https://www.hanselman.com/blog/making-a-tiny-net-core-30-ent... ... haven't tried it yet though.

It's a shame the CLI doesn't operate more like nvm or sdk man allowing you to download different sdk versions.

It was relatively easy to figure out how to install different versions alongside each other myself after digging into it. The folder structure of the distribution archives is already setup for it after all. After getting it in place it even lets you list and switch between them haha.

That's exactly how the CLI operates though? Maybe I didn't explain it well enough.

The CLI hides the different sdk versions. If you run `dotnet --list-sdks` it will tell you which SDK's you have installed. If you don't have the SDK you need, when you install it it should be placed in the same directory as your other SDKs. Then the CLI will recognise the different versions.

This can all go wrong if you have multiple instances of the CLI installed. That's why I recommend using the dotnet-install scripts from the start, because then you'll only have one instance and you'll be able to manage installed versions.

Unless you mean the CLI downloading the versions itself? I see your point in this case. I think that would be a nice developer convenience. From a production engineering/devops perspective, having the install scripts separate makes it much easier to automatically install the correct runtime.

Reply on news.ycombinator.com