Category Archives: development

The future of WPF for developers who need to support Windows 7

If you talk to Microsoft about what is new for Windows Presentation Foundation (WPF), a framework for Windows desktop applications, the answer tends to revolve around the Windows UI Library (WinUI), user interface controls for the Universal Windows Platform and therefore Windows 10, which you can use with WPF. That is no use if you need to compile applications that work on Windows 7. Is WPF on Windows 7 in effect frozen?

Not quite. First, note that WPF (and Windows Forms) was updated for .NET Framework 4.8, with High DPI enhancements and bug fixes. The complete list of fixes is here. So there have been recent updates.

Microsoft says though that .NET Framework 4.8 is the “last major version” of .NET Framework. This suggests that WPF on .NET Framework will not change much in future. WPF is open source; but the open source project targets .NET Core, the cross-platform version of .NET. In addition, there are a few features in WPF for .NET Framework that will never be ported, including XBAPs (XAML Browser Applications) – probably not something you care about.

The good news though is that .NET Core does run on Windows 7 (currently SP1 is required). You can see the progress of WPF on .NET Core here. It is not yet done and there are a few things that will never be supported. But when this is production-ready, it is likely that the open source WPF will run on Windows 7 and thus benefit from any updates and fixes made to the code.

From what I have learned here at Build, Microsoft’s developer conference, it is that .NET Core work that is currently top of mind for the WPF team. This means that WPF on Windows 7 does have a future – provided that .NET Core continues to support Windows 7. This proviso is important, since it is the decision of a different team. At some point there will be a version of .NET Core that does not support Windows 7, and that will be the moment when WPF cannot really progress on that operating system.

There may also be a special case. Presuming Edge Chromium runs on Windows 7, WPF may get a new Edge-based WebView control that runs on Windows 7.

Summary: WPF (and Windows Forms) on .NET Framework is not going to change much in future. If you can transition to using these frameworks on .NET Core though, there is more hope of improvements, though there is no magic that will make Windows 10 features available on Windows 7.

One .NET: unification of .NET for Windows and .NET Core, Xamarin too

Microsoft’s forking of the .NET development platform into the Windows-only .NET Framework on one side, and the cross-platform .NET Core on the other, has caused considerable confusion. Which should you target? What is the compatibility story? And where does Mono, the older cross-platform .NET fit in? Xamarin, partly based on Mono, is another piece of the puzzle.

Now Microsoft has announced that .NET 5, coming in November 2020, will unify these diverse .NET versions.

“There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more,” says Microsoft’s Rich Turner.

image

Following the release of .NET 5.0, the framework will have a major release every November, says Turner, with a long-term support release every two years.

Some other key announcements:

  • CoreCLR (the .NET Core runtime) and Mono will become drop-in replacements for one another.
  • Java interoperability will be available on all platforms.
  • Objective-C and Swift interoperability will be supported on multiple operating systems.
  • CoreFX will be extended to support static compilation of .NET and support for more operating systems.

A note of caution though. Turner says there are a number of issues still to be resolved. There is room for scepticism about how complete this unification will be.

More details in the official announcement here.

Update: having looked at these plans in a little more detail, it is wrong to say that Microsoft is unifying .NET Framework and .NET Core. Rather, Microsoft is saying that .NET Core is the replacement for .NET Framework for new applications whether on Windows or elsewhere. Certain parts of .NET Framework, including WCF, Web Forms, and Windows Workflow, will never be migrated to .NET 5. .NET Framework 4.8 will still be maintained and is recommended for existing applications.

Progressive Delivery: the next step in DevOps?

I attended the always-excellent QCon developer conference in London earlier this week. James Governor from Redmonk what there, presenting what he calls Progressive Delivery, the idea being that rather than rolling out continuous and (mostly) small changes to everyone, you segment your deployments. Progressive deployment, see.

image

It is not really a new idea and might even be considered a rediscovery of what we already knew: that it makes sense to deploy new stuff to a small sample first. However it is true that tools are constantly evolving, and Progressive Delivery is perhaps best seen as a necessary refinement to the Continuous Delivery concept. In particular, LaunchDarkly exhibited at QCon; the product is a feature management platform which lets you create groups of users and toggle features on or off for particular groups. Needless to say, the LaunchDarkly folk love the Progressive Delivery concept.

Why Progressive Delivery? My first reaction is that this is about caution: if stuff breaks, let us make sure it only breaks for a few users. Then I saw that it can be equally about bold experimentation, trying new ideas with small groups so you can observe what works and what does not.

