.NET Core 3 for Windows Desktop

Olia Gavrysh

Olia

Intro

In September, we released .NET Core support for building Windows desktop applications, including WPF and Windows Forms. Since then, we have been delighted to see so many developers share their stories of migrating desktop applications (and controls libraries) to .NET Core. We constantly hear stories of .NET Windows desktop developers powering their business with WPF and Windows Forms, especially in scenarios where the desktop shines, including:

  • UI-dense forms over data (FOD) applications
  • Responsive low-latency UI
  • Applications that need to run offline/disconnected
  • Applications with dependencies on custom device drivers

This is just the beginning for Windows application development on .NET Core. Read on to learn more about the benefits of .NET Core for building Windows applications.

Why Windows desktop on .NET Core?

.NET Core (and in the future .NET 5 that is built on top of .NET Core) will be the future of .NET. We are committed to support .NET Framework for years to come, however it will not be receiving any new features, those will only be added to .NET Core (and eventually .NET 5). To improve Windows desktop stacks and enable .NET desktop developers to benefit from all the updates of the future, we brought Windows Forms and WPF to .NET Core. They will still remain Windows-only technologies because there are tightly coupled dependencies to Windows APIs. But .NET Core, besides being cross-platform, has many other features that can enhance desktop applications.

First of all, all the runtime improvements and language features will be added only to .NET Core and in the future to .NET 5. A good example here is C# 8 that became available in .NET Core 3.0. Besides, the .NET Core versions of Windows Forms and WPF will become a part of the .NET 5 platform. So, by porting your application to .NET Core today you are preparing them for .NET 5.

Also, .NET Core brings deployment flexibility for your applications with new options that are not available in .NET Framework, such as:

  • Side-by-side deployment. Now you can have multiple .NET Core versions on the same machine and can choose which version each of your apps should target.
  • Self-contained deployment. You can deploy the .NET Core platform with your applications and become completely independent of your end users environment – your app has everything it needs to run on any Windows machine.
  • Smaller app sizes. In .NET Core 3 we introduced a new feature called linker (also sometimes referred to as trimmer), that will analyze your code and include in your self-contained deployment only those assemblies from .NET Core that are needed for your application. That way all platform parts that are not used for your case will be trimmed out.
  • Single .exe files. You can package your app and the .NET Core platform all in one .exe file.
  • Improved runtime performance. .NET Core has many performance optimizations compared to .NET Framework. When you think about the history of .NET Core, built initially for web and server workloads, it helps to understand if your application may see noticeable benefits from the runtime optimizations. Specifically, desktop applications with heavy dependencies on File I/O, networking, and database operations will likely see improvements to performance for those scenarios. Some areas where you may not notice much change are in UI rendering performance or application startup performance.

By setting the properties <PublishSingleFile>, <RuntimeIdentifier> and <PublishTrimmed> in the publishing profile you’ll be able to deploy a trimmed self-contained application as a single .exe file as it is shown in the example below.

<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

Differences between .NET Framework desktop and .NET Core desktop

While developing desktop applications, you won’t notice much difference between .NET Framework and .NET Core versions of WPF and Windows Forms. A part of our effort was to provide a functional parity between these platforms in the desktop area and enhance the .NET Core experience in the future. WPF applications are fully supported on .NET Core and ready for you to use, while we are working on minor updates and improvements. For Windows Forms the runtime part is fully ported to .NET Core and the team is working on the Windows Forms Designer. We are planning to get it ready by the fourth quarter of 2020 and for now you can check out the Preview version of the designer in Visual Studio 16.4 Preview 3 or later. Don’t forget to set the checkbox in the Tools->Options->Preview Features->Use the Preview of Windows Forms designer for .NET Core apps and restart the Visual Studio. Please keep in mind that the experience is limited for now since the work on it is in progress.

Breaking changes

There are a few breaking changes between .NET Framework and .NET Core but most of the code related to Windows Forms and WPF areas was ported to Core as-is. If you were using such components as WCF Client, Code Access Security, App Domains, Interop and Remoting, you will need to refactor your code if you want to switch to .NET Core.

Another thing to keep in mind – the default output paths on .NET Core is different from on .NET Framework, so if you have some assumptions in your code about file/folder structure of the running app then it’ll probably fail at runtime.

Also, there are changes in how you configure the .NET features. .NET Core instead of machine.config file uses <something>.runtimeconfig.json file that comes with an application and has the same general purpose and similar information. Some configurations such as system.diagnostics, system.net, or system.servicemodel are not supported, so an app config file will fail to load if it contains any of these sections. This change affects System.Diagnostics tracing and WCF client scenarios which were commonly configured using XML configuration previously. In .NET Core you’ll need to configure them in code instead. To change behaviors without recompiling, consider setting up tracing and WCF types using values loaded from a Microsoft.Extensions.Configuration source or from appSettings.

