Supporting the community with WF and WCF OSS projects

Scott Hunter [MSFT]


At the Build conference in May 2019, we mentioned that, after we add WinForms, WPF and Entity Framework 6 to .NET Core 3.0, we do not plan to add any more of the technologies from .NET Framework to .NET Core.

This means we will not be adding ASP.NET Web Forms, WCF, Windows Workflow, .NET Remoting and/or the various other smaller APIs to .NET Core. For new applications, there are better technologies that serve a similar purpose and provide more capabilities or better experiences. We think of .NET Core as the framework our customers will build brand new applications or port applications that they are still spending lots of engineering work on.

ASP.NET Blazor – provides a similar component and event-based programming model as ASP.NET Web Forms but generating a SPA (Single Page Application) instead of a traditional web site.

ASP.NET Web API or gRPC – provide APIs and contract-based RPCs that can be used across all devices and platforms.

.NET Core WCF Client – provides the ability for .NET Core projects to call into the existing WCF Servers that run on .NET Framework.

What do you do with your older applications that you are not spending much engineering time on? We recommend leaving these on .NET Framework. If you’re not spending much time on those projects and they meet your business needs, then you should just leave them where they are. You can even modernize those existing applications to Windows containers if you want to run them in containers.

.NET Framework will continue to be supported and will receive minor updates. Even here at Microsoft, many large products will remain on .NET Framework. There are absolutely no changes to support and that will not change in the future. .NET Framework 4.8 is the latest version of .NET Framework and will continue to be distributed with future releases of Windows. If it is installed on a supported version of Windows, .NET Framework 4.8 will continue to be supported too.

If you really want to move one of your older applications to .NET Core and don’t want to migrate it to newer technologies like Web API / gPRC / Cloud based workflow, we are supporting two community efforts that provide ports of Windows Workflow and WCF to .NET Core.

Core WCF

Core WCF is a new community owned project under the .NET Foundation. Microsoft has made an initial contribution of code from a WCF team member to help get the project started. Core WCF is not intending to be a 100% compatible port of WCF to .NET Core, but aims to allow porting of many WCF contract and service implementations with only a change of namespace.

Initially, it will be for HTTP and TCP SOAP services on-top of Kestrel, which are the most commonly used transports on .NET Framework.

This project is not yet ready for production but needs people to get involved and help get it there faster. If you are interested in this, or want more details about the project, then we encourage you to go and explore the Core WCF project on GitHub.

This project has joined the .NET Foundation and you can read about it on the .NET Foundation blog.

Core Workflow

Core WF is a port of Workflow for .NET Core sponsored by UIPath. The project was started by a former Workflow team member and the .NET team has been working to make sure that all the source code they need to do the work of porting Workflow is available to them. This project will need more community help to become a replacement for Workflow on .NET Framework and we encourage anyone who wishes to see Workflow on Core to get involved and see if you can help out.


We’re happy to see these projects be part of the .NET OSS community and hope that you’ll join us in supporting them and other .NET OSS. If you want more information about the .NET Foundation or what you can do to get involved then be sure to checkout the .NET Foundation website.


Comments are closed. Login to edit/delete your existing comments

  • Joseph Rufft
    Joseph Rufft

    ASP.Net Web Forms are a must in .Net Core or .Net 5.  Blazor an unreleased experimental framework sounds like a risky choice and a possible waste of time, money and could be self damaging to ones reputation if it doesn’t stick around.  Web Forms are mature, solve problems and work great for intranet apps.  University’s might be behind on recent trends, but they still teach ASP.Net Web Forms in their curriculum.  For Microsoft to not port Web Forms to .Net Core or .Net 5 shows a major disconcern for developers and companies that have spent millions developing on the Microsoft stack.  This is flat out bad business decision making and errodes customer loyalty!

    • Avatar
      Llewellyn Roos

      If you go to a university that still teaches Web Forms as part of a web development curriculum then you kinda deserve to not find a job and have all your children go hungry. ASP.NET MVC was released in 2009; that’s not a recent trend.

    • Avatar
      Ion Robu

      Microsoft announced 5 years ago that WebForms will be decomissioned. So, your university teaches outdated technologies.
      I also have WebForms apps, and I have to manage further, rewriting is not an option. But we have to accept the things are moving on, and we should do the same.

  • Avatar
    Antonio Di Dia

    Excluding Web Forms from .Net Core would be a serious error.

  • Avatar
    gaatje helemaalnietsaan

    Quoted question : “What do you do with your older applications that you are not spending much engineering time on?”
    Answer: we have an older application we are spending a LOT of engineering on. We only recently ported it from .net remoting to WCF. And now there is C# 8.0 with some very welcome enhancements such as default interface implementations. But it is only supported in .NET core! So we started porting our application to .NET core. First step: convert your projects to the new SDK format. This proved doable, but a terrible nuisance. The try-convert app does try, but to name one example, it adds net742 to the name of the output folder. You have to manually edit the XML to correct this. Post and pre build events don’t work as expected. This also has to be corrected by editing the XML manually. For a product like Visual Studio, I expected something like this to be fully automatic. One menuitem in the top-level which converts all projects in the solution to this new format, and the generated output exactly as it was before.
    Next step: set the target for all projects to .net core. Add the Windows extensions and rebuild… Ok, some changes are to be expected. BUT WCF server is NOT supported! WCF over namedpipes is not supported!
    So we can’t use these nice new C# 8.0 features, at least until WCF server is supported. MS should not have released this until all things are in place.
    This is starting to feel a lot like the introduction of .NET 1.0 and the demise of COM, and in particular VB6. For me as a C++ programmer this was not such a problem, but for a lot of programmers using VB6 it was a disaster.