18 ms·

.NET Core 3.0 Concludes the .NET Framework API Porting Project

297 points by mandar_badve22 7y ago

k_ 7y ago
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?
jug 7y ago
.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.
- donedealomg 7y ago
  There are rumors that the WindowsNT kernel will be replaced in the future with a Linux Kernel with a Windows Desktop code on top of it. Can't wait for it. I know 2020 is going to be the year of the Linux Desktop... but....
- mtgx 7y ago
  Nadella has made it pretty clear, whether explicitly or implicitly, that Windows is a dead-end product for them. You could've also deduced this from how they selected their CEOs (cloud guy vs product/software guy or even a sales guy like Ballmer was). When you've already decided a product is a dead-end, you ignore it and don't spend as much in Q&A. You also try to squeeze your customers for all of their worth, even if that pisses them increasingly more, because you know the product has no future anyway so might as well maximize the revenue at all costs - which is also what Nadella has been doing with all the Windows 10 tracking.
- pjmlp 7y ago
  Windows userland is being rewritten in COM since Vista, as the Windows team picked up the Longhorn ideas and used them in COM after winning the WinDev vs DevTools politics, I doubt they will change route. 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.
  - zaphirplane 7y ago
    Hey for people that don’t follow windows internals and politics closely, what did the devTools champion ? What are the longhorn ideas that are getting into windows ?
    - pjmlp 7y ago
      Long story short, that you kind have to assemble from blog posts, forum comments, between the lines articles and so on. 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-hilo-a-complete-c-windows-7-sample-application/ 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-generics-research-project-history-the-msr-white-paper-from-mid-1999/ 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.
- gnud 7y ago
  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.
  - jug 7y ago
    Yes, if things keep changing around or is hard to find, that's annoying but I see this as a separate problem from a bad pace and inconsistency. Nothing here in particular hinders good and well researched design.
    - y4mi 7y ago
      I could find stuff in the old panel without knowing where it is. I can't in the new one. Either because the options are missing entirely or because they're too well hidden. 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.
  - pantalaimon 7y ago
    Not to mention that the 'old' control panel has a lot more options!
  - simonh 7y ago
    >It means I know where the switches are, and more importantly, what they do Or even more importantly than that, that they even exist in there somewhere.
    - AndrewDavis 7y ago
      My goodness. 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.
- dvfjsdhgfv 7y ago
  I can sum up the situation with two sentences: 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.
  - platz 7y ago
    Core apps can be deployed standalone
  - gameswithgo 7y ago
    With .NET Core 3, you can deploy them standalone, and performance is much improved. So you might have a happy middle ground available now. 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.
    - huzaif 7y ago
      Piggy backing on this a bit.. 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.
- mumblemumble 7y ago
  This oldie seems relevant: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c... 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.
  - crazysim 7y ago
    ChromeOS? Is that a success? Lots of concessions there I guess though.
- shawnz 7y ago
  The old control panel can never be removed, because a significant amount of legacy software integrates itself into the old control panel and therefore wouldn't be usable if they removed it.
  - teddyuk 7y ago
    They also contain decades of bodges and quick fixes to get stuff to just work - working out what they need to keep and throw away must be a nightmare.
    - cptskippy 7y ago
      Microsoft is gradually porting what's necessary out of the Control Panel in a controlled manner. Rather than offering 1:1 functionality to existing items in the Control Panel, they're examining and rethinking everything. The new Settings App is a cross platform legacy free future. 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.
donedealomg 7y ago
Microsoft acting to be a good open-source citizen. Did hell freeze over? Congratulations. I hope Blazor kills Javascript.
mjfisher 7y ago
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.
- moksly 7y ago
  > adoption of .NET core on standard line of business applications 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.
- breakingcups 7y ago
  We're using .NET Core for a few new projects. Our situation is a bit different as we build bespoke software for a wide range of clients. We're pretty satisfied with it.
- pjmlp 7y ago
jeswin 7y ago
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.
- denisw 7y ago
  If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically. https://code.visualstudio.com/docs/languages/csharp https://code.visualstudio.com/docs/languages/csharp
  - james_s_tayler 7y ago
    It's still nowhere near the same level of experience that Rider or VS offer.
    - rraghur 7y ago
      I use VSCode with C# extension. THe only thing I missed was the additional analysis and quick fixes that full VS provides. However, that got sorted out by installing Roslynator in VS Code (works on linux too) and I couldn't be happier.
    - wayneftw 7y ago
      Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time. 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.
