That really depends what classes you use. There are still a lot of classes that haven't been implemented in .Net Core and many of them supposedly won't be implemented. Others were re-implemented and renamed and might not match features. You'll want to move to .Net Core eventually, but not every .Net release is going to be easy to move. Moving from .Net Framework to .Net Core is like moving from .Net Framework to mono. It's mostly similar, but it's still wholly different and not intended to be a 100% drop in replacement.
The Microsoft.Windows.Compatibility namespace isn't new at all. At least that's what the Windows Compatibility Pack for .Net Core [0] used at the end of 2017. It looks like it might just finally be out of the preview stages.
[0]: https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcin...
If you require the new features maybe, but if you are writing enterprise code, you shouldn't rush into things.
> Doubly so if you care about runtime performance.
Everyone cares about runtime performance, but if your software isn't experiencing performance issues, there is no need to rush into things. Or at the very least, reach out to your clients to get a feel about their schedules and expectations.
#1 rule: if it ain't broke, don't fix it.
I dont get these claims to not upgrade unless you're also just as worried about changing a line of code and having it all break too? Make the changes, test the changes, and deploy carefully, just as you would for anything else.
I've seen legacy code get created by people postponing platform updates for so long that the upgrade pathways stop being supported, that's one way.
I've also seen legacy code get created by people adopting the platform of the future super-early, and then being left high and dry when the rest of the world decided that platform wasn't actually the future after all, leaving them as the sole maintainers of the entire platform as well as their dependent code.
If your code currently works on standard .net, there's no reason to be in a massive hurry to move to .net core. There's not necessarily any reason to delay, either. It all depends on your business requirements and the investment required. If it's easy for you to move to .net core then by all means do it. If it's gonna be a massive project, let the smaller groups go first.
This is something i've seen many times, when you don't update in long enough entire API's might've changed or been replaced and there's no documentation or anyone even remembering the stuff available anymore.
I agree though that one doesn't have to rush new releases, i do however think there should be a plan to upgrade done as soon as there's a new stable release.
I've been working with a softphone that's built for .net framework 3.5, if you want any library you can forget nuget, must get source build and modify manually. Which is suboptimal.
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.
But it is pretty simple to use. It is in nuget package "System.Threading.Channels".
You basically call Channel.CreateBounded<T>(int) to create a channel that will buffer a limited number of T objects.
A Channel has a ChannelReader and ChannelWriter which are two ends of the same channel. The reader is the output side, the writer is the input side.
Each side exposes methods to synchronously try to Read or Write or asynchronously Read or Write (respectively).
It supports "Completion" meaning that the Writer can signal the Reader(s) that it is done writing forever. For example imagine you had a channel that was for Log Messages. A bunch of readers might be listening, but then the App shuts down. The writer can call "Complete()" on the channel and the Readers will get wake up and get a message that there is no more messages and flush themselves and shut down.
As a note you will need to run your own processing thread to await messages from the channel. Unlike Dataflow which will span it's own taks to handle messages.
I will write up an example Gist and reply to this thread in a little bit.
Other notes: - The API is very similar to Dataflow since Stephen Toub wrote them both. - It is extremely fast. I have seen > 1.25M messages per second in my benchmarks. - It is mostly allocation free due to using the new ValueTask<T> which is a struct
Futher Reading: https://www.nuget.org/packages/System.Threading.Channels/ https://apisof.net/catalog/System.Threading.Channels
https://gist.github.com/AlgorithmsAreCool/b0960ce8a3400305e4...
Channels does this but has 2 advantages.
1. It is built on the most up-to-date threading primatives (ValueTask) which gives it a perf advantage.
2. It's internal design is very simple and lightweight. BlockingCollection was designed to have swappable guts. Channels are single purpose.
The other nice thing is the channels API is really no nonsense super simple to get GREAT performance out of normal async/await. No tuning really needed. I got >300Krps out of a sequence of chained channels with a buffer size of 1.
This sounds very similar to the channels (Chan [1]) in Haskell, which I really loved playing around with.
[1] http://hackage.haskell.org/package/base-4.11.1.0/docs/Contro...
https://msdn.microsoft.com/en-us/library/dd267265(v=vs.110)....
Also, we need a GUI, of some kind.
Blazor (.NET webassembly) + Electron is an interesting option though for the future.
Are you stuck on Skype for business due to enterprise policy?
There is no Teams API to speak of, I'm super confused why Microsoft is pushing it so hard when they are wildly behind on the integrations that were promised already, and the functionality is behind the product that it is supposed to replace.
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...
Would be .NET Core 3 you'd be waiting for then:
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...
I wish they worked on their release notes with samples for all the smaller features like formatters, pooling and channels. Too much of it is buried in github issues.
Channel<T> uses ValueTask<T> which is kinda painful in F# for now.
They had tuples, async/await, and match statements a decade ago and every time C# adopts one of their feature they change the implementation and make F# retool. It's kinda awful.
At this point I want F# to do a hard reset, rebuild on top of Roslyn, natively adopt ValueTuple and Task/ValueTask then grow alongside C# like VB tried to.
I've been hoping for basically the same thing. That said, putting any new language on top of Roslyn (not just using it for IL generation, but actually making it a proper provider a la C#) is 1) not supported, and 2) not seeming like it's going to be. I have a language on .NET that I would love to build into a first-class Roslyn provider but there just isn't any support for that right now. Maybe F# folks inside MS can work to change that.
I'm somewhat astounded that VB.Net is still a thing, however.
Using it mostly for scripting like tasks only.
Then it wasn't relevant for .NET Native support, and finally Microsoft keeps ignoring some vocal anti-MS/C# members in the community, which made me loose any remaining interest.
I rather have C# with some FP like features, than a FP language without tooling support and needless forum discussions.
Regarding VB.NET, it is used quite a lot in some enterprise shops.
I have seen many apps that started as office macros and eventually grew up to be VB.NET ones.
Even if VB.NET is more complex than VB was, it still easier than C# for those office employees that know one or two things about coding.
The most important since at least framework 4.0 maybe even 3.0.
We are getting:
- Span<T>/Memory<T> : A 0-copy, unified way of accessing Managed or Unmanaged memory.
- Channel<T> : High performance thread-safe queues (like go channels)
- Pipelines : an async, 0-copy version of Stream
- In-box support for Array/Buffer pooling (finally!) (MemoryPool, ArrayPool)
- Better primitives for pointer manipulation and memory marshaling. (MemoryMarshal)
- New primitives for high performance parsers and formatters (System.Buffers.Binary and System.Buffers.Text)
- Improved support for SSE/NEON via Vector<T>
- Microsoft.Windows.Compatibility : Windows specific APIs on .NET Core (Registry, EventLog, NamedPipes...)
- Tiered Compilation
- Faster tooling
- Wider Platform support
If you write code on .NET, you should [Edit] evaluate this release with to see if it fits your business needs [/Edit]
Doubly so if you care about runtime performance.