Of course you can do this anyway and in the end there is no magic in LaunchDarkly; it is still down to the developer to write the code:

image

This stuff can also easily become non-trivial; one attendee asked about managing database structure and it is obvious that not all features are equally amenable to being switched on or off for groups of users.

Still, I reckon “how do you manage features?” is a good question to add to the list when considering DevOps tools.

You can read most of what Governor talked about in his post from last year here.

Adobe announces extensibility for XD design and prototyping tool, integration with Microsoft Teams, Slack and Jira

Adobe XD (Experience Design) is a tool for prototyping apps and web applications. The full application runs on Windows and Mac, as part of Adobe’s Creative Cloud, and there are apps for iOS and Android that let you preview your designs on a device. Note that it is only a prototyping tool: you still have to re-implement the design in Android Studio, Xcode, Visual Studio or your preferred development tool. However the ability to create and share prototypes is a critical part of the workflow for many applications.

image

Adobe has now announced extensibility for XD via an API. This enables third-party plugins, which will enable “adding new features, automating workflows and connecting XD to tools and services,” according to the press release.

There are also new integrations with collaboration tools including Microsoft Teams and Slack, and Jira (Atlassian’s software development management tool).

The release emphasises that that Microsoft Teams is Adobe’s “preferred collaboration service”, showing that the company’s alliance with Microsoft is still on.

These are not the only tools which integrate with XD. Others were announced in January this year, including Dropbox and Sketch.

What do these integrations do? It is mainly a matter of rich preview within the tool, and the ability to receive notifications, such as when someone comments on an XD design.

Adobe has a generous free starter plan for XD. This includes:

  • Adobe XD
  • 1 active shared prototype
  • 1 active shared design spec
  • 2 GB cloud storage
  • Typekit Free (limited set of fonts)

You can get the free plan here, play around with the tool, and upgrade to the full plan (with unlimited prototypes) if you need to, at $9.99 per month.

RemObjects Elements: mix and match languages and platforms as you like

The world of software development has changed profoundly in the last decade or so. Once it was a matter of mainly desktop Windows development for the client, mainly Java for server-based applications with web or Windows clients. Then came mobile and cloud – the iPhone SDK was released in March 2008, kicking off a new wave of mobile applications, while Amazon EC2 (Elastic Compute Cloud) came out of beta in October 2008. Microsoft tussled within itself about what to do with Windows Mobile and ended up ceding the entire market to Android and iOS.

The consequence of these changes is that business developers who once happily developed Windows desktop applications have had to diversify, as their customers demand applications for mobile and web as well. The PC market has not gone away, so there has been growing interest in both cross-platform development and in how to port Windows code to other platforms.

Embarcadero took Delphi, a favourite development tool based on an Object Pascal compiler, down a cross-platform path but not to the satisfaction of all Delphi developers, some of whom looked for other ways to transition to the new world.

Founded in 2002, RemObjects had a project called Chrome, which compiled Delphi’s Object Pascal to .NET executables. This product was later rebranded Oxygene. For a while Embarcadero bundled a version of this with Delphi, calling it Prism, after abandoning its own .NET compilation tools.

The partnership with Embarcadero ended, but RemObjects pressed on, adding language features to its flavour of Object Pascal and adding support for Mac OS X, iPhone and Java.

In February 2015 the company was an early adopter of Apple’s Swift language, introducing a Swift compiler called Silver that targets Android, .NET and native Mac OS X executables.

The company now offers a remarkable set of products for developers who want to target new platforms but in a familiar language:

  • Oxygene: Object Pascal
  • Silver: Swift 3 (and most of Swift 4)
  • Hydrogene: C# 7
  • Iodine: Java 8

Each language can import APIs from the others, and compile to all the platforms – well, there are exceptions, but this is the general approach.

More precisely, RemObjects defines four target platforms:

  • Echoes: .NET and .NET Core including ASP.NET and Mono
  • Cooper: Java and Android
  • Toffee: Mac, iOS, tvOS
  • Island: CPU native and WebAssembly

So if you fancy writing a WPF (Windows Presentation Foundation) application in Java, you can:

image

As you may spot from the above screenshot, the RemObjects tools use Visual Studio as the IDE. This is a limitation for Mac developers, so the company also developed a Mac IDE called Fire, and now a Windows IDE called Water (in preview) for those who dislike the Visual Studio dependency.