mariusmg 7y ago
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 :)
- manigandham 7y ago
  I find the opposite to be true. Many companies are moving to .NET Core, especially the independent dev shops. Cross-platform, easier to develop, faster and cheaper to run, and now supports desktop APIs.
- EnderMB 7y ago
  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.
  - sebazzz 7y ago
    Many libs already support it. But the end-users, the web applications, are the problem. If you haven't properly separated business logic from UI, which might very well be the case if your project budgets aren't too high or other causes, you will have a rewrite on your hands instead of a port. A rewrite which is, especially on low budgets, not worth it.
  - oaiey 7y ago
    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 ;).
Dolores12 7y ago
>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 7y ago
  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?
  - merb 7y ago
    especially since you need to enable the cookie container functionality manually and you can override it by yourself
    - Dolores12 7y ago
      or use different language with good library that support 8-year old RFC.
      - manigandham 7y ago
        C# is a language but .NET is a runtime and standard library. If this issue is really such a problem, you can use any of the dozens of open-source libraries available or just implement your own cookie container that follows this RFC in about a day. It sounds like you're picking on a strange issue to disparage .NET without any real experience in it.
        Dolores12 7y ago
        No, i just didn't like the wording in the original post mentioning all 'modern workloads' , while ubiquitous thing like cookies in httpclient is still not according to 8 year old standard. Does it make any sense now?
asplake 7y ago
> ...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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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.
deleted 7y ago
[deleted]
pts_ 7y ago
And yet it's not used for rockstar projects (change my mind).
- oblio 7y ago
  What's a "rockstar project"? :-)
  - rodgerd 7y ago
    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.
- cyptus 7y ago
  dot.net and bing.com are running under aspnet core 3.0
  - pts_ 7y ago
    Um dogfooding doesn't count.
- darklajid 7y ago
  You don't use StackOverflow, ever?
  - pts_ 7y ago
    That's pretty much it.
- rafaelvasco 7y ago
  It will be. Just a matter of time. As things stabilize; Unity Engine will certainly use it moving on. They could already be using it. Not certain; It just doesn't make sense starting a new project with old .NET Framework from now on;
LandR 7y ago
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 7y ago
  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 7y ago
    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.
- moron4hire 7y ago
  .NET Standard 2 relaxed the versioning requirements that led to so many binding redirects.
- autechr3 7y ago
  .net core is definitely better than .net framework in regards to nuget issues in my experience.
- fstopmick 7y ago
  Same here. I've tried moving my "boilerplate side project" .NET Framework template over to the latest and greatest about once a year over the past four years and every time I hit the eight hour mark, I give up. Either my dependencies aren't supported yet, or there's some wonky versioning incompatibility, or there's some other undocumented frustration. I'm not dealing with anything wildly complex here ~ just an n-tier architecture supporting MVC rendered views, forms authentication, API endpoints, an EF middle-tier, and Azure SQL. About as simple as it gets for a web app. Has anyone here migrated from .NET framework > .NET core lately? Think it's time for me to give it another go?
merb 7y ago
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.)
- morrbo 7y ago
  I've extensively used itext with no issues on core
  - merb 7y ago
    itext is extremly overpriced. btw. you can't use the AGPL version in any closed source project.
    - e12e 7y ago
      This is one of those cases where distribution really matters; for quite a lot of the work we do, AGPL would probably be fine (to-order in-house business tools;client pays for development, gets source anyway). 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.
      - merb 7y ago
        I never said that I can't sell AGPL software. just that I can't use AGPL in a closed source project.
        e12e 7y ago
        I didn't mean to imply you did, just that this distinction is particularly important here, as I've seen quite a few "closed" projects that do need a pdf library, and would be fine with the AGPL.
samuell 7y ago
.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 7y ago
  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.
samuell 7y ago
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-programming-in-c 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.
- LordN00b 7y ago
  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.
privateSFacct 7y ago
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 7y ago
  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/743966/163-xaml-designer-not-showing-for-net-core-30-apps.html https://developercommunity.visualstudio.com/content/problem/...
  - privateSFacct 7y ago
    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 7y ago
      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.
jcmontx 7y ago
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.
- artimaeis 7y ago
  I believe they did port IQueryable: https://github.com/dotnet/corefx/blob/master/src/System.Linq.Expressions/src/System/Linq/IQueryable.cs https://github.com/dotnet/corefx/blob/master/src/System.Linq...
- oaiey 7y ago
  IQueryable is the base of LINQ. I think you are looking for a certain provider not for the interface.
thrower123 7y ago
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 7y ago
  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 7y ago
    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.
