vsto auto update security

R

RoyalHale

I have created an Outlook 2003 add-in using VS 2005 pro with the VSTO second
edition. I have been able to get the add-in to work fine with the standard
cas policies being set etc. I tried setting up the install to look to a
website for auto updates. I publish the app and added the manifest file to
the install and removed filtered out the default manifest. When trying to
install the app now, it won't install. I read that I may have to add code to
create a cas policy for the url as well as the app. Is there any sample code
for doing this or is this even the problem
 
K

Ken Slovak - [MVP - Outlook]

Is the update stuff handled by a different assembly than the one you've
already granted trust to? That would require adding trust for that assembly
also, assemblies called by trusted assemblies aren't themselves trusted
automatically.

If that's not the case then please describe more fully what you're doing and
how.
 
R

RoyalHale

I am assuming it is the same assembly. I compiled the add-in and then
published it to the server. I followed the sample from this site:
http://www.codeproject.com/useritem...umid=363960&select=1878913&df=100&msg=1878913.

I figured out how to add a cas policy for the url but that didn't seem to
help.
--
Thanks
Royal


Ken Slovak - said:
Is the update stuff handled by a different assembly than the one you've
already granted trust to? That would require adding trust for that assembly
also, assemblies called by trusted assemblies aren't themselves trusted
automatically.

If that's not the case then please describe more fully what you're doing and
how.
 
K

Ken Slovak - [MVP - Outlook]

Well, without knowing if that code is in a separate assembly or knowing
exactly what you're doing that's the best answer I can give.

Are you compiling the code that calls for the update as a separate DLL you
are calling or is the code part of your main assembly?

What code are you using to check for the updates?

What do you mean "it won't install"?
 
R

RoyalHale

The way I understand this is that [assemblyname].dll.manifest which is
created by the publish wizard does the checking for the updates. That is why
I replace the manifest that the primaryoutput creates with this one. It is
placed in the same folder as the installed assembly and the whole folder has
fulltrust.
Does running build on the setup project which builds the assembly again
change something
As far as I know, the assembly published is the same assembly that gets
installed on the client machine. The add-in is not installed from the web but
by a local copy of the install program.
The only thing that changes is the manifest I am using for the install.

By won't install I actually mean the add-in gets installed but cannot load.
If i look in the COM add-ins folder, I see the standard runtime error.
--
Thanks
Royal


Ken Slovak - said:
Well, without knowing if that code is in a separate assembly or knowing
exactly what you're doing that's the best answer I can give.

Are you compiling the code that calls for the update as a separate DLL you
are calling or is the code part of your main assembly?

What code are you using to check for the updates?

What do you mean "it won't install"?
 
K

Ken Slovak - [MVP - Outlook]

I'm not positive that's the problem, try the code without that custom
manifest file and see what happens. There are other ways to check for
updates, like downloading a versions xml file and checking for the latest
version available.
 
R

RoyalHale

If I remove the custom manifest the add-in loads and works fine but the
autoupdate isn't available. The article I referred to earlier is the only one
that explains how to get the auto update to work on a vsto add-in.
Any other samples of how to do this would be appreciated.
--
Thanks for the input so far
Royal


Ken Slovak - said:
I'm not positive that's the problem, try the code without that custom
manifest file and see what happens. There are other ways to check for
updates, like downloading a versions xml file and checking for the latest
version available.




RoyalHale said:
The way I understand this is that [assemblyname].dll.manifest which is
created by the publish wizard does the checking for the updates. That is
why
I replace the manifest that the primaryoutput creates with this one. It is
placed in the same folder as the installed assembly and the whole folder
has
fulltrust.
Does running build on the setup project which builds the assembly again
change something
As far as I know, the assembly published is the same assembly that gets
installed on the client machine. The add-in is not installed from the web
but
by a local copy of the install program.
The only thing that changes is the manifest I am using for the install.

By won't install I actually mean the add-in gets installed but cannot
load.
If i look in the COM add-ins folder, I see the standard runtime error.
 
K

Ken Slovak - [MVP - Outlook]

I haven't seen any other examples. I use SetSecurity but I never mess with
the manifest file. The custom actions I use also include a Rollback action
as described in the VSTO walkthroughs at
http://msdn2.microsoft.com/en-us/library/aa537173(office.11).aspx

My own addins use a different method for finding updates, but the update
process isn't fully automatic and the method is more like the one I
described before.
 
R

RoyalHale

Thanks for the input. Just one more thing I thought of is does the auto
update only work for add-ins installed on Office 2003 pro. We are using
Office 2003 standard?

--
Thanks
Royal


Ken Slovak - said:
I haven't seen any other examples. I use SetSecurity but I never mess with
the manifest file. The custom actions I use also include a Rollback action
as described in the VSTO walkthroughs at
http://msdn2.microsoft.com/en-us/library/aa537173(office.11).aspx

My own addins use a different method for finding updates, but the update
process isn't fully automatic and the method is more like the one I
described before.
 
K

Ken Slovak - [MVP - Outlook]

Forget using VSTO then. VSO requires Office 2003 Professional or higher.

Office 2007 supports VSTO in all SKU's.
 
R

RoyalHale

I actually developed the add-in using Outlook 2003 standard and all went well
till I tried using the autoupdate functionality. Guess I'll be happy the
thing works at all.
Thanks again for your advice.
--
Thanks
Royal


Ken Slovak - said:
Forget using VSTO then. VSO requires Office 2003 Professional or higher.

Office 2007 supports VSTO in all SKU's.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top