Microsoft flips request to port Visual Studio Tools for Office to .NET Core from 'Sure, we'll take a look' to 'No'

Microsoft has closed a long-standing request to port Visual Studio Tools for Office (VSTO) to .NET Core, stating that it "will not be updating VSTO or the COM Add-in platform to use .NET Core."

The issue was raised in October 2019 by a developer with Excel VSTO add-ins written in C#. "Winforms has been ported to .NET.Core. Please also port VSTO in C# to .NET 5, to enable add-on development in C# in the 'new .Net," they asked.

Microsoft was initially responsive, and the issue was "queued up for prioritization" the following month. However, last week it was closed unfixed "because .NET Core/.NET 5+ cannot work together with .NET Framework in the same process and may lead to add-in load failures."

The post, attributed to "Feedback bot", assured developers that "the VSTO/COM Add-Ins platform is very important to Microsoft" and promised to continue to support it with the legacy version of .NET, but also stated that "the recommendation moving forward is to use the cross-platform JavaScript APIs."

Office applications like Word and Excel are among Microsoft's oldest and there are a number of ways to extend and automate them, some now regarded as legacy but still supported because of their wide use in business. Old-style Visual Basic (before VB.NET) lives on as VBA, the Office macro language.

VSTO was introduced in 2003 as a way of using .NET to code Office-based solutions. It is based on COM, the Windows Component Object Model, and has access to every API that Office exposes. However, VSTO is Windows-only. Around 2012 Microsoft embarked on a new way to extend Office using a JavaScript API, called Office Web Add-ins or sometimes just Office Add-ins. These are hosted on web servers and use the more limited Office JavaScript APIs.

The advantage is that they work cross-platform, on mobile and on the web. The two approaches have little in common, and there is no way to migrate client-side code other than by converting it to JavaScript.

• Microsoft previews Hot Reload for .NET developers, sets date for .NET 6
• Azure anywhere: Arc adds App Service, Function apps, Event Grid and more to on-premises Kubernetes
• Microsoft's cloud gets JAMstacked: Azure Static Web Apps greenlit for production
• Microsoft has gone to great lengths to push its tech, but survey suggests many devs slipped through the .NET
• Visual Basic 6 returns: You've been a good developer all year. You have social distanced, you have helped your mom. Here's your reward

The advent of .NET Core 3.0 in late 2019 saw Microsoft support Windows-only technology such as Windows Forms and Windows Presentation Foundation with its cross-platform version of .NET, causing VSTO developers to hope that .NET in Office would also be updated – since many had not made the transition to the JavaScript API.

"We need this badly... The JS addins don't work for our use cases, and we already have a large existing code base in .NET Standard libraries," said another developer.

"Our forecasting framework relies on Excel add-in interacting with an OLAP pivot table, which is not supported in OfficeJS," said another coder.

Microsoft's pronouncement has gone down badly. In answer to the question "why not use JavaScript?" they insist that it lacks the features they need, that performance is substandard, and that requiring a web application is a burden.

In answer to the question "why not be happy with .NET Framework 4.8 (the last version)?" they say that performance has fallen behind, that they want new features like native support for ARM platforms, and that compatibility with other .NET libraries will be a problem in future.

"I could live with staying on 4.8 except there are so many improvements for .Net Core 5/6," said another developer. "We support and are adding functionality to a large Word VSTO application for the government... Maybe Microsoft could open-source the VSTO code so users can move it to a modern .Net Core version."

The technical issue is tricky. The problem is that while a certain group of developers are pushing to upgrade to .NET 5.0 or the forthcoming .NET 6.0, there will always be other add-ins that use .NET Framework, and currently COM hosts (like Office) can only support one version of a .NET Runtime. Therefore, an add-in that required .NET Framework would break one that required .NET Core, and vice versa. It may also be necessary to support multiple .NET Core versions because applications can specify which one they support. The reasons for the limitation are not fundamental but it is a scenario that Microsoft has not planned or tested for.

A discussion here on running .NET Framework and .NET Core versions side-by-side covers some of the snags. "Multiple .NET Core versions running concurrently is going to get very dicey," said principal software engineer Aaron Robinson.

History suggests that Microsoft will indeed continue to support VSTO based on .NET Framework for the foreseeable future. The prospects of a change of heart with respect to VSTO on .NET Core look slim, however, despite the real limitations developers encounter when trying to use the JavaScript APIs. Office still works best on Windows, but this is evidence that the company is willing to let it fall behind as a native Windows application, for the sake of pushing developers towards web-based, cross-platform solutions. ®