image

Important to note: RemObjects does not address the problem of cross-platform user interfaces. In this respect it is similar to the approach taken by Xamarin before that company came up with the idea of Xamarin Forms. So this is about sharing non-visual code and libraries, not cross-platform GUI (Graphical User Interface). If you are targeting Cocoa, you can use Apple’s Interface Builder to design your user interface, for example.

Of course WebAssembly and HTML is an interesting option in this respect.

A notable absentee from the list of RemObjects targets is UWP (Universal Windows Platform), a shame given the importance Microsoft still attaches to this.

RemObjects is mainly focused  on languages and compilers rather than libraries and frameworks. The idea is that you use the existing libraries and frameworks that are native to the platform you are targeting. This is a smart approach for a small company that does not wish to reinvent the wheel.

That said, there is a separate product called Data Abstract which is a multi-tier database framework.

These are interesting products, but as a journalists I have struggled to give them much coverage, because of their specialist nature and also the demands on my time as someone who prefers to try things out rather than simply relay news from press releases. I also appreciate that the above information is sketchy and encourage you to check out the website if these tools pique your interest.

Pusher: a nice solution for sending messages and notifications to web and mobile apps

Pusher is a London company which runs cloud services for publish/subscribe in web and mobile applications. The idea is to deliver real-time updates, a concept that has many use cases. Examples include price updates in finance apps, status updates to track a delivery, news updates, or anything where users want to monitor progress or keep in touch with fast-moving developments.

The service passed my “get up and running quickly” test. I created a free account (limited to 100 connections and 200k messages per day) and a new channel:

image 

I’m guessing it runs on AWS, looking at the datacentre locations:

image

I chose a JavaScript client and ASP.NET MVC for the back end. On my PC I pasted the JavaScript into a web page running locally on Apache (in Windows Subsystem for Linux). I also created a new ASP.NET MVC project and added the sample code with some trivial modifications. I was able to send a message to the web page; it triggers an annoying alert but of course you could easily amend this to update the UI in more user-friendly ways.

image

Of course you could roll your own solution for this but what you get with Pusher is all the plumbing pre-done for many different clients and automatic scalability.

Pusher also has a service called Beams (formerly Push Notifications) which lets you send notifications to Android and IOS apps.

Pusher or roll your own? As with many cloud services, you are putting a high level of trust in Pusher (security and reliability) if you use the service, and you will need a paid subscription:

image

You are saving considerable development time though, and as Google and Apple update their SDKs or change the rules, Pusher will presumably adapt accordingly.

Can Azure easily do this, I wondered? I headed over to Azure Notification Hubs. I noticed that the amount of admin you have to do to support each device is greater. Second, Microsoft promised to support “push to web” in March 2016:

image

… but has not done so nor even bothered to update those asking:

image

It is odd that Microsoft, with all its drive behind Azure, is still in the habit of leaving customers in the dark in certain areas.

Microsoft announces Visual Studio 2019, but pleasing developers is a tough challenge

Microsoft’s John Montgomery has announced Visual Studio 2019, in a post which is short on any details of what might be in the product, other than to continue evolving features that we already know about, such as Live Share, AI-powered IntelliCode, more refactorings and so on.

The acquisition of GitHub is bound to impact both Visual Studio and Visual Studio Team Services, but Montgomery does not talk about this.

Note there is already a Visual Studio roadmap which gives some clues about what is coming. A common theme is integration with Azure services such as Azure Key Vault (for app secrets), Azure Functions, and Azure Container Service (Kubernetes).

It is more illuminating to read the comments to Montgomery’s post. Montgomery says that Visual Studio 2017 is “our most popular Visual Studio release ever,” which I presume is a count of how many times it has been downloaded or installed. It is not the most reliable though; one comment says “2017 has been buggier than all of the bugs 2015 and 2013 had combined.” I imagine every Visual Studio developer, myself included, has to exit and reload the IDE from time to time to fix odd behaviour. Other comments include:

– Reporting components have to be added per project rather than being integrated into the toolbox

– SQL Server Data Tools (SSDT) lagged behind the 2017 release and still have issues

– the XAML designer has performance and behaviour issues and the new XAML designer in preview is missing many features

In general, Microsoft struggles to keep Visual Studio up to date with its constantly-changing developer platform while also working well with the older technologies that are still widely used. The transition from .NET Framework to .NET Core is a tricky issue for the team to solve.

