3 ms·

I look at this ".NET 5" thing as a PR move to end full framework. "We aren't ending full framework, we have .NET 5!" If you are developing new apps in full fr

by pknopf 7y ago

I look at this ".NET 5" thing as a PR move to end full framework. "We aren't ending full framework, we have .NET 5!" If you are developing new apps in full framework, you are doing it wrong.

pjmlp 7y ago
Then we are doing it wrong, until the 3rd party libraries that we require, actually bother to make it right.
tstrass 7y ago
If you're developing an application with a Windows desktop GUI, you're still doing it on full framework (WPF, WinForms, UWP). They're folding that into .NET 5, and I haven't seen anything indicating that they see that as "doing it wrong". This is only one case of developing for full framework, but it's a big one. I imagine any other cases where the developer community really needs full framework capabilities that still aren't ported to CoreCLR, they'll fold that in just the same as with the UI frameworks, as a Windows-specific capability. Maybe they end up sunsetting more than I think, but for now this seems more like consolidating Core and Framework than ending Framework.
thrower123 7y ago
There are a ridiculous amount of first-party Microsoft SDKs for products they are pushing heavily that don't support Core yet. Unless there is a newer version than last month, one of those is the Bot Framework extensions for Microsoft Teams, which they are just slamming ahead with.
Nuzzerino 7y ago
Last time I tried to seriously switch from Framework to Core, I was dismayed to find that Assemblies could not be unloaded from memory in Core after they were loaded. That was something that depended on the AppDomain functionality, which existed in Framework only. Thankfully, they finally got around to adding support in .NET 3.0 (https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/ https://www.strathweb.com/2019/01/collectible-assemblies-in-...).

3 ms·

I look at this ".NET 5" thing as a PR move to end full framework. "We aren't ending full framework, we have .NET 5!" If you are developing new apps in full fr

by pknopf 7y ago

I look at this ".NET 5" thing as a PR move to end full framework. "We aren't ending full framework, we have .NET 5!" If you are developing new apps in full framework, you are doing it wrong.

pjmlp 7y ago
Then we are doing it wrong, until the 3rd party libraries that we require, actually bother to make it right.
tstrass 7y ago
If you're developing an application with a Windows desktop GUI, you're still doing it on full framework (WPF, WinForms, UWP). They're folding that into .NET 5, and I haven't seen anything indicating that they see that as "doing it wrong". This is only one case of developing for full framework, but it's a big one. I imagine any other cases where the developer community really needs full framework capabilities that still aren't ported to CoreCLR, they'll fold that in just the same as with the UI frameworks, as a Windows-specific capability. Maybe they end up sunsetting more than I think, but for now this seems more like consolidating Core and Framework than ending Framework.
thrower123 7y ago
There are a ridiculous amount of first-party Microsoft SDKs for products they are pushing heavily that don't support Core yet. Unless there is a newer version than last month, one of those is the Bot Framework extensions for Microsoft Teams, which they are just slamming ahead with.
Nuzzerino 7y ago
Last time I tried to seriously switch from Framework to Core, I was dismayed to find that Assemblies could not be unloaded from memory in Core after they were loaded. That was something that depended on the AppDomain functionality, which existed in Framework only. Thankfully, they finally got around to adding support in .NET 3.0 (https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/ https://www.strathweb.com/2019/01/collectible-assemblies-in-...).