I care about performance, but:
Still have customers on .NET 4.0.
.NET Core 2.1 doesn't do EF6, Forms or WPF, need to wait for 3.0 for that.
Not all third party libraries are already on Core.
Given all that, Core 2.1 is full of goodies that I will surely play around with.
...But reading between the lines, you probably still have clients on XP (.NET 4.0). That's gotta sting. We made a fuss about TLS1.2 support being required and forced them to upgrade to Win7/.NET 4.5.2 at least.
I have gotten gotten a smallish winforms app to work with the new .csproj format. But it's painful. WPF is probably a nightmare.
As an aside if you make it to .NET 4.5+ and get async/await. It works great with winforms and presumably WPF!
Nope, we cannot make it to .NET 4.5+ due to some third party libraries, which is a bummer, because we are stuck with BackgroundWorker as TPL had some bugs with Forms on 4.0, which were only fixed on 4.5.
It is only one project thought, the other issue are the IT upgrade policies regarding developer images.
Note that you don't have to install netcore on machines, you can create self-contained releases[1].
> EF6, Forms or WPF
Depending on your architecture you may be able to upgrade to netcore piecewise (i.e., microservices over "dumb" protocols like HTTP or gRPC). We are currently turning our monolith into microservices; porting to netcore where possible (using an anti-corruption layer where not). We've only just started but are already reaping benefits.
[1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/#self...
For native GUI applications it is nothing than a waste of resources.
Three tier architectures with modular designs across several assemblies are a much better solution, no need to go after what is cool.
The EF6, Forms and WPF support is the major goal of .NET Core 3.0, so why should I ask our customers to waste money with microservices and application rewrites?
1) RPC and remoting can leverage microservices, but are not required to. There is a very, very, low probability that people doing DCOM or SOAP were doing microservices. Modularity is an essential feature of microservices. Service experience does not necessarily translate to micro-service experience...
2) Is this GUI app service oriented? That is to say: despite its thick client, is it accessing network and shared resources in the networked environment? Because native GUI apps often talk with webservices. Maybe those are monolithic, maybe they're not, but the resource usage will have to do with development and maintenance of those service and its effect on the (fat) client.
3) Traditional three tier architectures struggle in numerous scenarios (particularly those where microservices thrive). Hexagonal architectures/DDD do well in those areas, provide all the same benefits and more, and are really not "cool" anymore. Also, those design styles can use microservices (or not), they're not dictated by them.
4) .Net Core 3 has a bunch of value adds for thick client WPF apps with no services -- side-by-side installations and such.
5) You should not ask your customers to waste money with microservices, nothing about .Net Core 3 would indicate that you should. Same deal for monolithic services... Just because MS launches something good for apples does not mean you should call your customers and tell them their oranges have to be thrown out.