4 ms·

Yeah, sigh Technically the ".NET initiative" was all about web services. But not the modern kind, it was about SOAP. And I guess also Code Access Security-- a

Yeah, sigh Technically the ".NET initiative" was all about web services. But not the modern kind, it was about SOAP. And I guess also Code Access Security-- a way to run untrusted (and even remote) code securely. Ahem, "securely". The .NET Framework, CIL, and CLI/CLR and it's initial languages, C# and VB.NET, were in support of those technologies, but ended up being the only parts with real staying power. I am a big fan of the .NET Framework (and it's evolution in .NET Core / .NET 5)-- so many rough edges of the Java runtime concepts and Java language concepts were polished, and a lot of new innovations were introduced (proper annotations, a framework for handling code isolation, a better reflection API, real runtime generics in .NET 2.0 and more). There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits. > That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact Firstly, of course C# is used quite a lot within Windows in the user space. I worked on some open source stuff around kernel level C# that was inspired by MSR's work here-- Singularity still used a very small core written in C++ iirc, we were interested in reducing the amount of unmanaged support code as much as possible as well as replacing the unmanaged c++ bits with unmanaged c#. That work grew into SharpOS. There was also a competing project called CosmOS. Lost to time now.

colejohnson66 3y ago
One of the guys who worked on Singularity's successor, Midori, has a nice multipage post-mortem write up.[0] Many design concepts have found their way into C#/.NET in the years since. However, unlike Singularity, Midori's source code was (unfortunately) never released. [0]: https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
Kwpolska 3y ago
> There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits. The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752 https://github.com/dotnet/sdk/issues/24752 The assembly redirection hell has also been greatly reduced there.
- rezonant 3y ago
  Yeah I didn't think it had, but I've not done too much with Core/5+ yet. I want to use it but I end up just using Typescript/Node by default. I do need to get into the habit of investigating using CLR when a bit more performance or lower latency is required, instead of jumping past it to systems level with C++/Rust/Go.
- mycall 3y ago
  There is something similar to the Global Assembly Cache for .NET Core. This allows WSUS to automatically upgrade the .NET runtime installed on the system. https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/ https://devblogs.microsoft.com/dotnet/net-core-updates-comin...
  - metaltyphoon 3y ago
    Thats just framework dependent upgrades. .NET core and beyond allows for side by side installations of with different assembly versions where in .NET framework they shared a GAC.
  - Kwpolska 3y ago
    Not really. You can upgrade the framework with Windows Update, or by just going to dotnet.microsoft.com and downloading the latest installer. Applications can ship their own copy of the framework or depend on the system copy. The framework does include some core/system libraries, but other applications can’t install their crap system-wide (which was possible with the GAC).

colejohnson66 3y ago

One of the guys who worked on Singularity's successor, Midori, has a nice multipage post-mortem write up.[0] Many design concepts have found their way into C#/.NET in the years since. However, unlike Singularity, Midori's source code was (unfortunately) never released. [0]: https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/

Kwpolska 3y ago

> There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits. The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752 https://github.com/dotnet/sdk/issues/24752 The assembly redirection hell has also been greatly reduced there.

rezonant 3y ago
Yeah I didn't think it had, but I've not done too much with Core/5+ yet. I want to use it but I end up just using Typescript/Node by default. I do need to get into the habit of investigating using CLR when a bit more performance or lower latency is required, instead of jumping past it to systems level with C++/Rust/Go.
mycall 3y ago
There is something similar to the Global Assembly Cache for .NET Core. This allows WSUS to automatically upgrade the .NET runtime installed on the system. https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/ https://devblogs.microsoft.com/dotnet/net-core-updates-comin...
- metaltyphoon 3y ago
  Thats just framework dependent upgrades. .NET core and beyond allows for side by side installations of with different assembly versions where in .NET framework they shared a GAC.
- Kwpolska 3y ago
  Not really. You can upgrade the framework with Windows Update, or by just going to dotnet.microsoft.com and downloading the latest installer. Applications can ship their own copy of the framework or depend on the system copy. The framework does include some core/system libraries, but other applications can’t install their crap system-wide (which was possible with the GAC).