
.NET Core 3.0 Concludes the .NET Framework API Porting Project - mandar_badve22
https://github.com/dotnet/announcements/issues/130
======
jug
.NET Core 3.0 was major achievement for Microsoft and I like the air
surrounding the project and some around it like Visual Studio Code and Windows
Subsystem for Linux.

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.

~~~
gnud
I love it every time I get the 'old' control panel. It means I know where the
switches are, and more importantly, what they do.

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.

~~~
cm2187
And also items from the old control panel don't appear any more when you
search in the start menu.

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?

~~~
gexla
Let me have their pretty UI. If you want to geek out, there's Powershell.

~~~
LIV2
Powershell is shit for discovery & not useful at all for the majority of
Windows consumers i.e regular users. You shouldn't need to learn powershell to
switch your audio output

------
jeswin
Given that our deployment platform was Linux (for a .Net Core 3.0 project), I
was determined to use Linux and VS Code for development. That was a fail; the
verbose nature of C# and the Framework APIs make it impossible to be
productive without significant help from a full-fledged IDE like Visual
Studio. One might think the verbosity can be reduced by clever coding (and
adopting a functional style), but that's not so easy. If you're writing a Web
App/Service, the Framework APIs and 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.

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.

~~~
SideburnsOfDoom
> Allow functions outside of classes

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://stackoverflow.com/questions/2690623/what-is-the-dynamic-type-
in-c-sharp-4-0-used-for)

[https://docs.microsoft.com/en-
us/dotnet/csharp/programming-g...](https://docs.microsoft.com/en-
us/dotnet/csharp/programming-guide/types/using-type-dynamic)

~~~
goto11
Structural typing is different from dynamic typing. C# supports structural
typing in the form of tuples and anonymous types. But you can't return an
anonymous type from a method. This is a significant limitation.

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".

~~~
moron4hire
You can't return an anonymous type, but the syntactic difference between an
anon type and a tuple is two characters: parens instead of curly braces.

~~~
Faark
And the little "new" in front of it. I actually preferred the curly braces
version and would have loved for them improve it instead of creating a
replacement.

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.

~~~
SideburnsOfDoom
> 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.

------
samuell
Can I use the occasion to recommend an VERY good book on modern C#
programming: "Functional Programming in C#" by Enrico Buonnano:

[https://www.goodreads.com/book/show/31550964-functional-
prog...](https://www.goodreads.com/book/show/31550964-functional-programming-
in-c)

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.

~~~
LordN00b
The first half is an excellent book, buuuuut becareful as you get into the
second half, it really becomes a book pimping his own library.

------
mariusmg
I've tried to port a MVC project to .NETCore 2 a while ago, it was pretty
painful mainly due to lack of @helper syntax in views (everything which relied
to @helper had to be changed).

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 :)

~~~
EnderMB
There are some similarities to Python 3 in .NET Core adoption.

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.

~~~
oaiey
Just with the difference, that there is not 2/3 culture split here. Everyone
agrees that .NET Core is the future and should be used. The universal cloud
adoption (e.g. AWS Lambda), containerization and Linux deployments are so huge
selling points for .NET Core.

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 ;).

~~~
EnderMB
For reference, I'm mostly talking about brand-new projects, and purely from my
perspective as a former .NET dev that still spends time with the local .NET
community.

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.

~~~
scarface74
I don’t care about being able to develop .Net apps on Linux. Being able to
deploy to Linux is a game changer especially in the cloud. Anytime that you
add Windows to a cloud environment you get hit with the triple whammy of slow
startup times, increased licensing costs and increased resource requirements.

------
LandR
My biggest issue with .net core and .net in general, although .net core seems
worse, is nuget issues and it causing issues with binding redirects.

Seems like every project I waste hours trying to figure out the mess that
nuget creates.

~~~
marsrover
I really don't understand how you're having binding redirect issues with .NET
core.

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.

~~~
lazulicurio
There's still plenty of ways reference resolution with NuGet can go wrong,
even without the GAC.

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.

------
asplake
> ...increased the number of .NET Framework APIs ported to .NET Core to over
> 120k, which is more than half of all .NET Framework APIs

