3 ms·

In theory exceptions can be easily found with static analysis. I suppose lack of such tools (and failure of code contracts which I think could've verified it st

by marwis 3y ago

In theory exceptions can be easily found with static analysis. I suppose lack of such tools (and failure of code contracts which I think could've verified it statically) means that vast majority of people are happy with status quo. Just an idea - maybe you can use CodeQL? The transition to .NET core is indeed rather painful but it's just Microsoft's choice. Things were dropped/backwards compatibility broken mostly to simplify runtime but I saw nothing that couldn't have been emulated with some modest effort. Also they could've easily softened the transition by continuing development of .NET Standard a bit longer and allowing side by side hosting of 4.x and Core in same process as that seemed to be the plan in the beginning. I guess they don't care.

neonsunset 3y ago
Both this and parent comments are so...strange. If you had any significant experience working with post-"Framework" .NET, you would know that the features that got deprecated were unsound, carried significant performance and complexity cost hindering the efforts towards further platform evolution. And most actually important use cases saw appropriate dev work to provide polyfills and shim packages to provide the path for migration. .NET Standard existed and still exists as a bridge for .NET Framework and "odd" platforms like UWP (effectively dead), Unity and maybe a couple of others - you never know! Fortunately it slowly but surely fades into obscurity as all the actively developed platforms are converging around pure 'net6+'-based TFMs. Special note regarding "being stuck with .NET Framework" - this may be true for some enterprise scenarios but I have grown to adopt a mental model of considering opinions like these as nonsensical or deeply out of touch with reality as much more useful way of dealing with audience that still lives in this camp. It is not worth entertaining, nor it is reasonable to respond to "move fast and break things" criticism after all these years - some people just have a bone to pick, for the pace is "moderate" and there are no changes made like in the early days of .NET Core 1.x and 2.x when the platform's fate was uncertain.
- marwis 3y ago
  Do you consider in-box PowerShell and MS Office to be rare enterprise/nonsensical scenarios? Or how about C# Source Generators that were introduced just few years ago and are stuck on .NET Standard 2.0 because of Visual Studio using .NET framework? There is a lot of actively developed software out there either built in .NET or using it to provide extensibility that is now stuck as you can't add support for .NET Core without breaking all existing plugins. The only alternative is complete redesign with out-of-process architecture which is not going to be compatible and might be inappropriate in some scenarios.

by marwis 3y ago

neonsunset 3y ago

Both this and parent comments are so...strange. If you had any significant experience working with post-"Framework" .NET, you would know that the features that got deprecated were unsound, carried significant performance and complexity cost hindering the efforts towards further platform evolution. And most actually important use cases saw appropriate dev work to provide polyfills and shim packages to provide the path for migration. .NET Standard existed and still exists as a bridge for .NET Framework and "odd" platforms like UWP (effectively dead), Unity and maybe a couple of others - you never know! Fortunately it slowly but surely fades into obscurity as all the actively developed platforms are converging around pure 'net6+'-based TFMs. Special note regarding "being stuck with .NET Framework" - this may be true for some enterprise scenarios but I have grown to adopt a mental model of considering opinions like these as nonsensical or deeply out of touch with reality as much more useful way of dealing with audience that still lives in this camp. It is not worth entertaining, nor it is reasonable to respond to "move fast and break things" criticism after all these years - some people just have a bone to pick, for the pace is "moderate" and there are no changes made like in the early days of .NET Core 1.x and 2.x when the platform's fate was uncertain.

marwis 3y ago
Do you consider in-box PowerShell and MS Office to be rare enterprise/nonsensical scenarios? Or how about C# Source Generators that were introduced just few years ago and are stuck on .NET Standard 2.0 because of Visual Studio using .NET framework? There is a lot of actively developed software out there either built in .NET or using it to provide extensibility that is now stuck as you can't add support for .NET Core without breaking all existing plugins. The only alternative is complete redesign with out-of-process architecture which is not going to be compatible and might be inappropriate in some scenarios.