4 ms·

The execution of .NET core project has been, with all due respect, a huge mess. The naming and versioning schemes are confusing. The breaking changes are disrup

The execution of .NET core project has been, with all due respect, a huge mess. The naming and versioning schemes are confusing. The breaking changes are disruptive. Making ConfigurationManager a pain in the ass to use is disruptive. .NET core has been around for years now but it doesn't inspire confidence and still doesn't seem production ready given the lack of adoption and Microsoft's incessant habit of changing and breaking things for no good apparent reason. It's such a pity because I absolutely love the dotnet cli tooling.

jddj 7y ago
It's still moving really fast for a framework. Definitely exciting to observe from afar, but it can be jarring to try to keep up with as someone who only occasionally dabbles in it for web stuff. Slight hyperbole, but waking up one morning to find the whole of Identity rewritten as razor pages was a bit of a curve ball. Edit to add: I'm not so sure about "lack of adoption", though. I'd temper that as lack of adoption in the US/valley. Europe, the UK and Australia seem to have quite a bit of .net core stuff going on.
pjmlp 7y ago
We just moved into .NET Framework 4.7.1 for greenfield projects. All regular .NET libraries and Visual Studio designers just work out of the box. And yes it was a huge mess, I see it as result of internal politics how Windows dev was supposed to move forward after that whole Longhorn vs Vista, which eventually lead to WinRT. Eventually we will be coming back to where we started with .NET 5. And the migration would have been easier if they just did the improvements into an increasing way. Rule of thumb, always wait and don't jump into new tech just because.
taude 7y ago
I'm not sure what you mean? We've been running dot net core apps in prod for awhile now, and I'm not sure what you mean about naming and versioning schemes? Are you talking about the difference between the legacy .NET Framework and the dotnetcore stuff? Sure that could be confusing if you're expecting them to be the same thing? Also, what do you mean not production ready? There's a lot of people running dotnet core apps in production. We have servers serving up a bunch of APIs, running Linux, and have no regrets, and I'm personally glad that I've moved off of Java framework for this. I only see if you're trying to migrate existing apps from Framework to core. But I'm not sure that's a path any sensible person would take with any significant amount of legacy code. Anyway, I'm not seeing the huge, insurmountable mess you're alluding to.
- taude 7y ago
  I should add that we didn't get into dotnetcore until 2.0 release era. So many there was a ton of pain with the first version?
marsrover 7y ago
> lack of adoption I don’t think this is true at all. My last two jobs have migrated from .NET Framework to .NET Core. At my current job all new services are .NET Core and there are many running in production now with no problems at all. Every piece of spam I get from recruiters has .NET Core in the description these days.
- simonh 7y ago
  I caught up with a friend of mine recently and his company has migrated to .NET Core as well. Anecdotal I know, but it's a thing some people are doing.
  - minedwiz 7y ago
    Mine as well. We're standing up our new service in Core, and we've migrated about half of our old WebJobs.
na85 7y ago
I'll echo your point about confusion. I tried once to figure out how to build a simple .exe with C# and dotnet core, something I could do easily with c++ and gcc. I gave up after a few days because the dotnet documentation was too confusing. There are 40 different projects with easily-confused names like corefx, coreclr, etc, and the docs are convoluted and split between developer.microsoft.com and msdn. That was a while ago, so maybe the docs are better now but I can't shake the feeling that when your best source of info on official stuff like "how to build a self-contained application" is a 2-year old obsolete Stack Overflow post, .NET Core is just a mess.
- AdrianB1 7y ago
  Same experience here. I wrote some C# Windows apps a few years ago, I jumped to write a REST API and the experience was painful: the documentation is confusing, the REST API projects are even more confusing, I got what I wanted but it felt like a big accomplishment to go through the complexities. By comparison I wrote that API in PHP in a couple of hours - it had more code, but my team mates were able to understand easily how it worked. I am not saying PHP is better, I am saying it is much easier to use and there are probably more examples out there of simplicity.
- manigandham 7y ago
  You don't need to know about any of those projects to build an app in C# so you may have started from a bad source. Documentation is much better now and all located at https://docs.microsoft.com/en-us/dotnet/ https://docs.microsoft.com/en-us/dotnet/ with github-integrated editing and comments. Self-contained apps package the runtime with your app so there are no dependencies but having an executable is a separate option and requires the ID of the platform you're targeting. The 3.0 SDK makes it much easier. https://docs.microsoft.com/en-us/dotnet/core/deploying/ https://docs.microsoft.com/en-us/dotnet/core/deploying/
- lukevp 7y ago
  What is your definition of "self-contained"? Does not require dotnet, or is contained within a single executable? Building an application that doesn't require a dotnet core runtime is a one-liner: dotnet publish -c Release -r win10-x64 --self-contained true https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli https://docs.microsoft.com/en-us/dotnet/core/deploying/deplo... If you mean creating a single EXE with no external dependencies whatsoever, that's something that they are discussing in .NET Core 3 but isn't straightforward right now. It's basically the same story as Python, you have to bundle the interpreter with the application or you have to rely on the interpreter being pre-installed. With dotnet, you rely on the runtime being installed or you bundle it in as self-contained.
manigandham 7y ago
It's been production ready (as in fully supported) since v1. It's the first new cross-platform runtime in over a decade so breaking changes are expected, but they were very clear about where things stood and always recommended v2+ if you wanted to move with the least amount of missing APIs. With .Net Core 2.2 now, a full 5 releases in, there should be no major issue for migrating apps or building new ones. The naming is definitely a known problem but as far as "doesn't inspire confidence" and "breaking things for no good apparent reason" - what specifically are you talking about? There's tremendous adoption with the next version of the entire .NET platform converging around Core and all the development is done out in the open with public discussions and code if you want to learn the reason why anything was done. Is it more that things are just different from what you're used to?
snak 7y ago
In my experience, people that are confused over .NET naming schemes are people that either have management roles or are stuck in .NET Framework. When you start playing around with .NET Core you can easily see the main difference between Framework and Core and why Standard exists.

