.NET Core 3.0 Concludes the .NET Framework API Porting Project
github.com
github.com
The teams working for Windows development are overall on a roll these days and it's both sad and a little mysterious how Windows 10 is still struggling with QA issues, decisions like dismantling their internal testing teams, dual control panels and inconsistent design.
I've heard Windows devs speaking up off the record that it is hell to work on with so much boilerplate and ceremony both in practice and politics and with few understanding all the ins and outs of building for their Windows 10 desktop, many restorting to copy & pasting because "it's just supposed to be like that". That makes it a little easier to understand why their aforementioned old control panel is still around even after five years of work on a new one.
I wish they could somehow restructure and streamline and come back to also be able to share the excitement like the .NET Core team are doing right now. Maybe if Windows 10X is a success? Maybe Windows is indeed just getting too big for its own good and the Win32 apps are best just put into one fat virtualized environment for backwards compatibility, like in that upcoming evolution of Windows.
Then write the Windows user land in .NET Core.
The new UIs change with every minor update. Layout, labels and semantics. It's truly horrible. Please don't encourage Microsoft to mess it up even more.
Or even more importantly than that, that they even exist in there somewhere.
Recently I went to play a game on my laptop, something i don't normally do. I'm not even normally a windows user.
It has this 'feature' where if a key is pressed then it disables all mouse clicks for X number of seconds. This is to prevent a forearm from tap to clicking on the touchpad while typing. Absolutely makes sense.
Only... I had a mouse plugged in. It disabled a physical USB mouse from clicking after a keypress. Even after disabling the touchpad entirely it continued this behaviour.
After some Googling there should have been a switch in the modern Windows 10 style mouse config. But it wasn't there.
More Googling, "go edit this registry key" but i didn't have that registry key.
More Googling, the registry key depends on your touchpad driver.
More Googling finally found a way to disable it globally with regedit.
#1 Why was the switch not available in the mouse settings #2 Why was it applied to a usb mouse #3 Why did the registry key differ depending on mousepad driver.
Just a nightmare.
For some inexplicable reason their newer touchpads (in newer laptops) support the Settings configuration, whereas their older ones (in older laptops) only work via the Mouse Control Panel applet (and sometimes not even then).
I've also had their touchpad driver cause keyboard input latency (it tries to hook hotkeys) with uninstalling it entirely and having no touchpad being the only solution. Their stuff is just bad, and they should feel bad about it.
I doubt they do feel bad as they have a seeming monopoly on Windows laptop touchpads.
It's just that Apple's system tries to separate deliberate touches from accidental ones, rather than disabling the trackpad input completely.
You used to be able to turn this on and off (it was called "Ignore accidental trackpad input" in the trackpad preference pane) but now it's an always on feature. The trackpad has extended so far into the palm rests that it would be very difficult to use without it, and the feature works well enough that you don't even realize it's happening.
Does that mean you would never be comfortable with with a complete UI overhaul?
> The new UIs change with every minor update
I completely agree that this is a problem. And this part of my biggest issue with Windows 10. They're constantly reworking the new UI for what seems like micro-optimizations, but they're mostly ignoring the old UI. Not only is it a headache for users to keep up with new paradigms every 6 months, but there continues to be two areas in Windows to control system settings, one of which is hidden pretty well, and the location of settings between the two is continually changing. It's a nightmare.
.NET Core, on the other hand, is pure gold. It's fast, it runs everywhere, it's well document, and it's a joy to work with.
Which leads us to Visual Studio, which is becoming like Windows. Constant tweak updates that break things. I stopped installing '.0' releases, beacsue they're consistently broken.
I'd like for the old interface to be still around, so I can click though the nav layers like I always have. At the end, instead of the information / setting I'm looking for, I'd be fine with info on how now to find that info/setting. This "tutorial" should obviously be kept up to date on later UI changes. It also requires the info/setting to still be available... so no dumbing-down please.
I’m a big fan of PowerShell, I have embedded it in two products. However it’s not a good justification for a poor user interface.
Which would be ok if they had been replaced by an equivalent in the new menu. But they have not. So what is the point in hiding them?
Tasks such as changing network adaptors setting, or sound settings. I regularly switch between three different audio devices on my desktop PC, and doing simple tasks such as toggling volume levelling isn't in the new interface and digging into the old is becoming harder and harder to find, with more clicks for every revision. Just yesterday I went to add a firewall rule, and that was hard to find. I'm an MCSE, so you would think I could change a firewall setting!
It definitely doesn't feel like an improvement, it feels like they're forcing an abstraction. Plus they've recently removed the Control Panel when you right-click the Start menu. That was about the only 'Safe Space' left.
I feel for anyone who has to support Windows 10. They're definitely not listening to the users. This is the FisherPrice interface all over again, but there's no stopping it this time around.
My biggest gripe is not being able to directly open the old settings... Always having to open "control panel" and then clicking on the correct category gets old fast, but is nonetheless more effective than fruitlessly searching in the new panels until I give up.
I hate writing Win32 apps, but I love using them. I love writing .NET apps but I hate using them.
The problem with Win32 apps is that although they look ugly, in general they're blazing fast and work basically everywhere. The problem with .NET apps is although they're aesthetically pleasing, they require the relevant version of the framework to be installed. I remember fighting with installing a .NET-based driver installer that insisted on installing an ancient version of .NET that Windows wouldn't allow to install. Win32 support is still universal.
And when I say performance is improved, there are two fronts to that. First, the compiler/jit are just better now, core library functions are sped up a ton, so just running ported old .NET Framework code will be a lot faster. But also, C# has added new features in recent years that give you further control over memory usage/layout, and now even SIMD Intrinsics, so the performance ceiling is much higher if you want to optimize your own code.
You can now publish a .net core 3.0 app that is: 1- Ready to Run: Part AOT compiled app for the platform. 2- Trimmed: Tree shaken down to only necessary bits from the framework. 3- Single File: Self contained app.
This combination of features provides a really decent balance between size, performance and distribution.
1 year to build Windows Vista's new shutdown menu, with a total of 43 people somehow involved in its design. If this is how Windows developers still have to work, it's no wonder.
That said, I would readily believe that the roots of this story have more to do with the complexity of modern OSes than any particulars of Microsoft culture. In terms of software quality, OS X peaked about 15 years ago, and has been steadily getting flakier ever since. And the Linux community has been struggling for virtually its entire existence, without success, to deliver a well-polished desktop experience.
The best we can hope for is that with the new AOT/JIT infrastructure, it gets more equal footing with C++/WinRT in platform APIs.
After all, it has won the UI, MFC is legacy and XAML/C++ doesn't have much uptake as most companies rather do C++/COM and then consume them from .NET for the UI part.
I am not sure "rewritten" is the proper word as this implies replacement, but in reality nothing gets replaced (at least as far as the user/developer facing stuff go) and the new stuff are added on top (or alongside, depends) the existing stuff.
Also i'm not sure if the whole "exposing new stuff in COM" thing is a good idea overall. The classic Win32 GUI APIs might not provide much functionality on their own, but the plain C APIs make them both understandable by pretty much everyone and fairly easy to use by pretty much everywhere. I haven't seen much COM use on the wild since the turn of the millenium (outside of the new UWP stuff in Windows Store but really the UWP/Windows Store seems to be a different world on its own that got itself attached to the regular desktop Windows world... and even then i do not really know of anyone who uses anything from there). The most common comment i read about COM is using it to control Office but that's about it (technically DirectX APIs are also COM but in practice you do not really use much of it).
As an example, Windows had a COM API for creating ribbon-like interfaces ever since Windows 7/Vista SP2 yet pretty much every framework out there (including MFC) reimplements their own ribbon using Win32 primitives instead of using the native one.
COM usage is fairly limited because using it easily requires compiler support, which only very recently was included in the Community editions of Visual Studio. You can also access COM via language bindings; most .NET code you write is COM-enabled, for example, and is accessed from non-CLR code as COM. MinGW has stuff that lets you use and generate COM classes, but it's not great. Improving it would help FOSS dev on Windows.
There are other languages that use COM also. The lead designer of Delphi was poached by Microsoft to design .NET.
Ext-VOS design document clearly refers to Java and J++.
Secondly, I have been developing for Windows since Windows 3.0 and wonder which compiler support features do you mean. Even the old express editions had the required Windows SDK tooling for COM.
The tools may have just been for COM object generation. I found the option to generate COM code in VS2017 one day, followed up on it, and found it was the first time they had been released. The bare headers were always there but the code generators were not, at least in most current releases.
https://www.welcometothejungle.co/en/articles/anders-hejlsbe...
Again, I never had to enable anything on VS to generate COM components.
Longhorn was to be built on top of .NET and there were lots of issues, regarding performance, stability and what not.
Apparently it was more a thing of WinDev (owner of Windows and C++) and DevTools (owner of VS and .NET) each pulling to their side instead of collaborating.
As proven later by Singularity and Midori it was an achievable goal, when everyone on the team believes on the end goal.
Instead Sinofsky team took over, several ideas were dropped, others were reborn in .NET 3.x like WPF, and Vista came to be.
Many of the .NET (Longhorn) libraries reappeared in Vista and Windows 7 as COM libraries.
See Project Hilo sample, https://blogs.msdn.microsoft.com/jasonz/2010/06/06/project-h...
Later WinRT was born, which is an improvement over COM, using IInspectable alongside IUnknown, and .NET Metadata instead of the old COM type libraries.
Curiously similar in concept to Ext-VOS, which was in the genesis of .NET, before CLR came to be.
https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net...
So WinRT (Win 8.0), eventually became UAP (Win 8.1) and now it is UWP (Win 10).
Contrary to many Windows 10 haters belive, UWP isn't tied to the store and each Windows 10 release brings more Win32 "legacy" APIs into UWP.
The next generation COM based runtime with interoperability across C++, .NET, JavaScript, Delphi and every other language capable of understanding COM projections.
Ah, and thanks to the contributions initially started by Kenny Kerr, which ended up joining the Windows team, the C++/CX language extensions got replaced by C++/WinRT a C++17 framework for UWP.
Office had stuck with regular the regular Windows platform and were focusing on UI and getting into a regular release rhythm under Sinofsky. People forget but Office releases used to be a real crapshoot and Microsoft needed to move to a true subscription model at some point (the original activation wasn't it.) To do this you need regular updates at least a few years apart before you can even get close to what's needed for a subscription business. Sinofsky seems to have been a real success here, but not so much in Windows.
Looking back the expectations for Vista could never meet the reality. Windows was fundamentally not ready as a product or team to deliver on any of the promises. This was not much different from Cairo (https://en.wikipedia.org/wiki/Cairo_(operating_system)) as it turned out. If the focus had been on the fundamentals like regular releases they may have been achieved some of what is promised with the right compromises. I also wouldn't discount some of the hardware changes in the period. We were getting multi-core and there was a transition to 64-bit.
Undoubtedly there were multiple issues at play there.
However having been part of such "rebuilt the world" projects, I do believe politics also played an important role, as many signs that came into the outside world feel similar.
Lisp machines in the 60s were doing tracing GC in hardware. It's not like we don't have the technology to move tracing GCs further down the stack. Sure, reference counting is "simpler", but it's also easier to do wrong. It's harder to get tracing GC wrong. (Sure, we can debate for days if its harder to get tracing GC performant, but it can and has been done, including as mentioned directly in hardware.)
But code written for tracing GCs cannot be automatically transformed into COM's (or any) reference counting scheme. And that's why we have this endless tug of war between those who want to build on top of COM versus those who want to build on top of .NET.
It's not just a Microsoft problem either. Our industry has been wasting a ton of resources on duplicating everything for a bunch of different languages/runtimes and it's all either because of GC incompatibility or license incompatibility.
It's not a minor problem even if there are more important problems in the grand scheme of things is what I'm saying.
It works even on Linux https://github.com/Const-me/ComLightInterop I also have these parts, especially about the interop. Libraries like drm, kms, gles, udev, and many other kernel APIs are only usable from C or C++.
Had very few issues with IUnknown-based interop. On Linux, my interop library retains .NET objects with GCHandle while they are referenced by C++ code. On Windows, it’s done automatically by the runtime. C++ implemented objects are automatically retained on both OSes.
What exactly do you think is a hard problem about such interop? Leaks due to ref.count cycles are possible, but I’m not sure it’s such a huge deal. There’re many good reasons to keep interop API surface small, with obvious “who owns what” relations.
The problem is that .NET libraries cannot be used from C++ or Rust without depending on the entire .NET runtime, including its tracing GC, which is obviously extremely undesirable.
And that is probably why Microsoft dropped their plans to write Windows userland components in .NET and decided to write them in C++ instead (exposing COM interfaces).
As I see it, the key theoretical issue is that neither CIL nor arbitrary code written in languages like C#, Java, JavaScript or Python contains enough static information to generate purely reference counted code.
You're seeing the same on Unix. All truly reusable code is written in languages that don't require a tracing GC. Everything that is written in other languages is duplicated for each language/runtime environment.
And therefore you can't (as far as I know anyway) compile arbitrary C#/Java/JavaScript libraries down to reference counted COM in order to make those libraries available to C++ or Rust code.
Certain elements will likely never be ported, like Phone and Modem, but will remain forever in the Control Panel. And the Control Panel will probably be a platform specific feature of x86/AMD64 based Windows installs.
My wishlist for C# is short:
- Allow functions outside of classes
- Structural typing
- Files and directories already provide excellent namespacing. Adopt it instead of forcing namespace declarations
Btw, Linux as a deployment platform works quite well.
Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class.
But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design.
> Adopt (files and dirs) instead of forcing namespace declarations
Likewise.
> Structural typing
Like "dynamic" in C# 4 ? Been there, done that and it didn't take off really. It's useful for some interop cases and that's about it. Strong types, with type inference is more suited to the language design.
https://stackoverflow.com/questions/2690623/what-is-the-dyna...
https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
As for "free" functions: C# already recognizes the usefulness of this in the "using static" directive. This is useful for a lot more than "hello world".
And well, I'd expect them to get it right eventually. It is at least their third evolution of that feature... there was a System.Tuple as well. Wonder if they ever come out and officially deprecate their earlier attempts.
That (mostly) doesn't happen.
I would say that .NET Core was the sole attempt to deprecate a lot of the framework. And most of it came back anyway; see the title of the parent article.
Fairly complex programs can be written with just plain functions, all of them elegantly starting off column 0 instead of being tabbed for namespaces and classes. It works especially well with directory structure based namespaces. eg: Microsoft's own TypeScript.
> Like "dynamic" in C# 4 ?
No not dynamic, I wouldn't use that very much either. https://en.wikipedia.org/wiki/Structural_type_system
Ok, I see that structural typing is a third type system option.
But honestly, I don't want C# and .NET to contain every feature and paradigm ever created. It would be bloated and hard to use. Already there is significant legacy and different ways of doing the same thing, and it's likely to get even worse.
If the language that you ideally want is built around structurally typed free-floating functions, then it probably isn't C#. It probably exists, it's likely possible on the .NET platform, but it doesn't work and think like C#.
That's what the Powershell integration is for.
And projects such as scriptcs and cake
On my new Ryzen 3600 with 32G of ram it runs smooth. So if you go for JetBrains, I definitely advise not to cheap out on the hardware.
Rider on Linux was very good for me, working on C# azure functions.
Not to mention how crazy it sounds having 32GB for an IDE.
Visual Studio, Netbeans and Eclipse run perfectly fine with 8 GB.
I was working app support really, with a fair bit of dev work as well, so needed to run a ton of different tools.
I agree that JetBrains stuff is resource hungry (maybe excessively so); to me it is still worth using it for Java, C#, Python, iOS and Android. For C++ I prefer Qt Creator (though I must say that the idea of switching to CLion and having a consistent IDE experience across all platforms that I work on is tempting).
Add Docker, VM, development database server etc. to the bill, and a 32 GB machine is pretty reasonable for a dev.
Visual Studio with Resharper chokes and dies pretty badly when you get into large solutions with 100k+ LOC and many projects. For years I've been seeing problems when memory usage gets close to 2GB, and the editor and intellisense starts getting laggy and unresponsive. For whatever reason, it is really bad if you have web applications with JS in the mix, to the point where I have resorted to just running WebStorm in parallel to do any front-end work.
[1] Other paid-for Jetbrains products such as IntelliJ Ultimate have the same integration
Then with static using directives, you don't need to spell out the namespaces.
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
You can even put every global function into a single class but still organize your code across multiple files by making them all part of the same partial class.
I personally wouldn't organize my code this way, but it seems like you can achieve what you want today with minimal effort.
Static using directives! Certainly a useful tool, thank you. I had been away from the .Net universe for a while and I think I have some more catching up to do. Some of the newer changes in C# help a lot with reducing code heft, even though it makes the language more complex.
However, the Framework seems to be headed in the opposite direction when it comes to simplicity. Here's for example the IOptions pattern: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...
https://laurentkempe.com/2019/09/03/WPF-and-dotnet-Generic-H...
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ho...
Makes testing easier too because you don’t have to write a fixture around your settings. Just build the class with known setting values without writing code purely for testing.
We have some solid use cases for free floating functions (e.g. business rules that need to be able to arbitrarily invoke each other) which we ultimately decided to scope to one public function per class. This allowed for some other interesting advantages in terms of consolidating tightly-coupled business logic that was formerly spread across the codebase (e.g. items used only by the one function - mappers, request/response models, private utility methods, etc). We even explicitly duplicated out some logic in order to enable completely isolated verticals of BL.
It would certainly be cleaner without having to define a useless class.
F# provides all of them, is shipped with .Net Core 3.0 and also works great on Linux.
A few years back, I was the VP of Engineering at a (now well-known) startup that had chosen to use .NET (on Azure, which is a whole other story). Everything was written in F# by default, _occasionally_ branching out to C# or C++ if it was proven that F# was unsuitable for the job.
We managed to hire a very large team in comparatively little time - and because people who apply for F# jobs either know it (indicating someone interested in looking forwards in the industry), or were interested in learning it (we provided training), quality was better and waste was substantially less overall than I have seen elsewhere in a rapidly scaling team.
Despite what Microsoft may think, F# is the crown jewel of the .NET world, and it is a mistake to sideline it over fears such as this.
Generally large companies and enterprises are resistant to change, and my advice will be to just ask for enough room to get the project executed somewhat within budget and schedule.
There's just few public examples on how to do this cleanly so people kinda have to work it out themselves which I think could be improved.
The vscode integration is barely beyond autocomplete, and it uses more memory than rider does.
The c# story for vscode still has a long way to go before it’s even close to feature parity.
(...and yes, if you scrabble enough plugins you can get more features, but you get more crashes and even more memory slurping. :/)
Omnisharp is the official .NET cross-platform development support system and is used across many different interfaces (VSCode, Atom, Sublime, etc). It's powered by Roslyn [2], the C# compiler platform, and can use the same packages for analyzers and autofixes that VS uses. It also has official debugging support. This is way beyond autocomplete.
It’s not unusable, but for example, I can’t refactor my code base without it crashing, and forget any advanced features like jump to symbol or extract class. The only feature that works reliably for me is autocomplete.
I can only speak for personal experience; omnisharp on Windows and Mac, on .net core (or heaven forbid you use something non standard like unity3d) ...
It’s just terrible.
Perhaps your combination of platform / project is a different story, but I try it again every few months, and bluntly, rider is just better at everything.
Visual studio on windows is also excellent, and the tooling is usually tighter (rider usually lags when new stuff like .net core 3 comes out, and the azure function integration is a bit spotty because it uses the core tools).
/shrug
Tldr; my experience, on multiple platforms on multiple projects has been simply negative every time I’ve used it.
Ymmv.
I can have VSCode installed and running with my personal settings on any OS within 2 minutes flat. I don't have to find a secret license key, login with any account, or pick through a list of 100 features in the installer. Then, once it's installed, well VSCode is just a better experience for the basic act of editing source code. Multiple cursors, quickly opening files by typing the name (without having to type a greater than sign followed by a space first every time like you do in VS), sane default keyboard shortcuts for managing/splitting documents and so on... Plus, it's got way better facilities for working with front-end web code than VS ever had and some other major features such as remote editing oh and one other little thing: it's fully cross-platform.
And that's the reason for VSCodes wild success. Let's hope Microsoft never fucks it up by trying to glom the rest of their Azure/Microsoft Account crap onto it too much.
Luckily, I don't have to work on anything that needs a designer anymore, like WinForms, but if I did I would certainly install VS. Even then - I think I'd only use VS for the designer and go back to VSCode for everything else. (And I love Windows and I used to love VS, having used both of them for 30 years and 15 years respectively.)
But the VSCode team also covered a lot of ground faster than VS ever did, adding feature after feature. So, what do you want for C#? I'm certain that we'll be getting it soon.
The WinForms designer is wonderful. I can throw up an ugly CRUD app that works so insanely fast with it. The web-equivalents are horrible. Everyone is trying to make a rich web app to write rich web apps and IMHO they are all targeting way too low on the "technical ability" scale for their users.
Though web is harder, since apps need to be responsive, and cross plat, and automating code gen of CSS that does that cannot be easy, and having a form designer UI expose settings for how a UI resizes itself doesn't sound like a UX challenge I'd want to tackle.
I find it's the opposite. VSCode is just a very barebones editor with an ecosystem of plugins that may or may not be maintained. I always need to search through a list of hundreds of plugins to figure out which ones I need for this particular techstack.
I started using Rider this year and it's been much, much better than VS and VSCode for me. I can use it in both Windows and Linux. Search experience in Rider is my favorite part of the UX. I find VSCode clunky in comparison.
I use VSCode when doing Vue stuff. I like it for that. But I still miss the nice search UX of Rider. Maybe I need to dive deeper to see if there is a setting or another plugin that can get me that same feeling.
I'm a big fan of IDEs, I couldn't imagine using C# without one.
But I've come to really like the way Nancy has explicit API routes, compared to the implicit conventional style, or slapping attributes all over everything. You can avoid a lot of the magical action-at-a-distance middleware behavior that seems to be increasingly common as well.
Although this won't solve all of your problems, if you can't use F# and want to use a more functional style, then this will help [1].
disclaimer: I'm the author
What are you using in production for Linux ? Kestrel + Nginx ? Any problems encountered with this setup ?
The default uses debian but they have ubuntu and alpine variants too. We stick with the defaults and don't have any preference for distro.
I'm not sure what your thoughts are on Structural Typing, but I've found liberal use of extension methods on interfaces to be a really useful way to get lots of functionality on a wide variety of types.
As for your comment on namespaces, I cannot agree. Again extension methods would not be anywhere near as useful if one can't arbitrarily add code to any namespace, without needing to adhere to a file system structure.
What would change with functions outside of classes? You already have anonymous functions/lambdas, static classes and extension methods if it's about instantiation overhead, and local (nested) functions. Can you explain a scenario where this doesn't work for you?
For namespace declarations, you can just use the same namespace on all classes if you want to keep it simple, and that kind of flexibility isn't available if you use file structure.
Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.
Funnily enough they had a huge team (and over 30 thousand classes) and a lot of time (over two years) but they couldn't finish it.
Edit: Should have said it was J2EE rather than .Net
We have the base MVC project that references services for DI. We load in another DLL via Ninject to add customization on top of those services (custom parsing of some magnetic card swipes for different institutions we deploy to and such). I discovered that while all of our services (~20) had an interface, only one of them was being customized/overridden. This mean that in order to do something as simple as a parameter change, it had to be changed in way too many places: the definition, the implementation, and the usages.
Why have that extra layer? If we need to override in the future, we can add more interfaces. For now, I just want to maintain my sanity.
For small applications, instead of going full on DI, I sometimes just make a few simple public static properties, that I initialize on program startup. Then you can initialize them differently in your test harness. This is a lot easier to understand if you're not an expert in the chosen DI framework or app framework.
I prefer making interfaces instead, though. I find it useful to make the boundaries between components explicit.
Then again, I rather use maintainable programming languages, instead of writing hieroglyphs.
I'm now currently in the position of having to decide whether it's better to accept defeat or use T4 or similar to write the 1000+ line wrapper class to undo the mistake... You'd think Microsoft would at least remember to do dependency inversion through interfaces in their own C# code.
I have had and continue to have the opposite experience of you. I use Ubuntu with VS Code and a few C# plugins that have greatly allowed me to navigate the .NET Core framework and write code with minimal references.
Even, with Visual Studio (unless you use R#), you will always run into issues where you aren't sure where the function or class lives. That's why you go read the documentation or ask SO.
The more you write webapi's the easier it is.
> Structural Typing
Dynamic was the closest to it, but it has significant performance issues. Tuples and structs do exist also.
> Allow functions outside of classes
No.
> Verbosity in C#
????
> most popular libraries will nudge you strongly to use Dependency Injection throughout the app and implement everything as a class and to extract interfaces out of it.
You do realize C# is mostly a strong Object Oriented language hence why they (the libraries) urge you to do that.
If you want functional so much use F#.
Mads Torgersen did a proposal related to this, it's in the C# Version Planing as version X.X, so maybe in the future we're going to have those capabilities.
use a delegate for this:)
Btw, for dev on Mac I use Jetbrains Rider, its like VS with Resharper or even better. Its also available on Linux. Otherwise, for smaller (micro)services, VS Code works fine. As soon as you start fighting with Code, maybe your solution is too big?
What do you mean? Isn't that just anonymous functions?
Objects are just initialized memory with a vtable, or actors that sends and receives messages...
https://www.goodreads.com/book/show/31550964-functional-prog...
I'm only a few chapters in, but already it has transformed my C#-writing in many ways, and I have ton of practical ideas on how to better structure my programs in a functional way as I go on.
Also, from what i saw, nobody is actually in a rush to "move" to .NETCore, most big shops still rely on .Net Framerwork , i still do some occasional work on a project which is using .Net Remoting :)
I know plenty of people that would love nothing more than to be up to date and to start using .NET Core, but many of them rely on certain libraries that simply aren't there yet. I know a load of Umbraco devs that are eager to make the jump, but until their CMS supports it, they're kinda stuck if it's a dependency.
People are hold back because of deprecated tech and because no one touches a running system without need. And maybe that black matter developers just do not know yet ;).
I've not met a single .NET dev that doesn't want to use .NET Core. Hell, if anything, a lot of them would love the opportunity to use .NET on a Unix system, and to use established tooling not available on Windows. The problem is that the tools they use aren't ported yet.
Umbraco is a key example, as the most popular .NET CMS in use today. It's a great CMS, but we're at least 1-2 years away from a .NET Core implementation, and probably even longer if we're hoping for a first-class Postgres/MySQL backed implementation. Until then, as you've rightly said, there's no need to switch to .NET Core.
Seems like every project I waste hours trying to figure out the mess that nuget creates.
They're usually caused by a mixup between local packages and the GAC, which .NET core doesn't use.
When you publish a .NET core application, you can publish as stand alone and see right there in the publish directory all the DLLs that are being used.
For example, because NuGet allows packages to import .props and .targets files you can have packages that add arbitrary references that don't match your target framework or runtime. Now you could say "oh, that's the package's fault, not NuGet's", but often the reason a package includes .props or .targets files is to work around other shortcomings in NuGet.
Has anyone here migrated from .NET framework > .NET core lately? Think it's time for me to give it another go?
Once the app is working with SDK style projects, then try changing the runtime to netcoreapp. Often it just works; if it doesn't, you'll get useful error messages.
I don't know .NET at all and the numbers there seem mind boggling. Can someone put this into some kind of context?
That being said, I'm sure there was indeed an impressive amount of code that had to be ported.
.NET Core is the new cross-platform runtime and now supports more than half of all the API surface available from the older framework. The number itself isn't anything special but just denotes how big the standard library is.
https://docs.microsoft.com/en-us/dotnet/api/?view=netcore-3....
* VSCode/Linux vs VSCode/Windows. Full VS on Windows worked OK.
.net HttpClient is based on outdated cookies RFC, RFC6265(that is 8 years old) is yet to be supported [1]. And what can you do today without good http library?
This RFC seems to be all about rejecting certain cookies under some very specific security rules. How impactful is this really? Is this affecting your app somehow?
How does a lack of support for an RFC (which is still being revised) that outlines where a cookie should not be accepted in edge cases mean the HTTP library is not modern? Where are you running into this issue in a real app?
I had discovered few bugs in cookies handling myself, compared behavior to competitors and moved on. If cookies handling is not enough, i came across inconsistent behavior on different platforms: on Windows it uses WinHttpHandler, on Linux its curl lib(if i remember correctly). And they both handle edge cases differently.
There shouldn't be any platform issues unless you're using an even older version or manually forcing it. What bugs in cookie handling did you encounter? This is very widely used code and the team is responsive so if you can document the issues then they can help.
A.) Not even stdlib
and
B.) Doesn't support async/await
Is an odd choice.
1) Dapper - https://github.com/StackExchange/Dapper
2) DbUp - https://dbup.readthedocs.io/en/latest/
3) Autofac - https://autofac.org/
The Kestrel source code expanded my view of what was possible in C# with respect to low level operations on memory (check out the fixed statement [2]).
A part of me doesn't want to like Microsoft because of their anti-competitive behavior in the past and crappy developer experiences from 10 years ago. Now, I sound like a Microsoft shill because of how good .NET core is.
[1] https://github.com/restsharp/RestSharp
[2] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
It sounds like you're picking on a strange issue to disparage .NET without any real experience in it.
If your whole reason for not using .Net Core is based around this weird and honestly unimportant edge case, all that tells me is that you have a strange bias against the framework for some other reason and looking to nitpick.
And yes the HttpClient is modern. Your entire argument so far has been a single RFC issue that is labeled up-for-grabs because it's so minor and doesn't really affect anyone. Claiming the http functionality and the whole stack isn't modern because of it just doesn't add up.
The current generation API for my library is extremely limited because I've never needed one but you are the perfect market research participant. It's an API I'm actively looking to improve.
PDF/A compliance is probably quite a way off though.
[0]: https://github.com/UglyToad/PdfPig [1]: https://github.com/UglyToad/PdfPig#document-creation
So we created a "bulk print" option. They tick a bunch of checkboxes for the Foo items, then click the Print button.
Internally we merge all those PDF's together and send one print job to the printer's queue. We used DevExpress [1] to accomplish this, and it worked very well. The only problem: it's expensive.
Multi-billion dollar companies don't mind paying the price tag, but smaller shops sometimes think twice. If a free or near-free alternative existed, that would be fantastic.
[1]: https://github.com/DevExpress-Examples/how-to-merge-document...
It's useful to know that this is a real use case too, I always assumed it was implemented 'just because' but the scenario you describe makes sense.
[0]: https://pdfbox.apache.org/docs/2.0.1/javadocs/org/apache/pdf...
Edit: another option is this pdfium wrapper for NET Core though it merges one pair at a time: https://github.com/GowenGit/docnet
basically we don't need a lot, mostly switch fonts/text sizes/images (generated barcodes, logos) and of course pdf/a-3(a/b/u) for invoice. so apis that translate the html into the layouting of pdf is the bigger problem.
[0]: https://github.com/AngleSharp/AngleSharp [1]: https://html-agility-pack.net/
Yeah HTML to PDF is a tricky one, presumably wkhtmltopdf/pechkin doesn't work out because of licensing / interop issues? Other than that the only other one I'm aware of is Aspose which is expensive as you say.
Images (along with font subsetting and fixing the gzip implementation) are the next thing I plan to implement so it's helpful to know its a real requirement.
btw. itext is a really great library, unfortunatly itext has a problematic licensing and I tought they were jocking after they gave me prices.
That version has a few unfixed bugs, e.g. merged table cells are sometimes broken, but the code quality is OK on average, relatively easy to fix them if you need to.
[1]https://skia.org/user/sample/pdf [2]https://github.com/mono/SkiaSharp/
https://www.reportlab.com/dev/opensource/
This is a Python implemented API/framework. However, you could use IronPython (compiles to CLR and .NET) and import Reportlab. I've never used it that way, but it's worth the try!
Hope this helps.
I've successfully used it both in .net 4.7 and .net core 2.2 to generate complex pdf structures, and it has been a great experience.
While selling those tools under AGPL certainly would be both Free and open source (but not gratis!) - the only real impact of the AGPL would be on our client - in that they'd be guaranteed the four freedoms (but they generally specify that in the contract anyway - they want the possibility to continue development in house, or with a possible new partner down the road).
However, the products are proprietary in the sense that our client only ever use then in-house and don't distribute them or expose them as public facing services. So no redistribution.
So you're technically correct (the best kind of correct!) - I just think the distinction is important, as you certainly could sell software with AGPL components.
The few places I know that work with .NET are a long way from migrating yet. Are there any similarities with the Python 2/3 port? I imagine language level compatibility makes the transition much easier.
It's mostly legacy and enterprise apps but it wasn't until .NET Core 3.0 (released last month) that it was viable to migrate everything perfectly anyway so it'll take time for that to filter through.
This is nothing like Python 2/3. .NET Standard has been out for a while and all the major libraries are compatible with both runtimes, and that now includes desktop APIs too.
If you work in a place where you develop many products for many clients, budgets are lower and you have much to maintain and develop. Porting is in my experience almost never done, because there is no business case to justify it.
This is rather anecdotal but in my little area of the world there is little. .Net is moving too fast and too impractical to really be worth it on enterprise these days. The main problem for us is the libraries for handling thing like data-formats.
Linq-to-sql is still better than Entity Framework from a time to market perspective, but both of them are really, really slow. XML interpreters reminds me of learning JAVA back in the early 00’s, they execute well enough but you need two million lines of code to do what Python does in 20. Working with SOAP and SAML often requires you to build additional parts on top of the fairly terrible APIs and some older stuff, that used to be in .Net has simply disappeared into unmaintained third party libraries. Connecting up Microsoft’s own System Center (2012) has gone from being a simple service reference to you having to build your own library because Microsoft moved to Azure. Even official libraries for AD integration are half finished and require you to build your own service APIs to look up stuff like unique IDs.
.Net Core is really good at building CRUD services and really bad at everything you actually need in Enterprise situations because almost nothing in the real world actually requires that.
Luckily both Microsoft and Azure are treating things like Python as first class citizens both on Windows Servers and in Azure. Their own Powershell has become a much more powerful tool than C# has as well, so it’s not like I dislike Microsoft at all, it’s just that .Net has spent the past decade becoming less and less useful for what we need it to do.
What I do know is that everyone is relieved now and incredibly happy that they did it. Hosting the applications on Linux is so much easier, and they appear to have twice the performance as well. Still not sure why, but it's definitely correlated with hosting them on Linux.
Most of our customers are doing transitions to .NET Framework 4.7.1 and 4.7.2 from 4.5 and such, .NET Framework 4.8 still isn't a viable option for them, and plenty of in-house, and third party libraries they depend on aren't yet on .NET Core.
By .NET 5, they might start moving into Core infrastructure.
And for those teams the multi-platform part of .NET Core isn't that appealing, because UNIX deployments are already covered by the Java teams anyway, with products whose .NET counterparts are yet to be 1:1 available.
Until IT certifies server images with .NET Framework 4.8, it doesn't get green light for new projects.
So is the nature of enterprise computing, I know a couple of customers still using Red-Hat Enterprise 5 on their servers.
The previous one had a big product based on a COM-turned-WCF architecture for years. WCF is dead/not a thing on .Net core.
The one I'm currently looking at just recently (last year-ish?) migrated from idk what to .. a big pile of WCF. I don't think that will every migrate either.
(yes, there are ways to replace WCF if you - and these examples don't require that - ignore transaction support, but it's a nightmare to migrate as far as I can tell .. and you end up with a product that looks exactly the same to the customer)
I've dabbled in .Net core since its inception and would love to use it more, but the whole WCF story was usually a deal breaker for usage at work unfortunately.
We ultimately restructured our projects a bit to dramatically simplify the number of points of touch for managing 3rd party nuget versions. We now have a common platform core (targeting NetStandard 2.1), with specific application implementations consuming it and targeting NetCore 3.0. Mercifully, we were able to capture 100% of our 3rd party dependencies into this common platform core project, so we no longer have to worry about mismatches between our own internal projects or nugets. The picture for us is: (3rd party libs)=>(shared platform library)=>(specific application). This seems to work out really well, and with the newer AOT/linker capabilities, we are resting easier knowing that we can shake off some unused bytes if our distributions start getting a little chunky due to this approach.
Also, the .NET compatibility pack is a life-saver for anyone stuck using System.Drawing or DirectoryServices. Those are our only 'difficult' windows dependencies, and we expect to be able to replace these with cross-platform alternatives next year.
Of course, lots of Microsoft services run on .NET Core. Last year, the Bing team talked about how their move to .NET Core 2.1 gave them big performance jumps here: https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-c...
(disclaimer: Microsoft employee, .NET team)
From what I've seen, all new projects are being done in .NET Core, and legacy apps are not really being migrated over. .NET Core 3 might fix a lot of these issues, but in the past there were a lot of library unavailable in Core that you could only use in Framework.
I haven't had a recruiter mention Framework in over a year now, I don't believe. It's all Core now.
In general, .Net framework is legacy. I see very little green field development being done with .Net framework.
Language level compatibility doesn’t help. There are so many differences between ASP.Net and EF6 between .Net framework and .Net Core that it isn’t an easy lift. But, MS did the right thing by not worshipping at the alter of backwards compatibility for a change.
We have not migrated the 4-5 .NET apps we have and don't see a pressing need yet.
The game is Unity so C# on the app and .NET Core on the backend is nice to match up, common code.
The client on the proptech is Microsoft focused so they chose Azure/dotnet/C#/Xamarin.
Initially the proptech drawing/document app was on .NET Framework 4.6 and had the app running with Xamarin on Android + iOS when the app was to run on Android or iOS tablets/pads.
However, now the project uses Surface Books with touch/pen and Windows Ink so we went to .NET Core for UWP and that is the main app target now though it still runs on iOS/Android. Xamarin is quite nice for business apps that have to integrate to dotnet or any backend really. Lots of great developing and testing tools.
We have updated from .NET Core 1 to 2 to 2.1 and 2.2 and will be going to .NET Core 3 soon, by end of year.
The web app, apis and app are all .NET Core + Xamarin and it is nice. I have been doing .NET apps since 2000 along with Python, PHP and Node apps for interactive / promotional / game / drawing / rendering products and .NET Core is pretty clean and I love the nix implementations as well.
.NET Core 1 + updating to .NET Core 2 was a little rough reminiscent of the .NET 1.0 to .NET 1.1 and 2.0 initial start, lots of breaking changes, but .NET Core 3.0 is pretty solid and slowing down on massive changes, libraries and frameworks are almost all on it for what we use including IdentityServer4, SignalR, Xamarin (Standard) and more. The list of breaking changes is small this time [2].
There is the typical .NET base library depth that random deep errors you have to hunt down, and the thousands of libs/packages, but for the most part it has been not much more than speedbumps. .NET Core comes with lots of great security features for APIs/apps as well which helped us with compliance/security scans [1].
Now that .NET Core is pretty solid, and the linux/nix implementations and tools are far along, I expect with the ease of Azure, for Microsoft to really take some ground.
Microsoft ecosystem is a complete setup, from Visual Studio/Code to Azure to dotnet to Xamarin and UWP to Teams/Office and Surface Books with Windows Ink and even CI/github. They have retooled quite nicely, I left .NET in 2007-2010ish when developers took a backseat and they got it handed to them with mobile, but they are developer focused fully again.
Side note: I also love the Surface Book with the disconnecting screen and Windows Ink. My current machines are massive custom PC, massive Mac Pro (cheesegrater from 2013 that I love) and Macbook but seriously considering going Surface Book and probably just going to be updating/building on a Mac Mini for our Unity games instead of upping to the new cheese grater as it is the cost of a car or major home renovation project for the specs I want.
[1] https://docs.microsoft.com/en-us/aspnet/core/security/?view=...
[2] https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core...
Time will tell how many existing libraries are fully ported to Core. For the foreseeable future, I expect that I'll still have to be working with the legacy framework, as there are so many SDKs that I require to interface with different products that will never receive the investment to bring them in line.
WCF, for example: Its a legacy technology that is also horribly complex and never really took off. It was never really a good solution if you wanted cross-platform RPC, and therefore has a userbase that doesn't overlap much with the people they're trying to attract with .NET Core. If you're trying to migrate to .NET Core in order to go cross-platform, you probably want to be migrating off of WCF, anyway. And if that's not true of you. then .NET Framework 4.8 probably still suits your needs, anyway.
Replacing WCF won't be easy in a lot of cases not so much because there's a lot of WCF-specific code, but simply figuring out where on the flowchart of possible concerns to migrate to:
Were you using WCF for RPC? Try gRPC, unless you really need SOAP support or worse WS-* support (I'm sorry) and then, uh, good luck. (Though SOAP libraries for .NET Core do exist and turn up in search results, depending of course how far down the WS-* rabbit hole you need to go.)
Were you using WCF for REST API? Try ASP.NET directly now instead of indirectly. Need client tools support? Take a look at Swagger (now aka OpenAPI) to replace WCF's odd extensions to SOAP's WSDL for REST APIs. Or maybe look into GraphQL (or less commonly Falcor) if you want something really new and wild.
(Were you using WCF for P2P communications? That hasn't been officially supported since Vista and whoops.)
WCF was actually pretty well built for exactly this sort of migration (the focus on interface-first design, data contracts, etc; in some cases it's just writing interface implementations where there were none before), and even the most WCF heavy applications were far more about fiddly giant bits of config files than actual code specific to supporting WCF. I really do think that half the challenge in migrating away from WCF has more to do with figuring out which tool (or tools, given you might have been using WCF for multiple things) to migrate to, as much as any actual code migration.
I haven’t tried building a windows app in 10 years.
That said, in the past I found it darn easy to wire an interface up quickly.
I recently downloaded visual studio and could not quickly figure out how to get a GUI going (design view would not show).
What is the recommended approach with this new stuff?
Some buttons and textboxes on a form with an onChange method and a data bound grid?
This used to be pretty easy.
I also had problems doing anything other than toy WPF projects. IMO the .NET Core support for the GUI frameworks is not ready for prime time. Building GUI apps in .NET Framework is still a great experience though.
[0] https://developercommunity.visualstudio.com/content/problem/...
I just fired up an attempt using Windows Forms / Net Framework after scrolling down to that combo. It looks good so far.
The recommended / modern approach for 100% new applications would probably still be UWP (WinRT XAML) / Core, except getting that up-to-date with the latest .NET Core improvements is currently delayed until .NET 5.
Fast forward to 3.0, Microsoft did it again, and nobody seems to care.
https://github.com/dotnet/corefx/blob/master/src/System.Linq...
(Security sandboxing is obviously a different matter, but Microsoft hasn't seemed too keen on the old .NET 1.0 CAS model for over a decade now, and has mostly recommended against it.)
Example code: https://github.com/dotnet/samples/tree/master/core/tutorials...
Anyway, who cares about it, when the bulk of job vacancies are offered by the enterprise. It's a lot easier to find a junior dev role for a .NET dev than for a Ruby dev for example: https://www.youtube.com/watch?v=ZUgNy-okDQ4