Rapzid 7y ago
It would be great if app domains or some other form of sandboxing came back? Perhaps with faster communication between domains..
- josteink 7y ago
  What other options do we have? Dedicated processes and some sort of (non-WCF) IPC?
- WorldMaker 7y ago
  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/Unloading https://github.com/dotnet/samples/tree/master/core/tutorials...
pknopf 7y ago
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 7y ago
  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.

k_ 7y ago

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?

jug 7y ago

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

donedealomg 7y ago
There are rumors that the WindowsNT kernel will be replaced in the future with a Linux Kernel with a Windows Desktop code on top of it. Can't wait for it. I know 2020 is going to be the year of the Linux Desktop... but....
mtgx 7y ago
Nadella has made it pretty clear, whether explicitly or implicitly, that Windows is a dead-end product for them. You could've also deduced this from how they selected their CEOs (cloud guy vs product/software guy or even a sales guy like Ballmer was). When you've already decided a product is a dead-end, you ignore it and don't spend as much in Q&A. You also try to squeeze your customers for all of their worth, even if that pisses them increasingly more, because you know the product has no future anyway so might as well maximize the revenue at all costs - which is also what Nadella has been doing with all the Windows 10 tracking.
pjmlp 7y ago
Windows userland is being rewritten in COM since Vista, as the Windows team picked up the Longhorn ideas and used them in COM after winning the WinDev vs DevTools politics, I doubt they will change route. 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.
- zaphirplane 7y ago
  Hey for people that don’t follow windows internals and politics closely, what did the devTools champion ? What are the longhorn ideas that are getting into windows ?
  - pjmlp 7y ago
    Long story short, that you kind have to assemble from blog posts, forum comments, between the lines articles and so on. 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-hilo-a-complete-c-windows-7-sample-application/ 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-generics-research-project-history-the-msr-white-paper-from-mid-1999/ 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.
gnud 7y ago
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.
- jug 7y ago
  Yes, if things keep changing around or is hard to find, that's annoying but I see this as a separate problem from a bad pace and inconsistency. Nothing here in particular hinders good and well researched design.
  - y4mi 7y ago
    I could find stuff in the old panel without knowing where it is. I can't in the new one. Either because the options are missing entirely or because they're too well hidden. 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.
- pantalaimon 7y ago
  Not to mention that the 'old' control panel has a lot more options!
- simonh 7y ago
  >It means I know where the switches are, and more importantly, what they do Or even more importantly than that, that they even exist in there somewhere.
  - AndrewDavis 7y ago
    My goodness. 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.
dvfjsdhgfv 7y ago
I can sum up the situation with two sentences: 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.
- platz 7y ago
  Core apps can be deployed standalone
- gameswithgo 7y ago
  With .NET Core 3, you can deploy them standalone, and performance is much improved. So you might have a happy middle ground available now. 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.
  - huzaif 7y ago
    Piggy backing on this a bit.. 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.
mumblemumble 7y ago
This oldie seems relevant: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c... 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.
- crazysim 7y ago
  ChromeOS? Is that a success? Lots of concessions there I guess though.
shawnz 7y ago
The old control panel can never be removed, because a significant amount of legacy software integrates itself into the old control panel and therefore wouldn't be usable if they removed it.
- teddyuk 7y ago
  They also contain decades of bodges and quick fixes to get stuff to just work - working out what they need to keep and throw away must be a nightmare.
  - cptskippy 7y ago
    Microsoft is gradually porting what's necessary out of the Control Panel in a controlled manner. Rather than offering 1:1 functionality to existing items in the Control Panel, they're examining and rethinking everything. The new Settings App is a cross platform legacy free future. 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.

donedealomg 7y ago

Microsoft acting to be a good open-source citizen. Did hell freeze over? Congratulations. I hope Blazor kills Javascript.

mjfisher 7y ago

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.

moksly 7y ago
> adoption of .NET core on standard line of business applications 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.
breakingcups 7y ago
We're using .NET Core for a few new projects. Our situation is a bit different as we build bespoke software for a wide range of clients. We're pretty satisfied with it.
pjmlp 7y ago

jeswin 7y ago

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.

denisw 7y ago
If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically. https://code.visualstudio.com/docs/languages/csharp https://code.visualstudio.com/docs/languages/csharp
- james_s_tayler 7y ago
  It's still nowhere near the same level of experience that Rider or VS offer.
  - rraghur 7y ago
    I use VSCode with C# extension. THe only thing I missed was the additional analysis and quick fixes that full VS provides. However, that got sorted out by installing Roslynator in VS Code (works on linux too) and I couldn't be happier.
  - wayneftw 7y ago
    Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time. 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.

