Since the VSTO (Visual Studio Tools for Office) are not ported to the CORE, there is a question about its future.
https://developercommunity.visualstudio.com/idea/757925/please-port-visual-studio-tools-for-office-vsto-to.html
Microsoft said (on the Ignite that just finished) that they are going to move to .NET 5 in November, which is essentially .NET core.
That basically means that you won't be able to build Visio extensions in .NET from November, right? Or am I panicking for nothing?
Has anybody experience using .NET CORE (3.x) to build an extension? I have only found this article from one year ago, and it's actually just launches Visio.
https://visualsignals.typepad.co.uk/vislog/2019/02/visio-interop-with-net-core-30.html
My project template (https://marketplace.visualstudio.com/items?itemName=NikolayBelyh.ExtendedVisioAddinProject2017) fails miserably for now if you try to do a .NET CORE project ;D
Since Javascript API for Visio is for viewing only (no modification) and is also quite limited, it's not really an option for now.
Quote from: Nikolay on September 25, 2020, 06:14:51 PM
That basically means that you won't be able to build Visio extensions in .NET from November, right? Or am I panicking for nothing?
I know MS are (in)famous for just dropping various parts of their technology, however, I can't see the standard .NET being dropped immediately. It might not get improved and updated quite so much though. So much software is built on .NET that it would break the whole world if it were to be just withdrawn!
Nikolay will there be a new Visual Studio (2021?) that supports VSTO with the compatible .NET frameworks? If so that will be a relief also.
Your question is really important, because there are so many VSTO-based solutions for Excel and PowerPoint I think Microsoft will keep provid9ng good support for it, but important to stay on top of this development your post about your concern is much appreciated!
I don't know. The point is, they are planning to merge all "frameworks" to rule them all. That will be .NET 5, and that will be the only one.
All the previous ones will be maintained of course, but probably not developed further.
It is just if you consider starting something new in the area of Visio extensions, the future is not clear.
I mean, the VSTO will be "already not there", but the JS is will be "not there yet".
The only option I see is the good old COM add-in (COM is supported in .NET CORE starting from 3.1).
Since .NET CORE runs also on LINUX, there may be some tricky stuff. Like, how do you register things in registry if there is no registry :D
A COM add-in has the same performance advantages of VSTO running in the same process as Visio?
Are there things a COM add-in cannot accomplish vs a VSTO solution?
They have the same functionality and performance. Just the "connecting/disconnecting" code is a bit different.
From the development point of view, visual ribbon designer in Visual Studio is only available for VSTO add-ins
Means, for a COM add-in you'll need to write the ribbon XML file by hand.
But basically VSTO provides a COM wrapper, and by Visio VSTO add-in are treated as a special kind of COM add-in.
One known issue (as far as I remember) is that all .NET COM add-ins are registered using single DLL (mscoree.dll) so disabling a single add-in disables all.
By disabling, I man, Visio may "block" an add-in that behaves inappropriately, so if Visio blacklists at least one COM add-in, all COM add-ins will be blacklisted.
May be not the case with .NET CORE though (they generate yet another wrapper. lib.comhost.dll)
https://docs.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
Thank you Nikolay very good to understand, also sounds like it isn't too much work for Microsoft to add VSTO to .NET 5.x!
According to my experience, it's always not much work until you start actually doing it... ;D
My bet (one good whiskey bottle): Microsoft will deprecate (move to maintenance) VSTO in about 2 years.
Anyone? ;D
I hope not. Office add-ins are a key benefit of Office desktop, which has long term support. It would be a bad decision to drop a key feature.
A COM add-in in .NET 5.x plus making Ribbons manually still an ok compromise, if other COM add-ins cause issues this can be diagnosed and treated (other COM add-in removed).
Quote from: Nikolay on September 29, 2020, 05:21:49 PM
According to my experience, it's always not much work until you start actually doing it... ;D
Everything is just a 5-minute job until you actually get down to it.
Once upon a time I got three 5-minute jobs done in one day!
Nikolay do you have a link with more info about COM support in .NET Core / 5.x? Thank you!
" Please port VSTO to .NET 5 (.NET Core). JS is no replacement for a real programming language and proper API, even if it is COM-based. I don't care that it is Windows-only, as that is already the case with VSTO, but having access to the many new features and performance enhancements in .NET Core would be huge. With the enchancements to COM Interop in .NET Core 3 along with Winforms, not much should be needed to port over VSTO."
https://developercommunity.visualstudio.com/idea/757925/please-port-visual-studio-tools-for-office-vsto-to.html
That's why I'm asking - has anyone tried to build an extension in .NET CORE (in the title of the topic).
One clickable button could be good enough I guess. The main mess is COM registration I guess (i.e. actually making a .net core library a visio add-in)
Are .net core components registered the same way?
They are asking to run regsvr32 - this already looks suspicious, like something fishy is hapenning here, usually it's regasm for .net components. What is this .comhsot dll exactly?
Also, type libraries (.tlb) files are not supported. Will Visio load an extension that does not provide type library? And does not implement IDsipach, because it's also not supported in .net core (there is no DLR runtime)?
Was able to register and run an add-in with the brand new .NET5 (CORE) ;)
Basically all the same, but VSTO smply does not exist.
You need to go the old way of registering using COM.
And the dynamic runtime basically does not exist.
And you have to have separate installs for x86 and x64
But now it loads and shows the ribbon :D
Sample project (with setup): https://github.com/nbelyh/VisioComAddinNet5
To run, you'll need .NET 5 installed.
Will update the project template to support .net core 3.1 / .net 5!
Wow Nikolay amazing work!
Nikolay do you notice a performance improvement with the .NET Core 5.0, I understand running more CPU resource-intensive code (that does not interact via the interop with Visio at that time, because that would be the bottleneck) can provide some nice performance improvements over .NET 4.x.
Since it is a "Hello World" project basically, I don't think I would be able to notice any performance differences ;D
Ok I have a pretty heavy-calculation layout algorithm that I'll test on a 2000+ shape diagram (doing everything in-memory no back and forths over the Visio interop until the layout is calculated). I can run two threads in parallel in this algorithm so hopefully .NET 5.0 will give 10x the performance of VBA.
I think now it's more of a research project actually, just to see if it's feasible at all.
It might be a bit premature to think about using this setup (.NET5 + Visio COM add-in) in production environment :)
Yes you're right but still interesting to try, I see some pretty good performance improvements in .NET Core!