You can find more information on differences between .NET Core and .NET Framework in the documentation.

Getting Started

Check out these short video tutorials:

Porting from .NET Framework to .NET Core

First of all, run the Portability Analyzer and if needed, update your code to get a 100% compatibility with .NET Core. Here are instructions on using the Portability Analyzer. We recommend to use a source control or to backup your code before you make any changes to your application in case the refactoring would not go the way you want, and you decide to go back to your initial state.

When your application is fully compatible with .NET Core, you are ready to port it. As a starting point, you can try out a tool we created to help automate converting your .NET Framework project(s) to .NET Core – try-convert.

It’s important to remember that this tool is just a starting point in your journey to .NET Core. It is also not a supported Microsoft product. Although it can help you with some of the mechanical aspects of migration, it will not handle all scenarios or project types. If your solution has projects that the tool rejects or fails to convert, you’ll have to port by hand. No worries, we have plenty of tutorials on how to do it (in the end of this section).

The try-convert tool will attempt to migrate your old-style project files to the new SDK-style and retarget applicable projects to .NET Core. For your libraries we leave it up to you to make a call regarding the platform: weather you’d like to target .NET Core or .NET Standard. You can specify it in your project file by updating the value for <TargetFramework>. Libraries without .NET Core-specific dependencies like WPF or Windows Forms may benefit from targeting .NET Standard:

<TargetFramework>netstandard2.1</TargetFramework>

so that they can be used by callers targeting many different .NET Platforms. On the other hand, if a library uses a feature that requires .NET Core (like Windows desktop UI APIs), it’s fine for the library to target .NET Core:

<TargetFramework>netcoreapp3.0</TargetFramework>

try-convert is a global tool that you can install on your machine, then you can call from CLI:

C:\> try-convert -p <path to your project>

or

C:\> try-convert -w <path to your solution>

As previously mentioned, if the try-convert tool did not work for you, here are materials on how to port your application by hand.

Videos

Documentation

Olia Gavrysh
Olia Gavrysh

Program Manager, .NET

Follow Olia   

