This article is more than 1 year old
Microsoft flips request to port Visual Studio Tools for Office to .NET Core from 'Sure, we'll take a look' to 'No'
Basically, it doesn't work
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."
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.
- 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
"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.
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.