User Benjamin Callister says this:

I have been developing professionally with VS for 20 years now. honestly, the experience seems to get worse with each new release. the amount of time wasted in my day working with XAML alone makes me more than frustrated. The feeling is mutual among my peers as well – and it has been for years now. VS Code is such a fresh breath of air because of its speed. VS full has become so bloated, working with UWP/XAML so slow, and build times so slow. Also, imo profiling tools should be turned OFF by default, with a simple button to toggle them back on when needed. As a developer, I don’t want them on all the time – rather, just when I want to profile.

The mention of Visual Studio code is an interesting one. Code is cross-platform and has an increasing number of extensions and will be an increasingly popular choice for developers who can live without the vast range of features in Visual Studio.

Microsoft and GitHub, and will GitHub get worse?

Microsoft has announced an agreement to acquire GitHub for $7.5 billion (in Microsoft stock). Nat Friedman, formerly CEO of Xamarin, will become GitHub’s CEO, and GitHub will continue to run somewhat independently. A few comments.

image

Background: GitHub is a cloud-based source code repository based on Git, a distributed version control system created by Linus Torvalds. It is free to use for public, open source projects but charges a fee (from 7$ to $21 per user per month) for private repositories.

First, why? This one is easy. Microsoft is a big customer of GitHub. Microsoft used to have its own hosting service for open source software called CodePlex but abandoned it in favour of GitHub, formally closing CodePlex in March 2017:

Over the years, we’ve seen a lot of amazing options come and go but at this point, GitHub is the de facto place for open source sharing and most open source projects have migrated there. We migrated too.

said Brian Harry.

Microsoft also uses GitHub for its documentation, and this has turned out to be a big improvement on its old documentation sites.

Note also that Microsoft has many important open source projects of its own, including much of its developer platform (.NET Core, ASP.NET Core and Entity Framework Core). Many of its projects are overseen by the .NET Foundation. Other notable open source, Github-hosted projects include Visual Studio Code, a programmer’s editor that has won many friends, and TypeScript, a typed superset of JavaScript that compiles to standard JavaScript code.

When big companies become highly dependent on the services of another company they may become anxious about it. What if the other company were taken over by a competitor? What if it were to run into trouble, or to change in ways that cause problems? Acquisition is an easy solution.

In the case of GitHub, there was reason to be anxious since it appears not to be profitable – unsurprising given the large number of free accounts.

Second, Microsoft is always pitching to developers, trying to attract them to its platform and especially Azure services. It has a difficult task because it is the Windows company and the Windows platform overall is in decline, versus Linux on servers and Android/iOS on mobile. Therefore it is striving to become a cross-platform company, and with considerable success. I discuss this at some length in this piece. Note that there is a huge amount of Linux on Azure, including “more than 40%” of the virtual machines. More than 50%? Maybe.

If Microsoft can keep GitHub working as well as before, or even improve it, it will do a lot to win the confidence of developers who are currently outside the Microsoft platform ecosystem.

image

Will GitHub get worse?

The tricky question: under Microsoft, will GitHub get worse? The company’s track record with acquisitions is spotty, ranging from utter disasters (Nokia, Danger) to doubtful (Skype), to moderately successful so far (LinkedIn, Xamarin).

Under the current leadership, I doubt anything bad will happen to GitHub. I’d guess it will migrate some infrastructure to Azure (GitHub runs mainly from its own datacentres as I understand it) but there is no need to re-engineer the platform to run on Windows.

Some businesses will be uncomfortable hosting their valuable source code with Microsoft. That is understandable, in the same way that I hear of retailers reluctant to use Amazon Web Services (since it is a platform owned by a competitor), but it is a low risk. Others have long-standing mistrust of Microsoft and will want to migrate away from GitHub because of this.

Personally I think it is right to be wary of any giant global corporation, and dislike the huge and weakly regulated influence they have on our lives. I doubt that Microsoft is any worse than its peers in terms of trustworthiness but of course this is open to debate.

Another point: with this acquisition, free GitHub hosting for open source projects will be likely to continue. The press release says:

GitHub will retain its developer-first ethos and will operate independently to provide an open platform for all developers in all industries. Developers will continue to be able to use the programming languages, tools and operating systems of their choice for their projects — and will still be able to deploy their code to any operating system, any cloud and any device.

