5 ms·

The difficulty for me as a FT .Net Dev is the pace of development is hurting quality. There are many edge cases and bugs that get introduced as things change fr

The difficulty for me as a FT .Net Dev is the pace of development is hurting quality. There are many edge cases and bugs that get introduced as things change from nuget to dotnet pack, from netstandard to netcore, from net core 3.1 to net 5. Each time, something is breaking which is more often than not "won't fix, just use .net 5". Net 5 isn't even finished and they are already previewing 6? It is usually something like under .net 3.1, the build was fine and then under .net 5, an error happens, "oh yeah, you can workaround that by modifying your project file". Or you try and build in a .net 5 nuget package which means you can also reference an older netstandard 2 package that the developer has decided doesn't need updating because it hasn't changed.

gregmac 5y ago
I agree, though I wouldn't say it's the pace of development so much as the change in approach. .NET Standard made sense as a transition plan, but then was effectively abandoned. I understand that the focus went to .NET 5/6, but the effort is incomplete! Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating. In theory you can also create a project that multi-targets .NET framework and .NET core, but in practice, while I've got this to work, it's an adventure every time and most often I just give up as it's not worth the time-sink. It kind of seems like the official migration path is just "stop everything, port to .NET 5 and you'll be good". But that's not really practical. Indeed, my experience on pure .NET Core (3.1) or .NET 5 has been very good thus far -- including easily building cross-platform native apps. It's just that the reality is there's still a lot of .NET Framework code. The other big challenge for us is in delivering apps that run on customer systems. Doing the switch to .NET Core/5/6 means we have to decide on: increasing from shipping a 5MB to a 45MB app (runtime included); requiring .NET runtime is installed (and handling auto-update failures when it's not); modifying the installer to install if needed (again handling failures). This is all tons of work, and a tough sell when we have a multi-year backlog of bugs and feature requests it has to compete with.
- mycall 5y ago
  > Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating. I'm happy to hear I'm not the only one with this problem. For me, removing assemblies from csproj ended up being the solution to many of these problems (let them load implicitly).
0x0 5y ago
This exactly! The branding and versioning of .NET is a complete disaster. There's .NET Framework (where even simply getting the current runtime version requires several convoluted hoops, since System.Environment.Version has gone the way of browser user agents and frozen itself at "4.0.30319"). Then there is .NET Standard, which was at version 1 and 2 (which are newer than .NET Framework 4.0 or 4.5? but have significantly fewer APIs available, and many classes are missing methods and properties that were present in .NET Framework). Then there is .NET Core which reset the versioning scheme again? Then there is .NET 5 which is newer than all of these, but is it actually fully supported on non-windows platforms? Then you need Newtonsoft.JSON, and then you get to watch your entire project blow up because you have three different dependencies that use different versions of netstandard/netcore/netframework and the assemblies aren't compatible. I really hope going forward there will be just one unified .NET 6 that works the same on all platforms and doesn't need a million different builds of the same nuget package. Edit: And even after all this, deploying your app by just copying the .exe and .dlls to a pristine machine often fails, because the corresponding .NET framework runtime isn't installed. And then you need to be a lawyer to figure out if you can even ship the net framework installer to your customer or how to handle that. You would think Microsoft would have a better story to sell to developers as what should be "the way" to develop and distribute windows executables. It seems like the only way to really be portable is to use an ancient version of Visual C to write win32 directly, and link the corresponding msvcrt statically.
- nightski 5y ago
  Yes .NET 5 is supported on all platforms. It is the future of .NET Core. They dropped core because they wanted to make it clear it is the one true dotnet going forward. It actually will greatly simplify things going forward. .NET standard will no longer be necessary because there is only .NET 5 onward. You don't "need" Newtonsoft.JSON. .NET now has a built in serializer which is much faster. But for compatability and some more advanced scenarios some people still need/prefer it. Lastly .NET core apps (and .NET 5/6 going forward) have an option to produce a single file deployment. This includes the framework so you do not have to have it pre-installed on the target.
