Hello,

I've been playing with my VSTO 2005 SE Outlook addin under Vista RC2 using Office 2007 B2TR and the VSTO 2005 SE beta loader (I also run around a lot with scissors)

My first issue has been with the installer. I get a 'Error: 2869' that requires my users to go and either turn off UAC (can you imagine!) or run the MSI with 'Run as Administrator'. Obviously I don't like this and would feel bad for lots of good reasons.

What seems to fail is some custom action [RunInstaller] code that allocates the .NET Security Policy around my wee Add-in assembly. This code seems to work fine under XP before.

I had a look at how the VSTO Team recommends doing it and saw the tutorial/examples of SetSecurity/CaspolSecurityPolicyCreator.

It looks like that code seems to build a command line to shell out a Caspol.exe call and update the policy level like that. My code (that doesnt work under Vista) actually uses the 'code way', i.e. some 'machinePolicyLevel.RootCodeGroup.AddChild(codeGroup);' style calls.

So my question is (finally, he has a question..) was the VSTO example done like that on purpose, because it works under Vista or was it just 'one of those' things and nothing to do with my VSTO installer error?

Thanks for any help.

I updated the installer to use the 'call Caspol.exe with cmd line arguments' way, to add the code group etc.

I get the following exception under UAC on Vista RC2 when calling SetSecurity / RunCaspolCommand():

"ERROR: Runtime error: Access Denied. You might not have adminstrative credentials to perform this task. Contact your system adminstrator for assistance."

Sigh.

If I run a command shell as Adminstrator and run the same caspol commands then it works fine.

I thought that UAC flashing up the 'Do you want to RUN SOMETHING!!!! DANGER!!' when the initial .MSI was clicked would elevate already? How else can I request programatic access to CAS policy?

VSTO Team: What is the recommended way of allocating a security policy for a VSTO addin under Vista?

David,

Modifying CAS is an action that might have serious security implications if the program that is attempting to modify the CAS is not well-written/is coming from a malicious user. So, no wonder Vista requires you to be an admin to run such command.

Can you tell me more about what you are doing? It sounds to me that you are going through the deployment article by Darryn and Lubo and when you are trying to deploy the add-in - it is giving you the grief. Is my understanding correct?

The basic problem seems to be that the deployment article on how to modify CAS for an Office add-in does not work under Vista.

My overall objective is to get my add-in to install and run under Vista.

To do this I need the installer has a custom action to modify CAS. While this previously worked under XP/2003, it no longer seems to work under Vista.

Misha - (thanks for the reply) Does this tutorial fail the same way for you in Vista? How do you build installers that work under Vista for VSTO and CAS modification?

David,

Yes, this article has not been updated for Vista (yet). We are aware of the issues, now it is just the matter of getting the time to fix the deployment article.

Installing Add-ins is an admin's task and needs to run in the Elevated mode.

On Vista an EXE that requires executing in Elevated mode should contain a manifst that basically requires a user permission to run in elevated mode. See details here: http://msdn.microsoft.com/windowsvista/reference/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp
The relevant topic is called:
Marking Applications on Windows Vista Using Manifests

Thank you Misha - I'll take a good read.

One thing that initially looks tricky would be to make sure my add-in and the custom installer actions are split into different assemblies. I only want to elevate the installer actions for the CAS change, not on my main add-in that runs with Outlook. Before I had used a [RuntInstaller(true)] attribute and had both classes in the same assembly.

Also, I guess the .MSI runs the custom installer assembly and picks up the .manifest to elevate for that? I read in the above link that '3rd party' packages allow you to insert manifest info for .NET apps into the PE image. Do you know if I have to do that, or will a 'myAddinInstaller.dll.manifest' be good enough to work?

I think MSIs on Vista should run elevated by default.

It doesn't look like that is the case, as in a regular setup project I get out of VS2005 doesn't have the UAC 'shield' icon, nor the menu action to 'Run as Adminstrator'.

I noticed that the VSTO2005 SE Runtime has one though - maybe it's something I have to set as part of the VS2005 MSI properties?

The workaround is to create a .cmd file (!) with something like "msiexec.exe /i myaddin.msi" and then use 'Run As Adminstrator' on that - but it's hardly a nice thing for an end customer to have to do...

As a follow up, in case it helps anyone, the sample can be updated in the following way to be slightly more UAC Vista friendly.

(1) In the caspol shell calls set the ProcessInfo.Verb = "runas". This will force a UAC challenge and elevate the command shell, and the caspol.exe that runs within it.

(2) set the ProcessInfo.UseShellExecute = true. You have to strip off the RedirectStandardIO stuff that currently checks the output text, but it's probably better just to run another caspol call to see if you group exists anyway and just rely on process.ExitCode.

I don't know if this is a good way, I suspect not, but it's as far as I got.

It would seem like editing the MSI's manifest to include the elevation request (plus shield icon resource) is the way to go, but there isn't much info I could find on doing this in plain Setup/Deployment poor .NET projects.

Oops. I figured it all out.

Misha, you were 99% correct. In Vista the setup.exe bootstrap for the .MSI is elevated by default, and as that's the thing that launches the new process then everything works out fine.

Unfortunately, because I was used to just starting my .MSI directly, I missed all this - the trick is under Vista to always use the setup.exe to launch your install and not the MSI.

The one happy ending was at least I learnt alot about UAC and Vista... ;-)

It's comforting to be 99% correct :)

Glad you figured it out.