It is of course in Microsoft’s interests to make this work and the success of Visual Studio Code and TypeScript (which also come from the developer side of the company) shows that it can make cross-platform projects work. So I am optimistic that GitHub will be OK.

Update: I’ve noticed Sam Newman and Martin Fowler taking this view, a good sign from a people I respect and who are by no means from the usual Microsoft crowd.

image

Official announcements

Press release: https://news.microsoft.com/?p=406917

Chris Wanstrath’s Blog Post: https://blog.github.com/2018-06-04-github-microsoft/

Satya Nadella’s Blog Post: https://blogs.microsoft.com/?p=52553832

Case sensitive directories now possible in Windows Explorer as well as in the Windows Subsystem for Linux

Experienced Windows users will know that occasionally you hit a problem with case sensitivity in file names. The problem is that on Linux, you can have files whose name differs only in case, such as MyFile.txt and myfile.txt. Windows on the other hand will not normally let you do this and the second will overwrite the first.

The latest build of Windows 10 (1803, or the April 2018 Update) has a fix for this. You can now set directories to be case-sensitive using the fsutil command line utility:

fsutil.exe file setCaseSensitiveInfo <path> enable

You can then enjoy case sensitivity even in Windows Explorer:

image

This is not particularly useful in Windows. In fact, it is probably a bad idea since most Windows applications presume case-insensitivity. I found that using Notepad on my case-insensitive directory I soon hit bugs. I double-click a file, edit, save, and get this:

image

Press F5 and it sorts itself out.

Developers may have written applications where a file is specified with different case in different places. Everything is fine; it is the same file. Then you enable case-sensitivity and it breaks, possibly with unpredictable behaviour where the application does not actually crash, but gives wrong results (which is worse).

If you are using WSL though, you may well want case-sensitivity. There are even applications which will not compile without it, because there are different files in the source whose name differs only by case. Therefore, WSL has always supported case-sensitivity by default. However, Windows did not recognize this so you had to use this feature only from WSL.

In the new version this has changed and when you create a directory in WSL it will be case-sensitive in both WSL and Windows.

There is a snag. In the full explanation here there is an explanation of how to adjust this behaviour using /etc/wsl.conf and also the warning:

Any directories you created with WSL before build 17093 will not be treated as case sensitive anymore. To fix this, use fsutil.exe to mark your existing directories as case sensitive.

Hmm. If you are wondering why that application will not compile any more, this could be the reason. You can set it back to the old behaviour if you want.

Should Microsoft have made the file system case-sensitive? Possibly, though it is one of those things where it is very difficult to change the existing behaviour, for the reasons stated above. Note that Windows NT has always supported case-sensitive file names, but the feature is in effect disabled for compatibility reasons. It is poor for usability, having files whose names differ only in case which are therefore easily confused. So I am not sure. Being able to switch it on selectively is nice though.

What is happening with desktop development on Windows and will WPF be upgraded at last?

Once upon a time all Windows development was desktop development. Then there was web development, but that was a server thing. Then in October 2012 Windows 8 arrived, and it was all about full-screen, touch control and Store-delivered applications that were sandboxed and safe to run. Underneath this there was a new platform-within-a-platform called the Windows Runtime or WinRT (or sometimes Metro). Developing for Windows became a choice: new WinRT platform, or old-style desktop development, the latter remaining necessary if your application needed more features than were available in WinRT, or to run on Windows 7.

Windows 8 failed and was replaced by Windows 10 (July 2015), in large part a return to the desktop. The Start menu returned, and each application again had a window. WinRT lived on though, now rebranded as UWP (Universal Windows Platform). The big selling point was that your UWP app would run on phones, Xbox and HoloLens as well as PCs. It was still locked down, though less so, and still Store-delivered.

Then Microsoft decided to abandon Windows Phone, a decision obvious to Microsoft-watchers in June 2015 when ex-Nokia CEO Stephen Elop left Microsoft, just before the launch of Windows 10, even though Windows Phone was not formally killed off until much later. UWP now had a rather small u (that is, not very universal).

In addition, Microsoft decided that locking down UWP was not the way forward, and opened up more and more Windows APIs to the platform. The distinction between UWP and desktop applications was further blurred by Project Centennial, now known as Desktop Bridge, which lets you wrap desktop applications for Store delivery.

Perhaps the whole WinRT/UWP thing was not such a good idea. A side-effect though of all the focus on UWP was that the old development frameworks, such as Windows Forms (WinForms) and Windows Presentation Foundation (WPF), received little attention – even though they were more widely used. Some Windows 10 APIs were only available in UWP, while other features only worked in WinForms or WPF, giving developers a difficult decision.