I don't know .NET at all and the numbers there seem mind boggling. Can someone
put this into some kind of context?

~~~
denisw
The crazy high numbers are due to a fairly Microsoft-specific definition of
"API" in this context. What they count here is class members; so they ported a
class with 15 methods and 3 properties, they'd count this as "18 APIs" (or
perhaps 19 - not sure if the class itself counts as an "API" as well).

That being said, I'm sure there was indeed an impressive amount of code that
had to be ported.

~~~
sytelus
All public members are legitimate APIs. Would you be more happy if every
property had get* and set* methods so now it counts as two?

~~~
ptx
I think the point was that often "an API" means a larger collection of
functions, classes, properties, etc. Like the COM API, the DirectX API, the
MFC API and so on.

~~~
denisw
Yes, that's what I meant. The use of the term "API" for a single public code
element is something I have not come across in any other language community,
hence the clarification for those who are not familiar.

~~~
tasogare
I've seen it before in Apple communication. I hate this usage. It doesn't cost
a lot of keystrokes to write "API members" which is more precise.

------
samuell
.Net core is fantastic. What a surprise to find a software from Microsoft that
worked a LOT smoother on Linux than on Windows* :D

* VSCode/Linux vs VSCode/Windows. Full VS on Windows worked OK.

~~~
autechr3
This has been my experience as well. JetBrains Rider on my mac is nice. I
prefer it to VSCode. I'd recommend it if you can afford it.

------
Dolores12
>With .NET Core 3.0, we’re at the point where we’ve ported all technologies
that are required for modern workloads

.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?

