VSTO & .NET & Excel

July 31, 2008

VS 2008, COM Add-ins and launch conditions

Filed under: COM Add-ins — Dennis M Wallentin @ 11:49 am

I can create COM add-ins based on the Shared Add-in template in VS 2008 and they all work well on my developing computer. However, I got an issue when I tried to deploy them on configurations where only .NET Framework 2.0 is installed.

In the New Project dialog we can select the targeting .NET Framework version, 2.0 or 3.0 or 3.5. Since I needed to get the COM add-ins to work with version 2.0 I selected that version and then continued to work with the add-ins.

To test that they work with the targeting .NET Framework version I deployed them on configurations with Windows XP SP-3 where only version 2.0 of .NET Framework was installed. I also tried to deploy them on a Windows Vista SP-1 configuration with .NET Framework 3.0 but I got the same outcome as with Windows XP.

The outcome was the following:

 

I was rather surprised by this message so I started to try to locate the source but first I couldn’t find any errors at all. Finally I took a closer look on the setup packages. There I found out that it exist a launch condition for every setup. It’s not possible to remove it so what we can do is to change its condition.

The following screen shot shows the default setting (despite the fact that .NET Framework 2.0 was explicit selected in the first place). In the left window we can see the launch condition and in the right window its present setting of the property Version:

This was easily to change as the following screen shot shows: 

I then compiled the setup packages again and deployed them. This time everything worked as expected on all platforms.

Hopefully this can be useful for other developers. I hope that the upcoming SP-1 for VS 2008 will include a fix for it.

Kind regards,
Dennis

Advertisements