jddj 7y ago

It's still moving really fast for a framework. Definitely exciting to observe from afar, but it can be jarring to try to keep up with as someone who only occasionally dabbles in it for web stuff. Slight hyperbole, but waking up one morning to find the whole of Identity rewritten as razor pages was a bit of a curve ball. Edit to add: I'm not so sure about "lack of adoption", though. I'd temper that as lack of adoption in the US/valley. Europe, the UK and Australia seem to have quite a bit of .net core stuff going on.

pjmlp 7y ago

We just moved into .NET Framework 4.7.1 for greenfield projects. All regular .NET libraries and Visual Studio designers just work out of the box. And yes it was a huge mess, I see it as result of internal politics how Windows dev was supposed to move forward after that whole Longhorn vs Vista, which eventually lead to WinRT. Eventually we will be coming back to where we started with .NET 5. And the migration would have been easier if they just did the improvements into an increasing way. Rule of thumb, always wait and don't jump into new tech just because.

taude 7y ago

I'm not sure what you mean? We've been running dot net core apps in prod for awhile now, and I'm not sure what you mean about naming and versioning schemes? Are you talking about the difference between the legacy .NET Framework and the dotnetcore stuff? Sure that could be confusing if you're expecting them to be the same thing? Also, what do you mean not production ready? There's a lot of people running dotnet core apps in production. We have servers serving up a bunch of APIs, running Linux, and have no regrets, and I'm personally glad that I've moved off of Java framework for this. I only see if you're trying to migrate existing apps from Framework to core. But I'm not sure that's a path any sensible person would take with any significant amount of legacy code. Anyway, I'm not seeing the huge, insurmountable mess you're alluding to.

taude 7y ago
I should add that we didn't get into dotnetcore until 2.0 release era. So many there was a ton of pain with the first version?

marsrover 7y ago

> lack of adoption I don’t think this is true at all. My last two jobs have migrated from .NET Framework to .NET Core. At my current job all new services are .NET Core and there are many running in production now with no problems at all. Every piece of spam I get from recruiters has .NET Core in the description these days.

simonh 7y ago
I caught up with a friend of mine recently and his company has migrated to .NET Core as well. Anecdotal I know, but it's a thing some people are doing.
- minedwiz 7y ago
  Mine as well. We're standing up our new service in Core, and we've migrated about half of our old WebJobs.

na85 7y ago

I'll echo your point about confusion. I tried once to figure out how to build a simple .exe with C# and dotnet core, something I could do easily with c++ and gcc. I gave up after a few days because the dotnet documentation was too confusing. There are 40 different projects with easily-confused names like corefx, coreclr, etc, and the docs are convoluted and split between developer.microsoft.com and msdn. That was a while ago, so maybe the docs are better now but I can't shake the feeling that when your best source of info on official stuff like "how to build a self-contained application" is a 2-year old obsolete Stack Overflow post, .NET Core is just a mess.

AdrianB1 7y ago
Same experience here. I wrote some C# Windows apps a few years ago, I jumped to write a REST API and the experience was painful: the documentation is confusing, the REST API projects are even more confusing, I got what I wanted but it felt like a big accomplishment to go through the complexities. By comparison I wrote that API in PHP in a couple of hours - it had more code, but my team mates were able to understand easily how it worked. I am not saying PHP is better, I am saying it is much easier to use and there are probably more examples out there of simplicity.
manigandham 7y ago
You don't need to know about any of those projects to build an app in C# so you may have started from a bad source. Documentation is much better now and all located at https://docs.microsoft.com/en-us/dotnet/ https://docs.microsoft.com/en-us/dotnet/ with github-integrated editing and comments. Self-contained apps package the runtime with your app so there are no dependencies but having an executable is a separate option and requires the ID of the platform you're targeting. The 3.0 SDK makes it much easier. https://docs.microsoft.com/en-us/dotnet/core/deploying/ https://docs.microsoft.com/en-us/dotnet/core/deploying/
lukevp 7y ago
What is your definition of "self-contained"? Does not require dotnet, or is contained within a single executable? Building an application that doesn't require a dotnet core runtime is a one-liner: dotnet publish -c Release -r win10-x64 --self-contained true https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli https://docs.microsoft.com/en-us/dotnet/core/deploying/deplo... If you mean creating a single EXE with no external dependencies whatsoever, that's something that they are discussing in .NET Core 3 but isn't straightforward right now. It's basically the same story as Python, you have to bundle the interpreter with the application or you have to rely on the interpreter being pre-installed. With dotnet, you rely on the runtime being installed or you bundle it in as self-contained.

manigandham 7y ago

It's been production ready (as in fully supported) since v1. It's the first new cross-platform runtime in over a decade so breaking changes are expected, but they were very clear about where things stood and always recommended v2+ if you wanted to move with the least amount of missing APIs. With .Net Core 2.2 now, a full 5 releases in, there should be no major issue for migrating apps or building new ones. The naming is definitely a known problem but as far as "doesn't inspire confidence" and "breaking things for no good apparent reason" - what specifically are you talking about? There's tremendous adoption with the next version of the entire .NET platform converging around Core and all the development is done out in the open with public discussions and code if you want to learn the reason why anything was done. Is it more that things are just different from what you're used to?

snak 7y ago

In my experience, people that are confused over .NET naming schemes are people that either have management roles or are stuck in .NET Framework. When you start playing around with .NET Core you can easily see the main difference between Framework and Core and why Standard exists.