To read previously blogposts on the subject please see:
Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part I
Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part II
Creating and Deploying Managed COM Add-ins with VSTO 2005 SE – Part III
Introduction
This article and the coming articles on the subject sets explicit focus on the deployment process.
In general for less advanced COM add-ins created with classic VB deployment is not an issue. If there are any problems the online community has usually a good knowledge about it.
For COM add-ins created with VB.NET (Shared Add-in template) the situation may be different as there may be deployment issues related to .NET Framework, PIA/IA, and the targeting Office version(s). Compared with classic VB the VB.NET deployments issues may be more complex and difficult to solve but within the online community there exist a general experience and a common good knowledge about .NET based deployment.
When it comes to VSTO created managed COM add-ins the situation is total different situation then with the above cases. Microsoft has a high development pace for VSTO and for every new version most major known problems are solved but at the same time new problems are created.
We need to be aware of two important aspects:
- The VSTO technology is still a “newborn” baby and still suffers of “teething problems.”
- In order to run VSTO solutions it requires a runtime version of VSTO to be installed on the targeting computers. It means that an additional layer is placed between Excel and the tools.
The following picture views the number of layers that exist in order to use VSTO solutions with Excel:
If the COM add-in(s) are loaded when Excel starts then both the .NET CLR and the VSTO Runtime need to be started before Excel can load the COM add-in(s). If they already are running, especially the CLR, then launching Excel will be much faster compared with the opposite scenario.
The picture also shows the levels where there may occur errors. It means that the complexity is high when it comes to tracking down errors. In addition, Microsoft has recently released new versions/updates:
- The first version of Office 2007,
- Some fixes for Office 2003,
- The first version of Windows Vista,
- SP-1 for the Visual.NET suite and,
- Version 3.0 of the .NET Framework.
Which increase the complexity of error tracking as new versions/updates as well as the number of new versions are potential sources for errors.
So when we compile the above list with the present possible configurations the list gets very long. In other words, the complexity increase heavily as the number of possible sources of errors increases.
The more advanced technology that is involved the more “sensitive” it tends to be. VSTO is no exception. The real difficult scenarios to deal with are:
- The Office installation is corrupted (including the PIAs).
- The .NET Framework installation(s) are corrupted.
- The VSTO Runtime installation is corrupted.
- Installations of Service Packs and monthly fixes of Windows go wrong.
Since we don’t have access to relevant diagnostic tools that provide us with relevant system information the above issues are part of the “Black Box”-syndrome.
In my opinion it’s a must that MSFT as soon as possible makes diagnostic tools available that actually can help us out.
Large corporates with dictating standards and configurations are better off than other corporates. Since VSTO explicit target this group of corporates developers, we who are not associated with this group of corporates will face a more challenging situations with smaller customers.
When all the above pieces are put together we end up in a situation where:
- Deploying VSTO solutions can be less complex or quickly turn into “nightmares”.
In order to get friendly solutions the two areas that should be in focus are prerequisites and security
Prerequisites
Prerequisites are components that need to be installed on the targeting computers and must work properly in order to get VSTO’s managed COM add-ins working. The above picture is the skeleton to discuss the prerequisites.
Security
Code Access Security (CAS) is the .NET CLR mechanism for maintaining security based on the identity of code. In order to get VSTO created managed COM add-ins to work the assemblies must have full permissions, i e granted full trust. When a VSTO project is created on the developing computer it gets automatically full permissions. However, when deploying the VSTO project on the targeting computers we need to make sure that it gets full permissions.
In the next article I will discuss strategies when it comes to prerequisites and in the final article I discuss CAS and VSTO.
Finally, I believe that Microsoft will, during 2007, make improvements that eliminate most of the issues we face today and also make it possible to use ClickOnce with VSTO.
Kind regards,
Dennis
VSTO & .NET & Excel 
Dennis,
I want to build an Add-In that targets Excel 2003 and Excel 2007. I thought that VSTO SE would be a good dev framework because it’s supported by MS and it has fast loading.
But when I read your post I have the gut feeling that I’d better fall back to a shared .NET add-In or to better avoid .NET at all and build a XLL/C++ add-in.
Comment by Andreas Lipphardt — January 23, 2007 @ 7:01 am
Andreas,
VSTO is a nice coming platform to develop add-ins with but at present it’s my opinion that is not ready for production. Within the nearest future MSFT will release version 3.0 of VSTO.
From my point of view I would go with the .NET Shared add-in and later consider to upgrade it to VSTO.
If You’re very comfortable with XLL/C++ then it will be an option.
Kind regards,
Dennis
Comment by Dennis Wallentin — January 23, 2007 @ 11:43 am
Dennis
Do you think the VSTO runtimes will be included with the next version of Office?
I’m looking forward to your next posts as I feel there is some way to go with the VSTO deployment story.
cheers
Simon
Comment by Simon Murphy — January 23, 2007 @ 4:16 pm
Simon,
The present situation with the PIA for 2003 and 2007 clearly indicate that it’s the wrong route go.
If we first install 2003 or 2007 then the PIA will not be installed as .NET Framework 1.1 and higher is not available. After we have installed the right version of the PIAs we face another situation – it does not work. In order to get it to work we need to add KB908002 fix. After that it may or may not work!
The PIAs, VSTO runtime and the .NET Framework need to be integrated in version specific packages. That would probably reduce the number of issues considerable. In the long run they should be part of the operating system. For me that’s the the only reasonable way to go.
Kind regards,
Dennis
Comment by Dennis Wallentin — January 23, 2007 @ 6:10 pm
I didn’t know about this KB 908002 issue at all. Is this a VSTO issue per-se or a Shared Add-in issue? The KB 908002 article does not mention VSTO anywhere. So I guess any shared add-in needs to be aware of this patch, at least if they are using Smart Tags, anyway.
I’m not a VSTO guy at all, so maybe 3.0 will make me a convert. What I like about VSTO is that shimming is handled automatically via the ‘AddinLoader.dll’ mechanism. The 2003 vs. 2007 version issue persists however… I think the best solution in this case is to simply make separate builds for each version. Changing the references and re-compiling is no big deal, especially when compared to the differences between the code required to control the 2003 CommandBars vs. 2007 Ribbon.
Very nice article Dennis…
Comment by Mike Rosenblum — January 23, 2007 @ 6:38 pm
Mike,
The KB908002 initially targets Shared Add-ins but I don’t exclude it when it comes to VSTO issues…
At present MSFT strongly recommend to only use VSTO 2005 SE on a developing machine that either has Office 2003 *or* Office 2007 installed.
Suppose we want to ship two VSTO solutions to one client, one that target Office 2003 and one that target Office 2007. It will require that we actually do have two legal copies of VSTO 2005 SE and two machines or running virtualising systems on one machine with a large disk.Edit note: Just to clarify that it’s possible to develop a VSTO solution with Office 2003 and to get it to work with Office 2007.(It reminds me that I should test to develop a Shared add-in for both 2003 and 2007 with 2003 PIA to see if it possible at all!)
Kind regards,
Dennis
Comment by Dennis Wallentin — January 23, 2007 @ 6:59 pm
> “Suppose we want to ship two VSTO solutions to one client, one that target Office 2003 and one that target Office 2007. It will require that we actually do have two legal copies of VSTO 2005 SE …”
Are you sure about that? VSTO 2005 cannot build to both 2003 and 2007? I don’t really have a clue one way or the other, but this doesn’t sound right… But you’d know much, much better than I would. Could you explain thi?
> “(It reminds me that I should test to develop a Shared add-in for both 2003 and 2007 with 2003 PIA to see if it possible at all!)”
Again talking VSTO here? I make standard Managed COM Addins targeting the 2003 PIA and it runs on either 2003 or 2007 just fine. (Only one build.) Of course I don’t have any RibbonX code in it! (Obviously RibbonX is an entirely different matter.)
But if there is a VSTO issue here, then yes, do test do test! Enquiring minds want to know… 🙂
Comment by Mike Rosenblum — January 23, 2007 @ 7:07 pm
Mike,
>>Are you sure about that?
Yes, MSFT strongly recommend to not install VSTO 2005 SE on any computer that has both 2003 and 2007 installed.
>>VSTO 2005 cannot build to both 2003 and 2007?
No, we need to take an active decision to either target 2003 or 2007.It’s possible to build to 2003 and 2007.>>Again talking VSTO here?
Yes, I meant VSTO but wrote “Shared Add-in”…
Kind regards,
Dennis
Comment by Dennis Wallentin — January 23, 2007 @ 7:19 pm
Dennis
I keep reading your blog and thinking maybe all this .net/office stuff is mature enough to get back into. (I was quite disappointed when I first looked into the detail a couple of years ago).
Then I look at this deployment pain and version pain and I think i would prefer to just email an xll and know it will work.
VB6 is heading out of extended support next year do you think VSTO will be a viable replacement and will it be ready in time?
cheers
Simon
Comment by Simon Murphy — January 24, 2007 @ 1:00 am
Simon,
Let us see what the next version (3.0) offer and if most of the shortcoming we now face with 2005 / 2005 SE have been solved in that version or not.
Kind regards,
Dennis
Comment by Dennis Wallentin — January 24, 2007 @ 2:22 pm
Dennis,
Excellent set of articles & has really got me thinking twice about heading down the VSTO route just for now. I find it quite upsetting that whilst MSFT have rushed some excellent new tools to market, there exist some gaping holes in their current interactivity.
VSTO ceratinly seems to require version 3.0 asap.
I have also been recently a little disappointed with MOSS (Office 2007 Sharepoint Server) as “out of the box” it seems not to support the SQL 2005 Reporting Services Web-Parts that were available to Sharepoint 2003. You either have to wait until SQL 2005 SP2 and even then, if you run in “integrated mode” you lose the ability to manage reports outside of the MOSS environment. Apparently MSFT are working on complete feature parity, however that will not be with us in SP2.
Adopting these new technologies sure can be frustraing. What I find is that corridors of new possibility opening up (with MOSS, VSTO, SQL BI Tools etc) but that you get halfway up the “corridor” and find a locked door that “will be opened soon with SPx etc”
Don’t get me wrong – overall, the new stuff is excellent, however we have had to adopt a mixed approach to deployment in stage 1 of our project due to some loose ends not being tidied up pre-launch. This is frustrating to say the least.
My 2p… Keep it up Dennis… I’m reading if not much time for commenting at the moment 🙂
Will
Comment by Will Riley — January 28, 2007 @ 6:04 pm
Will,
Thanks for taking Your time to comment and for Your kind feedback 🙂
Yes, I can agree on the “love & hate” feeling we tend to end up in when using the latest available technologies. The “it will come in a future fix” can be acceptable in the short run although it can be very frustrating.
What is not acceptable is the lack of reliable and upto date documentation. Here it has become painful obvious that MSFT lack experience and coordination when releasing new version of nearly all softwares during a short time. I can only speak for Office 2007 and VSTO but it would not be a surprise if this case is also valid for other softwares too.
Kind regards,
Dennis
Comment by Dennis Wallentin — January 29, 2007 @ 11:46 am
Hi Dennis…
Yes, the documentation issue has prompted me to write an article about specifically the SQL/Excel/Sharepoint integration issues on my blog. It took around 2 days of trying to do what I later found was impossible and a further 2 days on Google to discover
1. What I couldn’t do
2. Why I couldn’t do it (i.e. software’s fault not developer error 😉 )
3. What I could do to correct it
It’s true that it is the lack of a single place to go for the information that I found particularly frustrating. I have extensive “links” to places and it took me some time. For the “novice” user it would be a nightmare to sort out.
Happily, the solutions listed do work and I am once again moving along, however last week ended up being very frustrating & with little progress as a result.
Kind regards,
Will
Comment by Will Riley — January 29, 2007 @ 2:07 pm
Will,
I can only imagine the number of hours You and other spend (including myself) to find out what is workable and what is not…
From a broader point of view it would be nice to get the printed MSFT books back, which was distributed with the software. Sure, it cost more for all parts and they can be boring BUT we got a great start 🙂
Kind regards,
Dennis
Comment by Dennis Wallentin — January 29, 2007 @ 4:25 pm
Absolutely!
It would be very interesting to add up the “lost time” I have had over the last six months with my current project – mostly due to poor or lack of documentation/information. It would be a significant number of me-days I am sure…despite the fact that I have attempted to follow the MSFT “suggested technology route” 😉
It’s actually been quite difficult to find really comprehensive books for the suite of SQL 2005 and especially Sharepoint 2007. Many of the so-called MOSS 2007 books still seem to be merely updated versions of old SPPS 2003 Books… but how could that be when WSS 3.0 and MOSS 2007 are supposedly such a major step-change – is it publisher/author laziness ?
AFAIK, republishing anything around SPPS 2003 will just not cut it in the 2007 version as it’s been comprehensively rebuilt from the ground up so I am amazed at some of the offerings in text form.
Anyway, I just ordered Bill English’s Sharepoint 2007 Administrator’s Companion as I am finding it really difficult to get good “help” for MOSS 2007. Him and the Mindsharp crew seem to be a bunch of guys I can trust to deliver the goos so let’s hope so 🙂
Kind regards,
Will
Comment by Will Riley — January 29, 2007 @ 4:47 pm
Something struck me in reading your next post, Dennis, but it’s relevant to this one…
You’ve had three articles to this point on building and add-in using VB.Net and VSTO. This is the first on deployment, and in the next one you said two more. So we have 3 to build, and 4 to ship. (Okay, okay, we can all add, I know.)
The point I’m making here is that this is not a good thing. Deployment should/will have issues, to be certain, but it should not be complicated enough that you feel the need to post this many articles on the subject. You’ve said it, or at least alluded to it, that this process needs to be made easier.
Lord knows that I haven’t even tried to tackle deployment yet… I’m almost finished building my first add-in in .Net. The next step seems like a huge one. My concern, from a consultant point of view, is that I’m paid to code, not to deploy and deal with those issues.
At any rate, kudos for the great work. (And I’m pleased that I’m able to finally follow along! 🙂 )
Comment by Ken Puls — January 29, 2007 @ 7:03 pm
Ken,
Recently there was a thread on MSDN’s VSTO forum what a coming book should focus on.
The answer was:
Deployment
Deployment
Deployment
At present none of the available books (including the latest one) include any discussion about deployment.
The #1 issue developer have is deployment.
The more I read and the more I think of it the more I realize that is important to cover. In a way it’s reflected in this series of VSTO.
I totally agree with You that deployment per se should not be an issue. Unfortunately it is…
Kind regards,
Dennis
Comment by Dennis Wallentin — January 29, 2007 @ 7:26 pm
Will,
What You’re saying is that publishers and their respective authorgroups are having difficulties…
– Old work cannot be used (expensive to write new material)
– What to focus on (i e what is best selling —-> income?)
– MSFT finalized version(s) have been published late (we need to be first out to cut some marketshares from our competitors).
In a upcoming blogpost I will be *very honest* about the available VSTO-books.
Kind regards,
Dennis
Comment by Dennis Wallentin — January 29, 2007 @ 7:35 pm
“What to focus on (i e what is best selling —-> income?)”
I see a market for a book about deployment. 😉
Cheers,
Ken
Comment by Ken Puls — January 29, 2007 @ 7:55 pm
Ken,
I believe that MSFT with the next release (3.0) will solve the most difficult deployments issues. If not then VSTO will be a “dead end” for all developers.
You will propably be hearing a lot more of deployment at the upcoming summit.
Kind regards,
Dennis
Comment by Dennis Wallentin — January 30, 2007 @ 7:27 pm
Hi Dennis,
I believe you’re right on the latter.
With regards to the former, the question actually comes back to MS more than anything. Unfortunately, MS doesn’t always appear to listen to the needs of their customers as much as they push what they think should be upon them. (Maybe that’s harsh, but the deployment nightmare that exists is due to someone NOT looking at client need.)
Hopefully this does get addressed at the summit, and hopefully MS listens.
Comment by Ken Puls — February 7, 2007 @ 12:56 am
I have been working on an Outlook 2003 add-in for 4 months in VSTO 2005 SE. Development when fine. Deployment, on the other hand has been very painful. I have had to use one of my MSDN subscriber incidents for this. My Microsoft contact (Mohammed) has been great. The bottom line turned out that VSTO does not work on Office Standard edition which is what all of our users have. Since then I got smarter. I created a mini shared add-in that just displays a message box and tried to deploy that. Eventually, my Microsoft contact figured out what the problems were.
Since then, our company has decided to migrate to Outlook 2007 before I could get the 2003 add in deployed in production. And since VSTO works on all versions of Office, I am back to trying to get a mini version of VSTO deployed for Outlook 2007.
Based on experience, I would recommend that anyone considering this type of development, figure out deployment first. There are all kinds of VSTO programming examples out on the internet, but very, very few articles on deployment. The ones I did read were confusing and were hard to follow w/o my Microsoft contact.
Here are the main things I ran into. Part of it is my own lack of .NET experience w/ VSTO.
I did not have the Office2003PIA folder setup correctly and the same will be true of the Offcie2007 PIA folder.
The default compile option is Debug and to deploy, it needs to be Release. I have programmed almost exclusively in VB6 which doesn’t have all this.
Comment by Sarah Schreiber — March 19, 2007 @ 8:28 pm
Sarah,
Thanks for sharing Your experience and insight. Unfortunately this is not the first time (or last time) I will take part of similar experiences…
Another issue You indirectly points out is that corporate’s developers usually have access to the latest tools as well as more advanced versions of Office. While the end users use older versions and usually the standard version of Office. However, this will only be an issue until everyone have updated to 2007 and later version.
Kind regards,
Dennis
Comment by Dennis Wallentin — March 19, 2007 @ 11:49 pm