VSTO Development - Key Improvements In VS2010 / .NET 4.0?

Question

Hi all,

I am trying to make a case to my bosses on why we should use VS2010 for an upcoming Excel Workbook VSTO application. I haven't used VSTO before but have used VBA. With 2010 just around the corner, I wanted to read about the improvements made to see if it was worth using 2010 to develop this application.

So far I have read 2 major improvements are ease of deployments and also debugging / com interop improvements ...

I was just wondering if there was anything else I wasn't aware of, or if anyone here is actually developing in VSTO and has used 2010 and both 2008 and could help make a case / arm me with information.

The main concern of my bosses is deploying .NET 4.0 runtime on the Citrix servers here... however it seems that with 3.5, we would have to deploy the VSTO runtime and PIA's, etc... So really wouldn't deployments be easier with 2010 because installing just the 4.0 runtime is better than having to install the 'VSTO Runtime' as well as PIA's, etc? Or is there something I'm missing here? Anyone here deploy VSTO app in an enterprise and can speak to this?

Also - I'm trying to also fight to use C# over VB.NET for this app. Does anyone know any key reasons why (except for my bias on preference of syntax) it would be better to use C# over VB for this? Any key features lacking in VB VSTO development? I've read about the VSTO Power Tools, and one of them describes LINQ enalbment of the Excel Object Model classes - however it says 'a set of C# classes'... Does anyone know if they literally mean C# - so this would not work with VB.NET, or do they just mean the code is written in C#? Anyone ever used these power tools with VB? I am going to download & play with it now, but any help again is greatly appreciated

Thanks very much for any information.

Answer 1

I have not used VS2010 for Office development yet, but I have used VS2008 for Word addins and the Ribbon also, I used VB.NET.

Deployments all depend on how strict you are with security. I was on a USAF site and it required the highest security settings, which required signed assemblies, and some hacks with C++ to get things working perfectly, due to limitations in VSTO and Office. I hear they fixed most of the issues in the new version.

The other problem I found is that there was not any books for VS2008/Office/Addins at the time, which made things difficult. Also the web is cluttered with examples in the various versions of VSTO, Visual Studio, which make finding working examples very difficult.

VB has/had a advantage because it supports optional parameters. C# is getting them, not sure if it was 4.0 that they get them. If you have existing code in VBA or VB, I would recommend staying with VB. The Power Tools will work with both languages.

As for deploying .NET4.0 on Citrix; I can't see that being a problem, but I think you do need to login with that special Installer profile.

You could build a small prototype to try things out...

Answer 2

I have partially gotten a VSTO addin to work with Outlook 2007 running from Citrix XenApp5 togheter with RES PowerFuse. The addin is loaded by Outlook and is visible and active from the security center. One important thing I have learned is that you must create a custom installera since you need to install the application to local machine, HKLM, for Citrix enviroment to pickup the Office addin. This looks like it is supported with Office 2010 and there is a hotfix for Office 2007 to enable this (KB976811 available through KB976477).

The issue I’m still struggeling with is that non of our custom views are loaded by Outlook when running from Citrix. The addin is a WPF application built on top of the PRISM library

Answer 3

Deploying VSTO 3.0 to the Enterprise:

Nothing particularly tricky about this. I would definately recommend you use your companies packaging system such as Altiris or SCCM for deployment. When packaging make sure you add the CustomInclusionList project (and customise it according to the MSDN docos) + optionally sign your assemblies if you have a code signing cert.

If your in a locked down environment you'll need a packaging technology to allow the package to be installed as an admin. Otherwise the deployment will be a nightmare. Be careful when getting packagers to re-author the package that is produced by Visual Studio. You need to ensure that all the registry keys are retained, custom actions, etc You'll probably be deploying to HKCU hive, which means users won't be able to uninstall the addin themselves (unless they are admin).

Note that if users are getting a prompt when they go to open an office app asking "Do you want to install/not install this addin,etc" then the custominclusionlist project is not properly configured or you are missing a registry key.

On Citrix:

This seems to work fine. The main thing is getting the citrix servers fully updated to latest Office build with all prequistes installed prior to deployment. This is trivial if you have a well maintained system of patching. As the other answerer said nothing special with Citrix. It will just work, should install to HKCU to avoid any issues.

PowerToys for VSTO:

yeah these are great. They work equally well from either VB or C#. they are language agnostic, i think the statement you are refering to just meant they were authored in C#. On deployment make sure you include the Extensions assembly either locally or in the GAC. it won't be installed to the users machine even though they will already have the Office 2007 PIA component installed.

On using C# over VB.net:

no comment! yeah i'd go C#, although some complain that its more verbose than VB for VSTO projects i think most of this is legacy. Look for the really bad methods that have like 30 optional arguments you have multiple ways of dealing with this now. Write an extension method yourself or most of the time use the ones available with the Excel.Extensions and Word.Extensions namespaces. Also you could write overloads in a static helper class and call methods such as Open with just the parameters your going to use. Ultimately you must make a decision based on what the majority of programmers are better with, and as a result where your orgs strength in programmer resources lies. You may be a guru at C# but if the other 9 guys are VB.net wizs then it makes sense to do projects in VB.net. still try and convert them, but the real decision is with the techlead/manager not with the code monkeys.