3 ms·
I agree! With .NET Core 3.x it's possible to publish self-contained executables so there's no need to have to the runtime installed. https://docs.microsoft.co
by felipebueno 6y ago
I agree!
With .NET Core 3.x it's possible to publish self-contained executables so there's no need to have to the runtime installed.
https://docs.microsoft.com/pt-br/dotnet/core/deploying/#publish-self-contained https://docs.microsoft.com/pt-br/dotnet/core/deploying/#publ...
- colejohnson66 6y agoDidn’t .NET (pre-“Core”) have an AOT option? Or was that not “self-contained” (as in, a runtime was still needed prior)?
- fuzzy2 6y agoNot that I know of. When you target UWP, there’s .NET Native. That might be what you’re thinking of. IIRC .NET Native compilation was very slow and could not target…, well, Windows, but only Windows UWP.
- Iwan-Zotow 6y agohe's talking about ngen https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen...
- Iwan-Zotow 6y agoYes, used to be called Ngen https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen...
- WorldMaker 6y agoNgen was never self-contained however and ngen-ed binaries were system and runtime specific. You pretty much had to assume you couldn't ship ngen-ed binaries between machines and always ngen in place on the end user's machine. .NET Core's new AOT systems are much more capable than ngen ever was, including for static, self-contained binaries that you could potentially ship to all systems of a target architecture without shipping the non-AOT IL binaries as well. (ETA: Which is why the vast majority of .NET software hardly ever bothered with ngen except for very specific per-machine performance needs.)
- Iwan-Zotow 6y agoYes, I'm aware of that, we tried to use Ngen and basically gave up, not worth the efforts. I hope new AOT would be better