VSTO Add-In Deployment - CAS

 Hello once again.  It seems that every step of the development cycle of my project ends up as a post here ;)

I'm at the distribution part of the development of my code.  I have debugged and tested on my development machine and I am satisfied that there are no bugs preventing me from releasing a 'beta' version for testing among colleagues.  However, I can't deploy it!

The code will (is supposed to) be deployed as a COM add-in for Excel 2003 on WinXP.  I have followed the walkthroughs at MSDN Part 1 and Part 2, however I kept coming up with the error "Cannot set the security policy --> Cannot create the security code group 'MyProject'. --> The system cannot find the file specified. (Exception from HRESULT: 0x80070002)"

I have tried to remedy this a number of ways:

1. Steve Hansen's VSTO deployment model
2. Modifying the model in MSDN Part 1 using looping as shown on MSDN Forums.

With Steve Hansen's model, I can install the COM add-in, but then I run into the "Not a valid Office add-in" error when I try to install the add-in from Excel 2003.  During installation, the vstor.exe and Office 2003 PIA both install, and the install wizard tells me it has completed successfully.

Can anyone point me in the right direction to resolve this?  I am developing in VS2005 Pro with VSTO 2005 SE.

Thanks in advance for your time.

Matthew

Hi Matthew,

It appears to me that You have done it correctly, based on the sources You refer to. However, I suspect that there is a typo of the DLL name. Please check it and let us know the outcome.

 Hello Dennis,

The DLL name is correct ('MARS.dll').  After my initial post in this thread, I included the dependency to Microsoft.Office.Interop.Excel.dll I was able to install and run the solution on my development machine.  I have still not been able to run it on client machines.

Using the Microsoft .NET Framework 2.0 Configuration, I was able to determine that the full trust has been granted to the assembly after installation, so the CAS problem seems to have been overcome using the 'SetSecurity' project indicated in Parts 1 and 2 in my original post.  This goes for the development and client machines.

On the client machine I am now back to the error "MARS.dll is not a valid Office Add-in."

I have manually uninstalled both the vstor and Visual C++ Redistributable packages from the client machine, and the setup for my solution detects their absence and re-installs both of these, so the setup seems to be working in this regard.

After the minor success of including the Microsoft.Office.Interop.Excel.dll dependency, I re-included all the other dependencies in the setup project, however this does not solve the issue on the client machine.

The client machine is Windows XP running all critical updates, so I am fairly certain there is no issue with .NET.

My CustomActionData for the SetSecurity Custom Install Action is (all as one string - separated here for clarity):

 /assemblyName="MARS.dll"
/targetDir="[TARGETDIR]\"
/solutionCodeGroupName="IMO.MARS"
/solutionCodeGroupDescription="Code Group for MARS"
/assemblyCodeGroupName="MARS"
/assemblyCodeGroupDescription="Code Group for MARS"
/allUsers=[ALLUSERS]

As I mentioned above, the .NET Framework 2.0 Configuration shows that this grants full trust to the appropriate location.

One thing I did notice between the development machine and the client machine is that on the development machine, the add-in location is not the installed location.  The installed location is:

C:\Program Files\Common Files\Microsoft Shared\VSTO\8.0\AddinLoader.dll

Instead of the expected:

C:\Program Files\MARS\MARS.dll

Is this normal (if there is such a thing as normal here) behaviour? 

Matthew,

It looks like You got it right with the setup.

I'm not sure what You mean with the last part of Your comment.  You point to the VSTO Loader DLL in one location and also refer to the location of the custom DLL.

In general, the VSTO Loader file should never be added to a setup project and never be copied to the same location as the Custom DLL. If it's missing then install it separately and before installing Your solution. 

As for normal behaviour I never relate it to computers or computer work

 Matthew,

I re-read Your post about getting the error "...is a not a valid office add-in". If I remember it right it may be caused if we initially installed the add-in for the current user and later for all users.

The settings in the HKLM part of the Windows Registry is not read when we opening the COM add-in Windows in Excel while it does it for settings in the HKCU. So if we switch installation from current user to all users and where not all settings are removed in Windows Registry this message can appear. 

If this is the case then You need to remove all settings in the HKCU and then re-install the add-in.

 Dennis,

I removed all settings in HKCU and re-installed, but received the same error.

I have spend the last day downloading the VS2008 trial version and installing this (removing VS2005) and updating my system (and project!) to run in this development environment.  I am going to test whether there was a problem with my Visual Studio installation and see if I can resolve the problem this way.