22 Comments »

  1. Wow, great detective work Dennis. This must have been very frustrating to track down…

    This would seem to be an oversight of some sort, hopefully this is something that will get fixed in a future version to make it easier for us… but the correction you outline is really very easy — once you know what to look for!

    Mike

    Comment by Mike Rosenblum — August 2, 2008 @ 5:56 pm

  2. Hey Mike 🙂

    Thanks for Your kind comments. I haven’t test the present SP-1 beta but I also hope that MSFT will fix the prerequisites settings as well. As it is now we need to also manually select the targeting .NET Framework version.

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — August 3, 2008 @ 11:37 am

  3. Hi Dennis,
    Another thing to keep in mind when using vs to build managed com addins?!?!?!. I’ve all but given up with them, the CAS was the last straw for me.
    Good work all agaian, and thanks for sharing, nice to know that you’ve been there and done it – so to spk.

    Hope you well mate
    Cheers
    Ross

    Comment by Ross — August 8, 2008 @ 2:32 pm

  4. Ross,

    Well, I believe the keyword here is patience. We need to give MSFT some time to sort things out so to speak 😉

    What worries me is that managed COM add-ins based on the Shared add-in template may have less attention then VSTO as MSFT.

    CAS is CAS and I guess we will have to wait for x version before
    we can set up the security in a smooth way.

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — August 8, 2008 @ 2:58 pm

  5. I’m not sure I understand the issue with CAS? If you design your add-in with full trust, then all should be fine, right?

    Could you even make a partial-trust add-in anyway, since Excel itself, is running in COM and therefore in unmanaged, full trust.

    Or am I missing something?

    Mike

    Comment by Mike Rosenblum — August 8, 2008 @ 8:54 pm

  6. Mike,

    CAS refers to VSTO solutions and not, as You correctly point out, to COM add-ins based on the Shared add-in template.

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — August 9, 2008 @ 4:33 pm

  7. Hmmm, yes, I have too little experience with VSTO or deployment in general to comment on that. So I “trust” you guys! (lol)

    Maybe some day I’ll know enough so that I could comment more…

    Comment by Mike Rosenblum — August 9, 2008 @ 5:47 pm

  8. Mike,

    🙂

    Trust or not trust, I hope I will have the time next year to write some articles about VSTO. With the latest version MSFT has really improved it so it’s just fair to review the present standard.

    BTW, if You decide to explore VSTO then go only with the latest version 🙂

    All the best,
    Dennis

    Comment by Dennis Wallentin — August 9, 2008 @ 5:59 pm

  9. Yes, I will have to investigate VSTO further at some point.

    I LOVE the drag-and-drop Ribbon controls capability in the 2008 version. I really look forward to making use of it at some point! But I’m still a Managed COM Add-in guy, so far…

    Comment by Mike Rosenblum — August 13, 2008 @ 8:20 pm

  10. ….I WAS talking about Managed Com Addins!!! I wrote one that would work fine on the dev PC, but not install/work (can’t quite remeber now) on the target. I thought that it was due to CAS issuse/rights on the target PC, but maybe I just set it up wrong? I might have some free time come the end of september, if i feel the urge i will dig it out again – and take a look re Mike suggestions -thanks! 🙂

    I think that VSTO might be the way to go if the target version of Excel is 12 +, then unmanaged com up to 11? VSTO seems a nicer place (less hassle?) to be for a office addin dev?

    Comment by Ross — August 14, 2008 @ 12:57 pm

  11. Hi Guys,

    Creating managed COM Add-ins with VSTO 3.0 is very nice for Excel 2007 🙂

    Since MSFT have put so much efforts in VSTO compared with the Shared Add-in template I cannot see why we should use the later for Excel 2007.

    For solutions that targeting several versions of Excel I can only see the unmanaged code approach to be valid.

    In view of the above it seems that creating managed COM add-ins with the Shared Add-in template is not attractive:

    * We cannot target, let say, Excel 2003 and Excel 2007 with one solution. At least, that’s my findings so far.
    * It does not offer the same developer friendly utilities as VSTO does.

    Ross, does the security issue refer to a managed COM add-in created with VSTO or with the Shared Add-in template?

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — August 14, 2008 @ 1:15 pm

  12. It sounds like Ross was using the Shared Add-in Template, a straight managed COM add-in (I’m guessing un-shimmed).

    I don’t have much experience with deployment setup projects though, so I can’t know what went wrong.

    I would try deploying something simple, maybe even a .NET EXE using a setup project and see if that can deploy. If not, then the issue is fundamental to the .NET installation itself. If this deploys fine, but an Excel managed COM add-in does not, then there is something specific to the Excel installation…

    Comment by Mike Rosenblum — August 14, 2008 @ 3:17 pm

  13. Yeah it was a managed com add in using the Shared Add in Template, in VS2005, with the up KB update. I think I tried shimmed and un-shimmed versions, neither would work.
    It would not work on many different PC’s, so I think it is the addin itself that is at fault.
    It installs ok but does not load into excel. In the Com-Addin manager, it has a strange name “MIEColourCommander. ConnectFriendlyName” , which I would have expected just to be “MIEColourCommander”, and the error is something like: “Not loaded, Run time error during loading”

    If I get a bit of time I will try and dig it out and take a look. I can’t remember too much about it now, but I do know that I thought it was something to do with the CAS – I might have just missed the Full Trust bit though – wish I had a copy of the dam thing at work so I could go and take at look now!!!!!

    Cheers
    Ross

    Comment by Ross — August 15, 2008 @ 10:42 am

  14. Ross,

    Silent shutdown of add-ins that don’t work is quite common, i e change the load setting from 3 to 2.

    I find it difficult to track down the causes of this behavior but for Excel it’s a safe operation.

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — August 15, 2008 @ 11:05 am

  15. Hi Dennis,
    Yes, I agree it is hard to track down!!!;-) I think it’s not the addin code, as it where, beacuse it runs ok on the dev PC, it’s just when I try to run it on other PCs, I think it’s something to do with the security, I will have to dig it out and have another look!

    Cheers
    Ross

    Comment by Ross — August 20, 2008 @ 10:56 am

  16. Having trouble to install a COM add-in on other PCs aswell =/ Not sure if I’m doing something wrong…The addin itself is working fine on the dev PC

    Comment by Joe — August 26, 2008 @ 2:22 pm

  17. Joe,

    What kind of error message do You get?

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — August 31, 2008 @ 1:16 pm

  18. Dennis,
    thanks a million for this post, which saved me hours of grief!
    Mathias

    Comment by Mathias — October 26, 2008 @ 8:14 pm

  19. Mathias,

    You’re welcome and it’s great that we can help each out with VS and VSTO.

    Kind regards,
    Dennis

    Comment by Dennis Wallentin — October 26, 2008 @ 8:49 pm

  20. Dennis –

    Your post just solved my issue after I spent almost two days trying to track this down. I had an old build / setup that worked – I had created a new build from scratch after a machine failure and partial restore… Was driving me crazy….

    Again – thanks…

    Butch

    Comment by Harold Gray — March 25, 2010 @ 10:02 pm

    • Harold,

      You’re welcome and I’m glad You got it sorted out.

      Kind regards,
      Dennis

      Comment by Dennis Wallentin — March 26, 2010 @ 2:35 am

  21. Hi all,

    I have some issue related to this post, so here I am.

    I try to build a very simple 2007 Excel Workbook project (message box opens when the workbook is saved), with target to framework .Net 2.0. I need this for deployement purposes.

    Compiling in the .Net 3.5 works perfectly fine, but in the .Net 2.0 I get the following error:
    “EntryPoint not specified for manifest” (MSBuild error MSB3195). I have removed all the references to System.Linq and System.Data.DataSetExtensions which does not seem to be supported in .Net 2.0

    Does anyone has an idea of how to compile successfully under VS2008?

    Thanks a lot in advance for your help…

    Stephanie

    Comment by Stephanie — July 20, 2011 @ 11:44 am


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: