VSTO & .NET & Excel

November 7, 2006

VSTO 2005 SE

Filed under: .NET & Excel — Dennis M Wallentin @ 7:45 pm

With Visual Studio.NET 2005 (VS.NET 2005) we can create standalone applications that automate and control Excel. We can also create so called managed COM add-ins, either based on the template ‘Shared Add-In’ or from scratch with VS.NET 2005.

The present main edition of Visual Studio Tools for the Office System (aka VSTO) can either be run as a standalone tool or as a ‘plug-in’ to the VS.NET 2005. This is important to know that it per se does not require that VS.NET 2005 to be installed, only the .NET Framework. If wanted, Office developer can develop .NET based solutions only with VSTO although it limits the target versions of the Office suite.

With VSTO 2005 (internal version 2.0) we can create document-level solutions (i e templates, files for specific tasks, smart documents and smarttags). It’s also possible to create application-level managed COM Add-ins with it but only for Outlook 2003 and later.  

In order to create any VSTO solutions we need to have the Professional Edition of Office 2003 or later installed on both the development machine and on the targeting machines. It also requires that the target machines have both the .NET Framework and the VSTO runtime installed. In my opinion VSTO is a development platform typical for enterprise solutions and where the requirements can be met via central controled IT-structures (especially the security aspects).  

In the end of the summer 2006 MSFT released the beta of VSTO 2005 SE (Second Edition) which I have explored together with Excel 2007. Today MSFT announced that the final release of it is now available for download.  It’s very important to understand that it does not replace the present version of VSTO 2005. It adds new functionality to VSTO 2005 to create application-level solutions (managed COM Add-ins) for all applications in the Office 2003 and 2007 suite with VSTO.

Before I downloaded the final release I read the following from the download page:

“Do not install VSTO 2005 SE on a computer that has more than one version of Microsoft Office installed.”

From a strictly enterprise point of view this is not remarkable in any way. After all, large worldwide enterprises usually run one version all over the world (at least in my experience). But for us small developers who are forced to work with several versions of Office (as well as different language versions too) it gets more difficult with VSTO with this kind of requirements.

If You already use VSTO and want to read more and download VSTO 2005 SE: VSTO 2005 SE

The above gives me the opportunity to put together a rather primitive but workable guideline when it comes to developing COM Add-ins for Excel:

# Use classic VB:  

  • If the add-in target several versions in the range of 2000 – 2007 or all of them. 
  • If You can’t afford to buy VS.NET 2005 or VSTO 2005 / 2005 SE and
  • If the customers don’t explicit demand a managed COM Add-in solution.

# Use VS.NET 2005 or use VSTO 2005 + VSTO 2005 SE

  • If the customers explicit demand a managed COM Add-in and
  • If the add-in target one version of 2003 and 2007 or both.

As You can see I don’t make any differences between VS.NET 2005 and VSTO 2005/VSTO 2005 SE. Developing managed COM add-ins with VS.NET 2005 require that we ‘shim’ the solutions. VSTO already use a loader that doesn’t requires any ‘shimming’ but on the other hand it requires the VSTO runtime to exist on the target machines.

If we explicit target the areas of smart documents, smart tags and data bounded workbooks then VSTO is probably the best way to go.

The above guideline should not prevent us from learning and exploring both VS.NET and VSTO (which explain why this blog exist).

Finally, a comment on MSFT’s  “new” terminology. MSFT use the following terms:

  • “Unmanaged COM Add-ins” and “COM Add-ins” are OK for me as they imply that they are developed with an older technology then .NET.
  • “Managed COM Add-ins” is also OK for me as it implies that they are developed with a tool that requires .NET Framework.
  • “Managed Add-ins” is used for VSTO 2005 SE solutions.  I totally disagree with the phrase because it imply that COM is not part of the communication between the host application(s) and the add-in(s). I prefer “Managed COM Add-ins”.
  • “Add-ins” should only be used for add-ins created with the host applications.
     

Kind regards,
Dennis

Ps. I promise that in my next blogpost will take the ‘transition case’ further by showing the solution as a COM add-in developed with classic VB (that is VB 6.0).

Advertisements

12 Comments »

  1. Hey Dennis,

    Nice article. 🙂

    Unfortunately for me, I have only one machine for use and development and I already take too many risks as it is… One of these days I’ll have a bad crash and will lose a day having to rebuild this thing.

    Until and if I can get myself a 2nd machine, I don’t think I’m willing to experiment with the ‘SE’ version at this point. Especially since it’s not recommended with more than one Excel version installed!

    Btw, when I installed the Excel 2007 Beta 2, it corrupted my Excel 9.0 and 10.0 installations and will no longer run. Pretty odd. My 11.0 was fine and the 12.0 Beta ran fine. I wonder if this situation is in any way related to this warning with respect to VSTO ‘SE’? Who knows…

    Mike

    Comment by Mike Rosenblum — November 7, 2006 @ 8:07 pm

  2. Thanks Mike 🙂

    You don’t need to have two machines or more. Make sure You either replace the present hard drive with a larger one (>200 GB) or use two hard drives. The You can set up Windows in a way that allows You to choose which OS to start each time the computer is booted.

    “Btw, when I installed the Excel 2007 Beta 2, it corrupted my Excel 9.0 and 10.0 installations and will no longer run. ”

    Sounds like lot of extra work to restore the configuration… I believe we have both good and bad experience with running beta versions of Office et al. In general I have the impression that we have overestimated the quality of the public available beta versions.

    “I wonder if this situation is in any way related to this warning with respect to VSTO ‘SE’? Who knows…”

    In my opinion .NET platform including the tools do a lot of work ‘behind the scene’ which we not yet understand.

    In that way we are ‘back in the black box’… I sincerely hope that MSFT will produce a larger number of articles to support us.

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — November 8, 2006 @ 12:02 am

  3. “In order to create any VSTO solutions we need to have the Professional Edition of Office 2003 or later installed on both the development machine and on the targeting machines. ”

    Is this true? It won’t work with “Small Business Edition 2003” or “Standard Edition 2003”?

    Comment by Jeremy — November 8, 2006 @ 2:13 am

  4. Jeremy,
    Apparently we can also use the standalone versions of Excel 2003, Word 2003 and Outlook 2003 but not the versions You refer to.
    For more information please see the following article at MSDN:
    How to: Prepare End User Computers to Run Office Solutions
    Kind regards,
    Dennis

    Comment by Dennis Wallentin — November 8, 2006 @ 10:35 am

  5. Dennis,
    The list in that How-to is strange. I can’t really think of a reason why one version of office would work and another wouldn’t. Especially given that all of the stand alone versions work.

    We’re currently developing an Outlook Toolbar using VSTO SE and deploying to 10 machines. All machines have Office Professional, however I’m not sure they all have Office Primary Interop Assemblies. And I know they don’t have the VSTO run-times. Code Access Security was another problem.

    Luckily I found a great blog article with a great tutorial on how to solve these issues. It’s Outlook focused but should work for any version of office. Give it a read and let me know what you think.
    http://weblogs.asp.net/mnissen/articles/427504.aspx

    -Jeremy

    Comment by Jeremy — November 8, 2006 @ 7:15 pm

  6. Jeremy,
    Thanks for the link which I hope other also will find useful.
    “I’m not sure they all have Office Primary Interop Assemblies.”
    It’s rather easy to find out:
    If .NET Framework 1.1 or later was installed before the installation of the Office 2003 suite then the PIA are installed together with the Office tools.
    Here is a link to two good articles from MSFT about VSTO deployments(including how to handle PIAs and the VSTO Runtime):
    Deploying Visual Studio 2005 Tools for Office Solutions Using Windows Installer (Part 1 of 2)
    Deploying Visual Studio 2005 Tools for Office Solutions Using Windows Installer (Part 2 of 2)

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — November 8, 2006 @ 8:09 pm

  7. I think the Office version issue is around some of the XML components that are only installed with the pro version.
    And I think it was a licensing issue rather than MS being awkward, I’m sure I read/heard somewhere VSTO should work with all versions of 2007.
    cheers
    Simon

    Comment by Simon Murphy — November 9, 2006 @ 12:25 am

  8. Simon,

    “I’m sure I read/heard somewhere VSTO should work with all versions of 2007.”

    It looks like You’re right about that. At least according to the information given in the link to the VSTO 2005 SE.

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — November 9, 2006 @ 9:24 am

  9. > “The list in that How-to is strange. I can’t really think of a reason why one version of office would work and another wouldn’t. Especially given that all of the stand alone versions work.”

    Yeah, this is unusual. It could be to simply get users to “pay up” and upgrade, or there could be a technical reson for this due to some features not present in these versions actually being needed for VSTO to work.

    I actually think that VSTO has simply been “disabled”, and I’m guessing that it’s only the entrypoint that is disabled. Best is to make sure that your client has the correct Excel version and/or is willing to upgrade if one is making a VSTO solution. However, I’m guessing here that the “disabling” is simply that the lower versions of Excel simply do not check the Custom Document properties for the VSTO project path and so don’t launch the VSTO project. I don’t have a clue here, but it “feels” like this is what is going on…

    If this is the case, then it should be possible to rig an alternate entry mechansim to load the project. Because if you launch the VSTO project, it definately knows how to load the associated Workbook (provided the Workbook is in the folder location that it expects). So I’m not quite sure how one would go about trying this, but the goal would be to launch the VSTO project “from the other end”. From within VS/VSTO this is easy, of course, but at the client site, this is not possible. But Assembly.LoadFrom() could easily do the trick.

    The first step would be to attept to run a VSTO project from within VSTO on a sub-version of Excel that is not supposed to run. (Make sure you’ve made an image of your entire PC first though, LOL, and keep your fingers crossed…) If that runs, then all that would seem to be needed at the client-side would be a loader mechanism of sorts.

    On the other hand, these lesser Excel versions could actually lack some needed internals and all of this will fail. I just don’t know…

    Comment by Mike Rosenblum — November 9, 2006 @ 3:14 pm

  10. To clear up what I was trying to say in my last message:
    in Office 2003 I think:
    MS licenced some XML components off someone else, the agreement was for distribution with pro office only. VSTO for office 2003 used (/required) those components.
    VSTO for office 2007 does not use them, or MS rewrote them and include them in all versions. MS did not intend to force people to use pro versions and they recognise the problems that caused for developers, hence support in all versions (I think) in 2007.
    Its something like that, I can’t remember where I heard/read it or I would include a reference, sorry.
    cheers
    simon

    Comment by Simon Murphy — November 9, 2006 @ 9:07 pm

  11. Simon,
    Thanks for the clarification which also make sense to the situation with Office 2003.
    From a broader point of view I believe it’s important that all future versions of Office is included in the target group for VSTO.

    Jeremy,
    I’ve played around with the “Custom Prerequisites for Office” solution as well as with ‘the CAS installation’.
    They both work well and I wonder why MSFT so far not have been able to provide us with a similar wizard and solutions.
    At present I see no issues to apply it with the PIA for Office 2007 when they are available.

    Thanks and with kind regards,
    Dennis

    Comment by Dennis Wallentin — November 9, 2006 @ 9:54 pm

  12. I got curious about the difference between the VSTO supported versions of Office 2003 and not supported versions.
    According to the following article at MSFT:

    Information about designing Office XP add-ins and Office 2003 add-ins by using the .NET Framework

    “Microsoft Office Professional Edition 2003, Microsoft Office Word 2003, and Microsoft Office Excel 2003 include a loader that is designed specifically to load managed-code extensions, managed smart tag solutions, and managed smart document solutions.”

    Case closed 🙂
    Dennis

    Comment by Dennis Wallentin — November 10, 2006 @ 5:51 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: