VSTO SE is as “professional” as it gets!
Okay! It works! This means after journaling “Upgrading My Office Solution to a VSTO SE Application-Level Add-In” and “OpenXML/ODF Translator Add-in for Office Uses IDTExtensibility2 Interface” I can safely announce that it is possible to deploy a VSTO SE solution to an “end user” machine! It still took way too long to figure this out because the Office Team is cash cow riding with the the VSTO blimp! My barriers were two items:
- The
SetSecurityshit - Uniquely identifying the assembly with a strong nameWhat Microsoft could not do in 22 pages of documentation (see “Deploying Visual Studio 2005 Tools for Office Second Edition Solutions Using Windows Installer (Part 1 of 2)”), some French kid named Rémi Chambard explained on one page in “Creating a Microsoft Office Outlook 2007 add-in.” In order grant Full Trust to the Word Add-In during installation the
SetSecurityProject output needs be captured by the Add-In Setup Project and arguments need to be passed to the assembly. Rémi took the time to produce the critical pictures showing how this rather tedious task is accomplished. Great job! Without his help, I would still be scratching my head about this:
The issue of strong naming is where I drop the ball and expose my ASP.NET-centric view of the .NET world. So in response to my lack of knowledge in this area, I wrote this article for me: “Framework (SDK) Tools: The Difference between signtool.exe and sn.exe.” I can see from my previously mentioned journal entries that this was going to be a problem for me and I was more than willing to read up.