The Build 2018 event, which was on last week in Seattle, was the moment Microsoft announced that it would endeavour to undo the damage by bringing UWP and desktop development together. “We’ve taken all the UI stacks and merged them together” said Mike Harsh and Scott Hunter in a session on “Modernizing desktop apps” (BRK3501 if you want to look it up).

According to Harsh and Hunter, Windows desktop application development is increasing, despite the decline of the PC (note that this is hardly a neutral source).

image

So what was actually announced? Here is a quick summary. Note that the announced features are for the most part applicable to future versions of Windows 10. As ever, Build is for the initial announcement. So features are subject to change and will not work yet, other than possibly in pre-release form.

Greater information density in UWP applications. WinRT/UWP was originally designed for touch control, so with lots of white space. Most Windows users though have mouse and keyboard. The spacious UWP layout looked wrong on big desktop displays, and it made porting applications harder. The standard layout is getting less dense, and a new Compact Size, an application setting, will pack more information into the same space.

image

More controls for UWP. New DataGrid, Forms with data validation, Menu bar, and coming in future, Status bar, tab controls and Ribbon. The idea is to make UWP more suitable for line-of-business applications, which accounts for a large part of Windows application development overall.

New Windowing APIs for UWP. WinRT/UWP was designed for full-screen applications, not the popup-dialogs or floating windows possible in desktop applications. Those capabilities are coming though. We will get tool windows, light-dismiss windows (eg type and press Enter), and multiple windows on one thread so that they work like a single application when minimized or cycled through with alt-tab. Coming in future are topmost windows, modal windows, custom title bars, and maybe even MDI (Multiple Document Interface), though this last seems surprising since it is discouraged even in the desktop frameworks.

What many developers will care about more though is new features coming to desktop applications. There are two big announcements.

.NET Core 3.0 will support WinForms and WPF. This is big news, partly because it performs better than the Windows-only .NET Framework, but more important, because it allows side-by-side deployment of the .NET runtime. Even better, a linker will let you deliver a .NET Core desktop application as a single executable with no dependencies. What performance gain? An example shown at Build was an application which uses File APIs running nearly three times faster on .NET Core 3.0.

image

XAML Islands enabling UWP features in WinForms and WPF. The idea is that you can pop a UWP host control in your WinForms or WPF application, and show UWP content there. Microsoft is also preparing wrapper controls that you can use directly. Mentioned were WebView, MediaPlayer, InkCanvas, InkToolBar, Map and SwapChainPanel (for DirectX content). There will be a few compromises. The XAML host window will be rectangular (based on an HWND) which means non-rectangular and transparent content will not work correctly. There is also the Windows 7 problem: no UWP on Windows 7, so what happens to your XAML Islands? They will not run, though Microsoft is working on a mechanism that lets your application substitute compatible Windows 7 content rather than crashing.

MSIX deployment. MSIX is Microsoft’s latest deployment technology. It will work with both UWP and Desktop applications, will support Windows 7 and 10, will provide for auto-updates, and will have tooling built into Visual Studio, as well as a packager for both your own and third-party applications. Applications installed with MSIX are managed and updated by Windows, have tamper protection, and are installed per-user. It seems to build upon the Desktop Bridge concept, the aim being to make Windows more manageable in the Enterprise as well as safer for all users, if Microsoft can get widespread adoption. The packaging format will also work on Android, Mac and Linux and you can check out the SDK here.

image

Will WPF or WinForms be updated?

The above does not quite answer the question, will WPF or Windows Forms be significantly updated, other than with the ability to use UWP content? I could not get a clear answer on this question at Build, though I was told that adding support for .NET Core 3.0 required significant changes to these frameworks so it is no longer true to say they are frozen. With regard to WPF Microsoft Corporate VP Julia Liuson told me:

“We will be looking at more controls, more capabilities. It is widely recognised that WPF is the best framework for desktop development on Windows. The fact that we’re moving on top of .NET Core 3.0 gives us a path forward.”

That said, I also heard that the team would rather write code once and use it across UWP, WPF and WinForms via XAML Islands, than write new controls for each framework. That makes sense, the difficulty being Windows 7. Microsoft would rather promote migration to Windows 10, than write new UI components that work across both Windows 7 and Windows 10.