[sundarurfriend]

I was going to ask what the multiplatform deployment story was like, it seems like you've partially answered it - it seems like you ship it with .NET Core as a dependency, kinda like JRE for Java programs?

How heavy of a dependency is it?

And is there a dependency hell situation, if different programs require different versions of .NET Core?

[int_19h]

There are quite a few knobs there. You can AOT-compile the bytecode, as well, and you can ship the whole thing as a single binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

Size very much depends on what you actually use in the app, but on the order of tens of megabytes.

[ethbr1]

Also, one of the major changes in the Framework -> Core (now just .NET) shift was making it legally permissible to redistribute the runtime?

So you can ship .NET code with a .NET runtime all in your installer.

Afaik, Framework was only distributable from Microsoft.

[telgareith]

Nope, have always been able to ship the redist installers. Just like VC++. https://www.microsoft.com/en-us/download/details.aspx?id=21 (scroll down to 'Installation Instructions')

After all, not being able to ship the runtime with the software to buyers would have been... Bad. In the early '00s

[ethbr1]

I think I was getting a few things conflated. Is the following correct?

You can't run .NET Framework applications without a system install of .NET Framework.

You can absolutely run .NET (ex-Core) applications without a system install.

[neonsunset]

The state of .NET Framework is that it's packaged with Windows so technically it did not require an install - an OS shipped with it.

The state of .NET is something that Java wants to reach in a few years or so. There are basically three ways to deliver an application to the users:

- A single or multiple files containing .NET assemblies and a thin binary launcher (single-file mode controls the exact shipping of this) - this is similar to OpenJDK which requires a runtime to be installed on the system (except OpenJDK does not have the capability to put all assemblies into a single file with a small native section for the launcher).

- A single or multiple files containing .NET assemblies and runtime itself

- A single native executable compiled with NativeAOT

The first two options allow to "merge" assemblies into a single file or ship them separately.

Shipping just .NET assemblies without runtime takes the least amount of space but requires a runtime dependency (it's easy to install on practically any system).

Shipping assemblies + runtime can also be done as a single file where there's a sandwich of native code and .NET assemblies. In order for such executable to not take disproportionate amount of space (65-120+ MiB) it can be trimmed which is recommended - this reduces base binary size down to 10 MiB or less nowadays (and grows as you add dependencies).

And building with NativeAOT relies on the same linker-based trimming but produces a single native statically linked executable. This results in the smallest runtime-independent binaries (they start at about 1-1.2MiB) with the best startup latency but comes with a different performance profile when compared to JIT and is not compatible with features that either rely on JIT or on unbound un-analyzable reflection where ILLink cannot determine the exact scope of code that has to be compiled. The ecosystem has significantly improved since the introduction of this target in .NET 7 to provide users with tools to make their code compatible, if any changes are required at all.

[pjmlp]

Java has been there for years as well.

AOT compilation has existed for about 20 years, it only happened to be a commercial product, Excelsior JET, Aonix, PTC, Aicas, are some examples.

What GraalVM, OpenJ9 bring to the table is free beer AOT compilers, and in GraalVM's case, a LLVM like compiler framework that doesn't exist at all in .NET land.

They also have the advantage of using agents to gather the required reflection data, instead of forcing an ecosystem split of having to rewrite existing libraries to make them AOT ready.

There was the Phoenix project from Microsoft Research, which had the goal to replace Visual Studio infrastructure with a CLI based compiler toolchain, but unfortunely that project failed to gain traction within Microsoft.

Shipping runtimes, which .NET Core introduced for .NET, has been a thing in Java land since they exist.

There is also the ability to create single executables, coupled with jlink and jpackage.

Besides OpenJDK offerings, there is a richness of JVM implementations, each to those having other capabilities, like OpenJ9 and Azul with their distributed JIT compiler for example.

.NET is great and I prefer .NET to Java consulting projects when given the option, however it is no accident that Microsoft has decided to become again a Java vendor as well.

[int_19h]

For .NET Framework, you are indeed correct, but in practice this was treated largely the same way as e.g. C++ runtime libraries - you just bundled the .NET runtime with your installer.

This has been moot for a long time now, though, since Windows has shipped with some version of .NET preinstalled since Vista.

[SideburnsOfDoom]

> it seems like you ship it with .NET Core as a dependency, kinda like JRE for Java programs?

Pretty much yes. (there are also other ways to bundle it)

It's not even called ".NET Core" any more, it's just ".NET", which for version >= 5.0 effectively is the successor to cross-platform .NET Core.

.NET 9.0 will be out shortly - The annual release is expected November 2024, likely this week.

[CharlieDigital]

Imagine how much better the branding would be if they had just called it:

    > dot
    > dot console apps
    > dot web API
    > dot desktop apps

Simple logo design.

CLI commands would be like:

    > dot new console
    > dot build
    > dot run
    > dot publish

(Yes, I know I can alias)

It's not too late, Microsoft!

[abhiyerra]

It is basically the same as any cross platform language now. They even recommend Docker containers for deployment.

[pjmlp]

JRE for Java isn't a thing since Java 8, the official way is to use jlink to create a custom runtime, make use of jpackage, or AOT compile.

You may still find some JREs, which are created by some distributions that take the stuff out of the JDK to make classical JRE, though.