I am developing in two different environments:

1. Notebook running Vista Ultimate, VS2008 (previously VS2005) and Office 2007.
2. Windows XP, VS2005 and Office 2003 (running as a virtual machine on my notebook with Vista as the host system).

I'll update this thread once I have tried to deploy from the VS2008 environment.  As I posted here in a different thread, I had some strange behaviour during development.  It may be that there are further issues with my installation that are causing the deployment problems.

Once again, thanks for your time in helping me work through this.

 Dennis,

Success - of sorts.

After downloading VS2008 and installing (as well as Vista SP1) I was able to deploy my add-in using Steve Hansen's deployment model.  The MSDN walkthroughs (Part 1 and Part 2) still wouldn't work for me.  Any ideas why this would be the case?

VS2008 required some changes to the code from VS2005 in order to work, but I was quite happy to do this to produce an installer for my add-in that now works.

I am beginning to suspect that there was a flaw in my original installation of VS2005 that caused my problem.  Uninstalling VS2005 and installing VS2008 has resulted in a solution that works, but I am still wary.  Perhaps rebuilding my development machine is required to fully resolve this issue.

Thanks once again for assisting me in resolving my issue. 

Matthew,

Great You got it to work so far

I notice that You use Vista while You are targeting the XP version, Make sure that the solution is tested with XP before going into production,

I'm not familiar with Hansen's video but I will take a closer look into it.

 Dennis,

A quick update with this thread.

I installed VS2008 on my development machine running Vista and Office 2007.  When trying to deploy the VSTO add-in for Office 2003, I continually received the error "not a valid office add-in."  Without changing any code or setup options, I deployed the same solution using VS2005 on Windows XP and the add-in worked without a problem.

It seems that even though Office 2003 has been selected as the VSTO add-in, the version of Office installed on the development machine influences the dependencies.  As a highlight of this issue, Excel interop for Office 12 added instead of Office 11.  This appears to be significant when attempting to deploy the solution!  I haven't tried to deploy from a Vista environment with Office 2003 as yet, but will look into this in the coming weeks.

I hope this saves someone (anyone) hours of trauma trying to resolve the issue.

Matthew, 

First of all, thanks for coming back to us with an update

Since we cannot have (and should not have) several Office versions installed on the development machine VS 2008 can only references the present version of Office. So when the VSTO project is opened VS IDE sets the reference to Excel 2007 (12.0) PIA. Next, the VSTO solution runs against the version of the VSTO runtime that it was built against, regardless of the version of Office that is hosting it.  So when developing with Office 2007 while targeting Office 2003 will only give us problems (and grey hair).

As a general thumb rule, we must have, on the development machine, the same Office version as the targeting clients use. 

Targeting Windows Vista is all about User Access Control (UAC). If this is turned off then it should not be an issue to deploy the VSTO solution on Vista configurations. If it's in use then You can use the Orca Tool to make the VSTO solution UAC compliant (which I wrote a blogpost for a while ago, UAC Compliant) It should also be noted that to install on Vista it requires adminstrative rights and finally don't consider to write to files inside the Program Files section as that's totally forbidden.

Based on my own 'trial and (t)error' I use the following configurations:

Windows XP / VS 2005 / Office 2003

Windows Vista / VS 2008 / Office 2007.

I'm the first to really regret the mess, in particular when it comes to VSTO.

 Dennis,

Thanks for the information.  Perhaps I have been a little too enthusiastic about charging ahead with VSTO - hence running into problems that some people who were more prepared avoided

The configuration you are running mirrors what I also arrived at.  The 'trial and (t)error' approach certainly reinforces the lessons learned, however, and the grey hair is more advanced - along with my VSTO skills

I'm sure there will be more silly questions as I blunder my way through the transition to VSTO, but so far I am pleased with the results.

Once again, thanks for the assistance.

Matthew,

Managing to create VSTO solutions that actually runs on the targeting computers, which You've done is good. The experience You've got now will be rewarded when You ship future solutions In other words, You've done a good job so far.

Just for the record, which I guess You also have already figured out, when using Office 2007 the targeting machines must have version 3.5 (and later) of the .NET Framework.

BTW, check out the toolkit, Microsoft Visual Studio Tools for the Office System Power Tools v1.0, which is available for download here It can help You out to make sure that the targeting machines have all the prerequisities.

My experiences of Excel & .NET/VSTO will hopefully be available in a printed source next year. Meanwhile I will continue to lurk around this forum.