[1]
[https://github.com/dotnet/corefx/issues/29651](https://github.com/dotnet/corefx/issues/29651)

~~~
manigandham
HttpClient is fast and efficient, and the built-in cookie container handles
all the standard functionality, although many users just read and handle the
cookie header directly.

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?

~~~
Dolores12
Well, you expect http library to be as good as everywhere else.. like python
requests. When library is not updated due to app compatibility issues i would
not call it modern. It is good enough for basic use, tho.

~~~
manigandham
HttpClient supports http2, the latest protocol features, has been rewritten in
managed code with sockets, and includes advanced handling to balance
connection lifetimes with DNS updates. It's about as modern as it gets and we
run 10 billion requests per day through this code without issue.

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?

~~~
Dolores12
> 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.

~~~
manigandham
HttpClient uses sockets in managed code since .NET Core 2.1 which was released
in Oct 2018: [https://docs.microsoft.com/en-us/dotnet/core/whats-
new/dotne...](https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-
core-2-1#sockets-improvements)

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.

------
merb
sadly .net core still lacks a good pdf library that is not priced over the
top. (and at least supports building pdfs and creating pdf/a 3's.)

~~~
UglyToad
I'm currently building an open source (not copyleft) PDF library for.NET
standard [0] and I'd be interested to hear more what you need on the document
generation side.

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](https://github.com/UglyToad/PdfPig)
[1]: [https://github.com/UglyToad/PdfPig#document-
creation](https://github.com/UglyToad/PdfPig#document-creation)

~~~
merb
wow that looks really nice. actually we mostly do html to pdf, but maybe I can
look into your project and try to add it (if there is a nice html/dom library
like java has with jsoup).

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.

~~~
UglyToad
Thank you for the response.

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.

~~~
merb
actually wkhtmltopdf/pechkin both won't support pdf/a-3 and have a not so nice
output. aspose is actually really cheap, compared to others, unfortunatly
their support is trash: [https://forum.aspose.com/t/html-to-pdf-pdf-net-fonts-
error-o...](https://forum.aspose.com/t/html-to-pdf-pdf-net-fonts-error-on-
macos/198233) i.e. pdf/a-3 does not work on mac (didn't tried linux, but I
guess it has similar problems)

btw. itext is a really great library, unfortunatly itext has a problematic
licensing and I tought they were jocking after they gave me prices.

------
mjfisher
Can anyone closer to the .NET community than I am comment on the wider
adoption of .NET core on standard line of business applications?

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.

~~~
manigandham
Last 5 startups have used .NET, all of them have migrated and all new projects
are on .NET Core. Every major dev shop I know starts new projects on Core.

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.

~~~
sebazzz
If you have one product (like startups) it is easy to port. You have, in
relative terms, nearly unlimited budget and incentive to stay on the latest
and greatest.

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.

------
thrower123
While I'm happy to hear this on one level, as it likely means that .NET Core
is finally going to be approaching some levels of stability that allow it to
be used in earnest for production usage, I'm somewhat dismayed. There's still
a lot of things missing from it that the 4.X full framework version had, and
this feels like it is the door slamming shut on hopes that existing code could
be seamlessly upgraded without a lot of rework.

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.

~~~
mumblemumble
FWIW, the decisions on what not to port that I'm aware of seem to make sense.

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.

~~~
WorldMaker
Worse than that, too, was that WCF tried to be an "all worlds" solution, so it
was an okay-not-great RPC toolkit, and an okay-not-great REST API toolkit, and
an okay-not-great IPC toolkit, (and it tried to be a terrible P2P
communications toolkit for several years), and so forth.

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.

------
privateSFacct
Question:

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.

~~~
scott00
If you were trying WinForms, the designer does not yet work for .NET Core
apps. The WPF designer is supposed to work with .NET Core, but there was a bug
in it in the first VS release that might have been the cause of your issue[0].

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/...](https://developercommunity.visualstudio.com/content/problem/743966/163-xaml-
designer-not-showing-for-net-core-30-apps.html)

~~~
privateSFacct
Very helpful. I thought WPF / Core was the recommended / modern approach.

I just fired up an attempt using Windows Forms / Net Framework after scrolling
down to that combo. It looks good so far.

~~~
scott00
Yeah, I think the Microsoft messaging would naturally lead you to that
conclusion, though generally they avoid saying it explicitly. I think in a
year WPF and WinForms will probably work great under .NET Core, but I wouldn't
use either for real work right now. My recommendation would be to use .NET
Framework for GUI work right now, but do it in such a way that the upgrade
path is easy. The way to do that is to create the project under .NET Core, and
then hand edit the project file to change the <TargetFramework> element from
"netcoreapp3.0" to "net472". That will give you the new project file format
and make it easy to upgrade when they finish getting the bugs out. The other
main thing you should do is to create any libraries as .NET Standard 2.0
libraries, which work with both .NET Framework and .NET Core.

~~~
1wd
Can you put WPF code in .NET Standard 2.0 libraries somehow?

------
k_
Shouldn't this link to
[https://github.com/dotnet/corefx/issues/41769](https://github.com/dotnet/corefx/issues/41769)
instead since it's redirecting there for discussion?

------
pknopf
You know what's funny? ASP.NET Core 2 previews dropped full framework. The
community freaked out, warning of a Python 2/3 split, and Microsoft
backtracked.

Fast forward to 3.0, Microsoft did it again, and nobody seems to care.

~~~
manigandham
True, it's another lesson in change management and perceptions. Looks like
people have finally figured out .NET Core is the clear future and it's about
time to move on from the legacy framework.

------
jcmontx
I never understood why they didn't port IQueryable. I never really updated my
Azure functions from runtime v1 to v2 becuause of that. Dealing with Table
Storage without it is a pain in the ass.

~~~
oaiey
IQueryable is the base of LINQ. I think you are looking for a certain provider
not for the interface.

------
Rapzid
It would be great if app domains or some other form of sandboxing came back?
Perhaps with faster communication between domains..

~~~
WorldMaker
Depending on your needs, of course, AssemblyLoadContext supports unloading, if
the goal is simply loading then unloading plugins.

(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...](https://github.com/dotnet/samples/tree/master/core/tutorials/Unloading)

------
pts_
And yet it's not used for rockstar projects (change my mind).

~~~
oblio
What's a "rockstar project"? :-)

~~~
rodgerd
One that gets high, trashes the room, drives an expensive car into the hotel
swimming pool, and breaks up the band to release a mediocre solo project, then
has to go back to touring with the band when the money runs out.