mariusmg 7y ago

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

manigandham 7y ago
I find the opposite to be true. Many companies are moving to .NET Core, especially the independent dev shops. Cross-platform, easier to develop, faster and cheaper to run, and now supports desktop APIs.
EnderMB 7y ago
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.
- sebazzz 7y ago
  Many libs already support it. But the end-users, the web applications, are the problem. If you haven't properly separated business logic from UI, which might very well be the case if your project budgets aren't too high or other causes, you will have a rewrite on your hands instead of a port. A rewrite which is, especially on low budgets, not worth it.
- oaiey 7y ago
  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 ;).

Dolores12 7y ago

>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 7y ago
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?
- merb 7y ago
  especially since you need to enable the cookie container functionality manually and you can override it by yourself
  - Dolores12 7y ago
    or use different language with good library that support 8-year old RFC.
    - manigandham 7y ago
      C# is a language but .NET is a runtime and standard library. If this issue is really such a problem, you can use any of the dozens of open-source libraries available or just implement your own cookie container that follows this RFC in about a day. It sounds like you're picking on a strange issue to disparage .NET without any real experience in it.
      - Dolores12 7y ago
        No, i just didn't like the wording in the original post mentioning all 'modern workloads' , while ubiquitous thing like cookies in httpclient is still not according to 8 year old standard. Does it make any sense now?

asplake 7y ago

> ...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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.

deleted 7y ago

[deleted]

pts_ 7y ago

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

oblio 7y ago
What's a "rockstar project"? :-)
- rodgerd 7y ago
  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.
cyptus 7y ago
dot.net and bing.com are running under aspnet core 3.0
- pts_ 7y ago
  Um dogfooding doesn't count.
darklajid 7y ago
You don't use StackOverflow, ever?
- pts_ 7y ago
  That's pretty much it.
rafaelvasco 7y ago
It will be. Just a matter of time. As things stabilize; Unity Engine will certainly use it moving on. They could already be using it. Not certain; It just doesn't make sense starting a new project with old .NET Framework from now on;

LandR 7y ago

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 7y ago
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 7y ago
  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.
moron4hire 7y ago
.NET Standard 2 relaxed the versioning requirements that led to so many binding redirects.
autechr3 7y ago
.net core is definitely better than .net framework in regards to nuget issues in my experience.
fstopmick 7y ago
Same here. I've tried moving my "boilerplate side project" .NET Framework template over to the latest and greatest about once a year over the past four years and every time I hit the eight hour mark, I give up. Either my dependencies aren't supported yet, or there's some wonky versioning incompatibility, or there's some other undocumented frustration. I'm not dealing with anything wildly complex here ~ just an n-tier architecture supporting MVC rendered views, forms authentication, API endpoints, an EF middle-tier, and Azure SQL. About as simple as it gets for a web app. Has anyone here migrated from .NET framework > .NET core lately? Think it's time for me to give it another go?

merb 7y ago

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

morrbo 7y ago
I've extensively used itext with no issues on core
- merb 7y ago
  itext is extremly overpriced. btw. you can't use the AGPL version in any closed source project.
  - e12e 7y ago
    This is one of those cases where distribution really matters; for quite a lot of the work we do, AGPL would probably be fine (to-order in-house business tools;client pays for development, gets source anyway). 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.
    - merb 7y ago
      I never said that I can't sell AGPL software. just that I can't use AGPL in a closed source project.
      - e12e 7y ago
        I didn't mean to imply you did, just that this distinction is particularly important here, as I've seen quite a few "closed" projects that do need a pdf library, and would be fine with the AGPL.

samuell 7y ago

.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 7y ago
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.

samuell 7y ago

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-programming-in-c 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.

LordN00b 7y ago
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.

privateSFacct 7y ago

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

jcmontx 7y ago

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.

artimaeis 7y ago
I believe they did port IQueryable: https://github.com/dotnet/corefx/blob/master/src/System.Linq.Expressions/src/System/Linq/IQueryable.cs https://github.com/dotnet/corefx/blob/master/src/System.Linq...
oaiey 7y ago
IQueryable is the base of LINQ. I think you are looking for a certain provider not for the interface.

thrower123 7y ago

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 7y ago
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 7y ago
  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.

Rapzid 7y ago

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

josteink 7y ago
What other options do we have? Dedicated processes and some sort of (non-WCF) IPC?
WorldMaker 7y ago
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/Unloading https://github.com/dotnet/samples/tree/master/core/tutorials...

pknopf 7y ago

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 7y ago
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.