- sebazzz 5y ago
mycall 5y ago
> Net 5 isn't even finished and they are already previewing 6 net5 was never an LTS release, so they are moving as fast as they can to net6. I do believe 6 will be much more stable.
codebolt 5y ago
Even worse, this week I ran into an issue which was answered with "just use .net 6" which isn't even out of beta yet.

gregmac 5y ago

I agree, though I wouldn't say it's the pace of development so much as the change in approach. .NET Standard made sense as a transition plan, but then was effectively abandoned. I understand that the focus went to .NET 5/6, but the effort is incomplete! Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating. In theory you can also create a project that multi-targets .NET framework and .NET core, but in practice, while I've got this to work, it's an adventure every time and most often I just give up as it's not worth the time-sink. It kind of seems like the official migration path is just "stop everything, port to .NET 5 and you'll be good". But that's not really practical. Indeed, my experience on pure .NET Core (3.1) or .NET 5 has been very good thus far -- including easily building cross-platform native apps. It's just that the reality is there's still a lot of .NET Framework code. The other big challenge for us is in delivering apps that run on customer systems. Doing the switch to .NET Core/5/6 means we have to decide on: increasing from shipping a 5MB to a 45MB app (runtime included); requiring .NET runtime is installed (and handling auto-update failures when it's not); modifying the installer to install if needed (again handling failures). This is all tons of work, and a tough sell when we have a multi-year backlog of bugs and feature requests it has to compete with.

mycall 5y ago
> Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating. I'm happy to hear I'm not the only one with this problem. For me, removing assemblies from csproj ended up being the solution to many of these problems (let them load implicitly).

0x0 5y ago

This exactly! The branding and versioning of .NET is a complete disaster. There's .NET Framework (where even simply getting the current runtime version requires several convoluted hoops, since System.Environment.Version has gone the way of browser user agents and frozen itself at "4.0.30319"). Then there is .NET Standard, which was at version 1 and 2 (which are newer than .NET Framework 4.0 or 4.5? but have significantly fewer APIs available, and many classes are missing methods and properties that were present in .NET Framework). Then there is .NET Core which reset the versioning scheme again? Then there is .NET 5 which is newer than all of these, but is it actually fully supported on non-windows platforms? Then you need Newtonsoft.JSON, and then you get to watch your entire project blow up because you have three different dependencies that use different versions of netstandard/netcore/netframework and the assemblies aren't compatible. I really hope going forward there will be just one unified .NET 6 that works the same on all platforms and doesn't need a million different builds of the same nuget package. Edit: And even after all this, deploying your app by just copying the .exe and .dlls to a pristine machine often fails, because the corresponding .NET framework runtime isn't installed. And then you need to be a lawyer to figure out if you can even ship the net framework installer to your customer or how to handle that. You would think Microsoft would have a better story to sell to developers as what should be "the way" to develop and distribute windows executables. It seems like the only way to really be portable is to use an ancient version of Visual C to write win32 directly, and link the corresponding msvcrt statically.

nightski 5y ago
Yes .NET 5 is supported on all platforms. It is the future of .NET Core. They dropped core because they wanted to make it clear it is the one true dotnet going forward. It actually will greatly simplify things going forward. .NET standard will no longer be necessary because there is only .NET 5 onward. You don't "need" Newtonsoft.JSON. .NET now has a built in serializer which is much faster. But for compatability and some more advanced scenarios some people still need/prefer it. Lastly .NET core apps (and .NET 5/6 going forward) have an option to produce a single file deployment. This includes the framework so you do not have to have it pre-installed on the target.
sebazzz 5y ago

mycall 5y ago

> Net 5 isn't even finished and they are already previewing 6 net5 was never an LTS release, so they are moving as fast as they can to net6. I do believe 6 will be much more stable.

codebolt 5y ago

Even worse, this week I ran into an issue which was answered with "just use .net 6" which isn't even out of beta yet.