87 comments

  • Avatar
    Ian Marteens

    “We are planning to get it ready by the fourth quarter of 2020…”

    … wait. Are you telling us you need another year for completing the WinForms designer? Wow!

  • Avatar
    Dominic Shaw

    This is great, thank you.

    What are the plans in regard to deployment? We currently rely heavily on ClickOnce. MSIL is more difficult to use than ClickOnce publish and I can’t find any notes anywhere on CD pipelines for MSIL. Is there anything you can point me at? We are just publishing LOB applications so it is all internal, no need for the Store or anything like that.

    • Avatar
      Daniel Jacobson

      You have several options for deployment. You can use the Windows Application Packaging Project to create an MSIX package which supports many of the features that ClickOnce has on recent versions of Windows 10: https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-packaging-dot-net.

      An example of this project with an end-to-end .NET Core WPF application using CI/CD is available here: https://github.com/microsoft/devops-for-windows-apps

      You can use Installer Projects to create a .NET Core MSI. You can make everything fully self contained within the .exe and distribute that way. You can also look at other third party options for packaging and distributing applications.

      None of the above require you to upload to the Store, but MSIX packaging is the one that will allow you to upload to the Store if you ever do build applications that would make sense there.

      We’d be happy to chat more about your application deployment requirements and see if we can help. If you’re interested, please contact me at dajaco at microsoft dot com.

    • Avatar
      Jiří Urban

      I believe MSIX packages is the succesor of MSIL or ClickOnce and they support windows 7 (for some reason) as well. Check the docs

      • Avatar
        Dominic Shaw

        Apologies that is exactly what I meant – but I don’t see any resources for that with CD either. I don’t see any way to deploy that automatically with, for instance, DevOps?

  • Avatar
    Jack Bond

    “They will still remain Windows-only technologies because there are tightly coupled dependencies to Windows APIs.”

    For the love of ******* god, stop running surveys, actually listen to your customers, and DECOUPLE THEM.

    Seriously, whoever is making some of these decisions should have been fired ages ago. Imagine a Microsoft store for MacOS and a couple Linux distros, where you could distribute your cross platform XAML / .NETCORE app. I’d gladly give up 50 cents on the dollar.

    • Avatar
      Fabien Geraud

      There is xamarin, avalonia, uno, blazor, the winform like cross plate-form project I can’t remember the name, and many small project using wasm&electron or more low level. There is already a lot of solution to do what you ask. What the ecosystem will gain to do that exept trying to simplify porting application (I’m not even sure if it will be easier)

    • Daniel Neely
      Daniel Neely

      Winforms is a thin wrapper around native win32 controls. Porting it to mac/linux would be equivalent to writing a win32 implementation for those OSes. If you want to do that just run the exe with WINE.

      • Avatar
        Jack Bond

        Notice I said XAML. Microsoft already made XAML cross platform(remember Silverlight.) It’s complete ******* ******** that WPF is any more tightly coupled to Windows than the full .NET framework was. Someone has made a decision that allowing WPF to run on MacOS and Linux would be detrimental to Windows, so why spend the money? Just look at Azure, when given the choice, A LOT of people pick Linux. Heck, given the absurd licensing costs built into Windows VMs, if deploying Service Fabric apps to Linux was as simple as selecting from a drop down in a build pipeline, the Windows usage would probably crater even further.

        • Avatar
          Constantine Zachariadis

          XAML was built to make HEAVY UIs and makes use of DirectX/Direct3D for most of its drawing capabilities. I would venture to say that is the heavy coupling. Personally, I never warmed up to WPF as it was always slower than WinForms.

          • Avatar
            Jack Bond

            And yet they somehow got Silverlight to work.

            This is NOT a technical problem.
            This is NOT a financial problem.

            This is a stupidity problem.

    • John McCourt
      John McCourt

      That’s a lot of work, with a big financial outlay which may not pay for itself in the short term. As a Linux developer I’m quite happy with the direction that Microsoft is taking. It has to be a gradual process though, and I don’t expect everything to happen overnight. A bit of patience is necessary. Expecting everything right now is a little bit ‘entitled’.

  • Avatar
    Zoltan Puski

    Interop and Remoting, you will need to refactor your code if you want to switch to .NET Core.

    Interop – you mean COM Interop?

    • Avatar
      Kathleen Dollard

      We have brought most of the Visual Basic Runtime (Microsoft.visualbasic.dll) to .NET Core. We have not yet released templates for Visual Basic because at present we don’t have an adequate Visual Basic experience.

      • Avatar
        SuperCocoLoco .

        But not brought for ASP.Net Core. All my VB.Net libraries are shared between WPF desktop applications and ASP.Net web applications.

  • Avatar
    kuo liu

    “They will still remain Windows-only technologies because there are tightly coupled dependencies to Windows APIs. “, Does “They” mean .NET Core? If that, .Net Core winform couldn’t be cross platform.

    • Avatar
      Kathleen Dollard

      Visual Basic is not dead. We have brought most of the Visual Basic Runtime (Microsoft.visualbasic.dll) to .NET Core. We have not yet released templates for Visual Basic because we are not yet confident in our ability to provide an adequate Visual Basic experience.

      • Avatar
        jaroslavmitrovic@hotmail.com

        Hi.

        I would like to suggest to use the help of the “Windows Template Studio” Team.
        Especially Sybille, who was the nice Person, which contributed alot of VB Support into the Project.

        Maybe the other Team from “Template 10” could help, but I think there Focus is more on C#,
        but I think they could Jump in…

        I have a Video link of a fellow Forum member, how a C# Project is converted manually to VB .NET Core 3.

        But it is in german Language.

        If it is of interest I could put a link on a Reply.
        I don´t know if it is allowed to add a Weblink to a Video Portal Webpage in here.

        Sorry for my bad english and my typos, but you can keep them, it´s free… 🙂
        c.u. and Greetings from Germany

          • Olia Gavrysh
            Olia Gavrysh

            Also (will add from myself) – no need to apologize for “my bad English and my typos”. It is admirable you speak another language, besides your native, and express yourself so well. I am extremely thankful for everyone who gives constructive feedback, and the fact you do it in foreign language deserves a double thank you! 🙂

          • Avatar
            jaroslavmitrovic@hotmail.com

            Thank You dear Mrs. Gavrysh for these kind Words.

            On avarage I speak 4.45532 Languages (Of HumanLanguages) , if You combine all of them. 😉

            I am looking forward, to hear from Mrs. Dollard.

            Have a nice Day.

      • Avatar
        David Streeter

        Microsoft have abandoned the ‘co-evolution’ strategy where VB was previously the equal of C#. We’re back to the bad old days of features being added to C# first, and then maybe if we are lucky VB catches up sometime down the track: https://devblogs.microsoft.com/dotnet/the-net-language-strategy/

        I have been a BASIC programmer since QuickBasic days and I strongly recommend you switch to C# (and TypeScript). Microsoft are struggling to keep .NET/C# relevant, let alone VB.

        The self-taught programmer path is Excel VBA -> VB.NET but then the road runs out. Microsoft should ensure the path keeps going by making it easier to transition to C# and JS/TS.

        One idea would be to add an ‘autocorrect’ feature to the C# IDE, so you type in VB code and it autocorrects to C#.

        The only major VB feature missing from C# is REDIM PRESERVE, which would be a good addition to C#.

        Also missing from C# are static variables inside a method (intentionally missing feature) and ‘With Object’ property access, but they are easy to do without.

    • John McCourt
      John McCourt

      It doesn’t really make much sense for Microsoft to develop both C# and VB. They should select one (preferably c#) and stick with it.

  • Avatar
    Will Woo

    “In September, we released .NET Core support for building Windows desktop applications, including WPF and Windows Forms.”

    I would call what was released in September the equivalent of a movie preview where an initial white screen was followed by random images punctuated by static: as in “completely unusable.”

    “Since then, we have been delighted to see so many developers share their stories of migrating desktop applications (and controls libraries) to .NET Core. We constantly hear stories of .NET Windows desktop developers powering their business with WPF and Windows Forms, especially in scenarios where the desktop shines, including”

    uhhh … where is one example of such a story for a Windows Form app with a rich GUI ?

    “For Windows Forms the runtime part is fully ported to .NET Core and the team is working on the Windows Forms Designer. We are planning to get it ready by the fourth quarter of 2020”

    In other words, Win Form devs, with a substantial investment in apps making use of existing MS and 3rd. party controls (which often use the Win API) are pretty much thrown under the bus (again … the previous bus being WPF, and the so-called “Modern” UI).

    Would I like to write (no-UI) libraries using Core 3 that exploited the latest C# features ? Oh, yes ! But, I have no way, evidently, to use those libraries with a Win Form app that uses today’s GUI controls: “game over.”

    In “programmer time,” 4th. quarter 2020 might as well be “never.”

    Bill Woodruff
    CodeProject Mentor
    CodeProject MVP, 2015, 2017, 2019

    • Avatar
      Jan Nedoma

      Exactly. I would like to know what the “user story” is, users who want to convert their WinForms apps to Core and never touch the UI again?
      Waiting a whole year for the designer is deeply disappointing.

    • Avatar
      Ian Marteens

      All this reminds me of Wolfgang Pauli drawing an empty square in a note, with the text: “this is to show the world I can paint like Titian. Only technical details are missing.”

    • Avatar
      Hall, Trevor

      Will: Agreed!

      Our team, which is part of a (massive) company (>50,000 employees) put “some money and effort” into porting our Windows desktop tools to .Net core 3.x this year, having believed that this would be delivered with full WinForms and WPF support by end of 2019.

      50% of our “test harness” code for many algorithms is “WinForms”, so:
      When this was not useable at core 3.0, we deferred the project (ignored it for 2 months) to wait for 3.1.
      We are now putting it on ice for another 9 months.

      This means: we have to do “9 months of merging” from the Framework code that we need to keep maintaining, when this comes back on-line with .Net 5.
      We are unlikely to use .Net core 3.0 or 3.1 in any of our Windows projects shipping in 2020. Since .NET 5 is not until near the end of 2020, and we need months to validate projects on new frameworks, our move to “core” won’t appear in shipping projects until well into 2021.

      This doesn’t match the rapid adoption pace as suggested in the article, at least for all teams that I work with.

      On cross platform:
      We gave up hope on anyone delivering this to us, so we rolled our own.
      We have “device independent” layers for our custom controls that render in WPF, HTML5, SVG, EMF and Bitmap.
      We can get the same presentation on Windows as on an android tablet for many items.
      There is no obvious reason why that cannot be done for WPF as a whole (if it is open source) as the “input data” is XAML, which (like HTML), does not seem connected in any way that I can see to a specific implementation for “Windows”.
      WinForms is possibly a bit more tricky to isolate as it is described more like a “win32 wrapper”, but nothing is “impossible”

      There are are questions on “why you would want multiple formats of apps”. Just run a survey: Some people “want apps and data on their Windows laptop”. Some “only accept cloud data and tablets” Etc. Some prefer these different technologies based on workflows, so: We absolutely need tools that work on many platforms, including UI.

      • Avatar
        Merrie McGaw

        Hi Trevor,

        As you know, the WinForms runtime is fully functional, and we’re seeing very positive feedback for how it’s working. I’d love to know more about your scenarios with the test harnesses, because the WinForms .NET Core Designer already supports the main common controls, and we’re working hard to bring you container controls to help with layout of your forms in the next preview. So if your test harnesses are not using terribly complex UI or third party controls you may find that the support is sufficient for your needs.

        We’re working hard to get new features available with every VS preview that ships. Data binding, User Controls and support for third party controls are our long lead items at the moment but they’ll be coming as soon as we can get them done. If you aren’t using those features however, your company may not need to put the project on ice for a long time. And if you are using those features, I’d love to know which ones and how you’re using them in your test environment.

        Thanks,
        ~Merrie McGaw
        Principal Dev Lead for WinForms

        • Avatar
          Will Woo

          “the WinForms .NET Core Designer already supports the main common controls”

          Are you kidding: even using the latest VS 2019 Preview update, with a Core 3 WinForm project, the simplest WinForm ToolBox controls don’t work, or behave bizarrely. See mention of 4k screen below.

          The controls you drop on the Form … once you’ve manually edited Location to get them to show up on the Form … do not write their edited properties into the Designer.cs file; they’re not saved with the file.

          At design-time, controls, including Forms are not movable or click-drag resizable.

          On a 4k Dell laptop screen, settings of AutoScaleMode make no difference, and the design-time view is rendered at about 25% of the run-time view.

          These iterations are not usable: they should not be released as previews.

          I’ve already uninstalled the latest VS 2019 preview, and have no intention of paying attention to further developments with WinForm Core until next year … unless you want to hire me as a tester 🙂

          • Avatar
            Merrie McGaw

            High DPI has always been a very tricky topic in the WinForms world and I’m sorry you’re running into these issues. Our testing hasn’t indicated anything of what you’re discussing, unless you’re working on a secondary monitor or a HDPI situation. I’d really love to see the logs of what’s happening on your system, because at this stage we haven’t been seeing things like not writing edited properties into the designer.cs file. That’s a key part of what we’ve been working to make happen for these early releases. If you’re willing, it would be super helpful to us (and to the WinForms on .NET Core community) to create a VS Feedback item when it’s happening so we can collect logs and understand what exactly is getting in the way of the basic scenario of dropping and editing a control.

            As for the HDPI related stuff, we are having to tackle that a little later so that we can get base functionality working first. But if we hear enough reports that this is blocking work then we may be able to prioritize it over some other scenarios.

            Thank you for the feedback and for trying out the designer!

        • Avatar
          Hall, Trevor

          Merrie,

          Thanks for your reply. Maybe you have some “much better” internal versions?

          Unfortunately, There is no “Paste image” in the forum.
          If there was, I think you would get a laugh out of it.

          I have a simple library with 2 forms.

          One of them is basically a pile of buttons arranged in the shape of the periodic table, with element names on it.
          There is not much more. A simple data grid, which shows the known isotopes when you click on a button, and a couple of numeric “up/down” text boxes. One of those boxes has the default value “10”.

          The box takes up maybe 6 inches wide by 5 high on a laptop.

          With .NET 4.7.1: I see a periodic table.
          With core 3.1: and all latest previews: I see a square, about 1 inch by 1 inch, with several red Xs, and the number 10.

          Most of my forms are like this.

          Some may use “Data Binding”. We have many custom items, that are probably user controls and not supported yet.

          We organize items with Group Boxes (doesn’t everyone)?
          Group box is not supported.

          So: out of maybe 50 forms, I have not yet found 1 that renders correctly in the designer.

          Obviously, I cannot offer code libraries like this for other teams to consume.

          There is (sadly) currently, no compelling reason to move any of our desktop software to .NET core.
          Our team has determined that this is “not ready for prime time”.

          I know people are “working hard”. The problem is:
          You can’t live in a house if the roof is not installed yet, despite all efforts in progress by the “roofers”.

          Thanks
          Trevor

    • Avatar
      Merrie McGaw

      We totally understand the frustration with not having a fully functional designer right away. It’s just as frustrating for us – we want you all to have it and be working daily in WinForms on .NET Core (WPF/XAML designer is already fully working, their designer was architected in such a way that adding support for .NET Core was relatively straight forward).

      WinForms Designer was one of the original main components of Visual Studio back in 2000/2001. Our Classic Designer was architected before many of the current coding standards and best practices were created. In fact, I’d say the majority of the code we’re working with is 15-20 years old! We’re essentially having to crack open Visual Studio and insert a new window layer in it’s own new process that displays the .NET Core Form as you would see it at runtime. Then we have to create a way for the Core process to communicate with Visual Studio and vice versa. That is for ever single action the designer could perform (resize, change property, change locatiOn, etc). It turns out this is no small feat and every time we start working in a new area of the designer there are new and interesting challenges to get it to light up.

      In the meantime, the Core Designer that we’re previewing is functional for certain scenarios and the runtime is fully functional. Migrating existing code can be started now and we will continue to add functionality in every VS release. As @Olia mentioned we’re looking to have a stable and nearly complete release in the 2nd quarter of 2020, spending the summer and early fall polishing up . We are working closely with the various control vendors to ensure they’re prepared to support their control libraries as they’ll have to do some of the same rearchitecting we do.

      We’d love as many people to kick the tires on this early Preview and tell us how it’s going. When you encounter something that doesn’t work as it should, we’re asking folks to file VS Feedback so we know what things we need to focus on for each preview we ship. We’d also love to know what pieces of the Designer experience our customers are missing most so we prioritize those scenarios.

      We thank you all for your patience, and are super excited by the energy the community is showing around WinForms and the WinForms designer!

      ~Merrie McGaw
      Principal Dev Lead for WinForms

      • Avatar
        Jan Nedoma

        “When you encounter something that doesn’t work as it should” – how do we know what should work? Is there any list of supported/unsupported features? Know issues? Changed/added features for each release?
        I checked the initial (standalone) release and it didn’t even load my forms, because apparently it doesn’t support inherited classes at all. Is that intended? How should I know?
        Also, why is the preview tied to VS Preview now? Why not update the standalone release? I’m not sure I’m willing to install (and maintain) another instance of VS just to test the designer early, early, early preview.

        • Olia Gavrysh
          Olia Gavrysh

          yes, here is the Known Issues and the
          Release Notes for the Designer Preview 1 and we will publish the blogpost for the Preview 2 very shortly (after all the Ignite announcements).

          As for shipping with VS Preview – we received many asks from the users to be in-box so that they don’t have to do extra work of finding, installing and updating the designer separately. The goal is to have the same designer experience as it was for .NET Framework applications. I personally prefer to have 2 VSs on my box, because with the VS Preview I get the latest updates on all the components that are in preview including .NET Core, etc. That way I get the latest goodness of everything :).

          We really appreciate everyone who is testing the designer and leaving the feedback via VS feedback channel, it helps us a lot to find bugs and prioritize our work. I’m sorry the experience is not great for some of you, we, more than anyone, want to get the designer to the stable mature state as fast as possible, and the community has been a great help! Thank you!

          • Avatar
            Jan Nedoma

            Thank you. If I were to vote, please prioritize support for inherited forms and user controls. Without that the designer is pretty much unusable for me (and I imagine for a large percentage of real-world projects).

      • Avatar
        Will Woo

        “the Core Designer that we’re previewing is functional for certain scenarios”

        I believe you are well-intentioned, and, indeed, working hard on a difficult task; however, I must reply to a claim like this as I have replied to Olia’s claims:

        “we have been delighted to see so many developers share their stories of migrating desktop applications (and controls libraries) to .NET Core. We constantly hear stories of .NET Windows desktop developers powering their business with WPF and Windows Forms, especially in scenarios where the desktop shines”

        on this thread: show me a working example.

        I suggest you get together with management-whoever, and make a decision to stop the release of previews that are so dysfunctional they are a waste of developers’ time.

        Right now, I have to regard the claims made about these updates as “propaganda.”

        cheers, Bill

  • Avatar
    TAE-IN KIM

    I had to leave a comment on this article since I want any of MS developers in charge of this framework could see those opinions.
    What is the very irreplaceable values of this .NET Core? Why MS made this .Net Core with spending their resources?
    Sorry if I’m wrong, but I think it’s to make framework which can be used regardless of operating system.
    For example, will developers who makes GUI program based on WinForms or WPF use .Net Core? I don’t think so. There’s no reason for them to leave .NET Framework to use this “new” “Core” something. There’s already “mature framework” to use WinForm, WPF, UWP on Windows.
    Yes I’ve seen a number of reason why .NET Core team is not going to implement WinForm and WPF for non-Windows out of DirectX, WinAPI issue. But then “they shouldn’t” implement those GUI framework on .NET Core because those reason directly comes to conflict with why .NET Core exists.

    Everyone regards .NET Core as cross-platform framework based on C#. If it isn’t, there’s no benefit to use this “newborn” environment and it’s huge loss of Man/Month for MS and open source community. So it would be nice of MS development team to reconsider this issue with care.
    Thank you.

    • Avatar
      Fabien Geraud

      You already can make gui application regardless of the os. What bringing wpf will bring except spending Money and divide the community.
      One of the goal off. Net core was to unify the community. So making wpf or winform cross plate-form is against the idea of dotnet core. But one thinks important is dotnet core was made in the beginning for asp. Net…

    • Olia Gavrysh
      Olia Gavrysh

      Thank you for the comment! You are right if you think of .NET Core as just a cross-platform alternative for .NET Framework. And that was true in the past but our vision of .NET Core has changed. Now .NET Core is the platform that will move forward unlike .NET Framework that will stay where it is (with version 4.8). So if we did not bring desktop stacks to .NET Core, desktop developers would never be able to use anything new that will come in the language, runtime and so on. That is including C#8 and further, performance improvements, deployment flexibility, etc.

      Besides desktop is available as a separate workload that you install only if you need it, there are no reasons to worry about desktop making .NET Core “heavier” for non-desktop applications.

  • Avatar
    Illenseer, Kirill

    What I still don’t understand though is why exactly Windows Forms can’t work cross-platform. I understand in theory that it’s very close to the way Windows manages forms, but I understand in practice that I have a couple Raspberry Pis in my household displaying .NET Windows Forms running on Mono.

    • Avatar
      Wayne Sebbens

      Mono did the work to build up a framework that can render the WinForms components on whatever window manager/display server Linux is using on your Pis. For WinForms/WPF to be cross-platform beyond Windows, Microsoft would need to create (and support) a similar framework for each window manager on Linux (or at least the most popular ones) and MacOS.

      And possibly Android and iOS. Which brings me to Xamarin already existing and serving part of this need, and other community projects (shoutout to Avalonia, which is a bit more WPF-like than Xamarin). Why put in the huuge amounts of time and effort to build WinForms/WPF from scratch for those other platforms when there are already good, stable, and in-use equivalents that can be fostered instead?

  • Avatar
    Will Woo

    Don’t waste your time trying to use these releases:

    installed VS 2019 preview 16.4.29430.225

    install does not create a desktop shortcut: the exe is hidden away in “C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\devenv.exe”

    created a new WinForm App using Core 3

    enabled the option in VS to use Core Preview WF designer: required restart.

    re-started VS 2019 preview

    15 minutes later, VS 2019 preview is still loading, Task Manager is showing a
    ServiceHub.ThreadedWaitDialog process eating a lot of cycles.

    • Avatar
      Shyam Gupta

      We are sorry that you ran into this problem. We are working on Perf issues that we are aware of and we have several fixes going in for next release.

      It will be really helpful, if you could report this problem using Visual Studio Feedback with more details so that appropriate team can look into this issue.

      Thank you.

  • Avatar
    Carlos Osuna

    Maybe it’s just me, but all your renaming juggling act is just a mess of confusion.

    I’m working for a company that uses .NET on the server and another which uses it on the client and with the transition to .NET 5 they are scared shtless. We are telling them that is a simple matter of switching to .NET Standard and that both .NET Core 3 and .NET Framework 4. adhere to it, but they tell us that they have looked into the APIs and see some serious missing pieces.

    With all the change to .NET 5, they are even more confused, since they don’t know why there’s no .NET Core 4 or .NET Framework 5.

    So we are just waiting for you to create .NET 5S and .NET 5X, just to be in line with all the madness inside MSFT.

    • Olia Gavrysh
      Olia Gavrysh

      Carlos, I can totally see how this can be confusing! 🙂
      In 2020 we will merge all platforms in one with the name “.NET”. It will have the version number 5 to emphasize it is the latest among all the existing platforms: .NET Core (latest version 3.1), .NET Framework (latest version 4.8), … . In terms of porting to it, you can think of .NET 5 as the next version of .NET Core, it will be built on top of Core 3.1 with some additions of new features. There still might be some breaking changes. Hope this helps and happy to give more details or answer any questions on it.

  • Avatar
    Stephen White

    @Olia – It would be nice if you could post some examples on how to get PublishSingleFile / PublishTrimmed to work with the Desktop Bridge. We have a WPF app that we converted to dot net core (which is doing great btw! 😀 ) but the MSIX still contains a lot of assemblies that it doesn’t need, which causes delivery bloat. 🙁 We tried using the examples Orin posted on his Github but they don’t seem to work. It’s not a deal breaker by any means, but we’d like to be able to reduce the file size if possible.

  • Avatar
    John Pepper

    Good blog post but the strategy is really confusing. So you want everyone to move to .NET Core because its cross platform BUT

    I can’t take a WPF or Windows Form App and run it on Linux or Mac so I would have to build an entirely new UI
    I can’t use CLI to take my native C++ code and reference it on Linux or Mac
    I can’t update a Windows Form app because the designer won’t be ready for a year
    I can’t really use Visual Basic with a visual designer or with ASP.NET Core or with mobile apps as an introductory program for new developers, so why does Visual Basic still exist?
    -.NET Core is missing pieces of .NET framework so its actually a step back to develop a Windows app on the Core
    UWP has a questionable path forward
    Which leads one to question how you should even develop a C++ program with a UI on Windows these days if you don’t use QT?

    So why wouldn’t I just use Java, Python, or C++ w/ 3rd party UI library for cross platform apps?

    • Avatar
      David Streeter

      VS Code is written in node.js

      I think that tells you everything you need to know about Microsoft’s desktop strategy. They don’t eat their own dogfood any more.

    • Olia Gavrysh
      Olia Gavrysh

      So you want everyone to move to .NET Core because its cross platform
      No. First of all, we don’t want you to move if you are happy where you are. .NET Framework will be supported. The goal of this blogpost was to provide the information about the current and future development of the technologies so you can better plan your activities and choose what is best for your applications.

      Also this “because its cross platform” is not at all what I was referring in the post:
      “But .NET Core, besides being cross-platform, has many other features that can enhance desktop applications. …” and the full section bellow, where I give reasons one may choose .NET Core for their Windows-only applications.

      Since we already responded to most of your points in the previous comments, just a few here:
      – designer not available – the Preview is already out, some scenarios will already work, we are releasing updates every month and looking for supporting most of the scenarios by May 202
      – .NET Core is a step back cause it’s missing pieces – .NET Core does not have parts that we consider outdated and has new technologies and APIs, so by all means it is a step forward. But if you want to use APIs available only in .NET Framework – you can stay on Framework, we will support it.

      But I can see that you are probably looking for developing a new cross-platform application instead of supporting and enhancing existing WPF or WinForms app. This blog was mostly focused on WPF and WinForms on .NET Core. I’ll be happy to learn about your scenario and see if I can suggest something and definitely learn from your feedback for our future plans. If you’ll be up for a phone interview, please reach out to me on olia.gavrysh@microsoft.com

      • Avatar
        Will Woo

        Olia wrote: “No. First of all, we don’t want you to move if you are happy where you are. ”

        If you implement compelling, useful, new C# language features/facilities, but devs can’t use them unless they change to .NET Core (already happened, happening) … and, we are stuck with previews (that are fragile) for a year … do you think we will be “happy” ?

        Provide a way to make a non-GUI Core project using C# 8 Core features, and then, reference, and use, the dll in a FrameWork WinForm or WPF, project ? Is that as impossible as it sounds ?

        cheers, Bill

      • Avatar
        Ismail Demir

        Hi, the problem we have is, the core is “published/announced” as cross-platform programmers like me (hobbiest) was hyped for writing “one code” for different platforms. e.g. VB.Net WinForms Applications running on Linux. Maybe it was a wording from MS but for the most of us have understand it that way. After you (Microsoft) changed your vision about cross-platform, as you said above, community are more tied because the left hand already not know that winforms is only for windows.

      • Avatar
        John Pepper

        Will and Ismail make exactly my point. You can’t stay on .NET Framework because all the new feature development is on .NET core and the entire promise of .NET core is to be able to write one code and deploy anywhere. If Sun/Oracle/QT can have a common UI what can’t .NET?

        Who knows on .NET Core either? Over the course of the almost 20 years I have coded on the Microsoft platform there have been so many go down this direction and it will be the future, only to find it completely abandoned a few years later. Examples include Silverlight, C++ Amp, J#, LINQ to SQL, Visual Studio R Tools, UWP, and now possibly VB entirely (if that is not the case I would challenge you to post a blog with a roadmap that allows it to stay relevant on modern platforms web/mobile). That is a list that makes it hard to sell others on the Microsoft platform.

        I actually have a couple of WPF and Winforms apps that I maintain but what I would really like to do is run those on Windows and Mac. Ideally that would mean allowing .NET Core to have a common UI and allow CLI C++ to compile on other platforms.

  • Avatar
    Daniel Smith

    Hi Olia, is the WinForms designer for .NET Core built into VS 2019 16.4 Preview 3 now? I’ve still got the “(Pre-release) .NET Core WinForms Designer” plugin installed from previous builds – do we still need to keep that installed, or is it no longer required?

  • John McCourt
    John McCourt

    I have a question. I’ve installed preview 1 of the forms designer and I like it. If a preview 2 gets released will my IDE (VS 2019) automatically update to it or will I need to manually do the upgrade? I’m asking this because I’m afraid I might forget to check for an update.

    • Olia Gavrysh
      Olia Gavrysh

      You will get automatic updates with Visual Studio, no manual upgrades needed! 🙂 Just keep in mind that you need to be on Visual Studio Preview for the WinForms designer, since it is in the preview too. And don’t forget to enable the designer in Tools->Options->Preview Features->Use the Preview of Windows Forms designer for .NET Core apps and restart the Visual Studio.

      • John McCourt
        John McCourt

        Thanks for your prompt answer. I have submitted some feature requests using the feedback tool and am going to try submitting some minor ui bugs that I’ve been experiencing when placing items on my forms and moving them around. Also copying and pasting buttons doesn’t seem to work. When you double click for the new (pasted) button it takes you into the function for the old button (even if you’ve changed the name of the new button). Adding a new void in manually for the new button doesn’t work either. I ended up deleting my new button and just created it from scratch instead of using copy and paste. By the time you read this I will already have submitted this as a bug.

  • Avatar
    Paul Rosemberg

    Will there be a control like the ASP FileUpload in the Windows Forms App (.Net Framework) and the file path reference will be like ~/folder ?

  • Avatar
    Daniel Smith

    Do the plans also include making the Data Sources window work with the WinForms designer? In the full framework you can drag and drop classes from the Data Sources window onto the form and it automatically creates all the controls and hooks them up to a BindingSource for you. This is one of my favorite designer features as it’s really great for productivity and saves a lot of manual plumbing work.

Leave a comment