Publishing VSTO 2005 SE addin to a network location

Rakesh Rathod

Hi,

I want to publish my Outlook add-in build using VSTO 2005 SE to a network location so that updates can be automatically pushed to all users later. The steps mentioned for this are as follows:

1. In Visual Studio, use the Publish Wizard to deploy your solution to a server.
2. Make changes to security policy so that each end user can run the solution.
3. Create the required registry entries on each client computer.
4. Copy the application manifest for the add-in to each client computer.

The publish wizard generates the application manifest and other output files.

But I'm not sure how to achieve the steps 2,3 and 4. Is there some some standard way which we should follow for changing the security policy, making the registry entry and copying the required files to the client machine. Can someone please throw some light on these points.

Thanks and Regards,

Rakesh

X4U

Hello Rakesh,

I can be wrong - but

as I know currently there is no click once support for VSTO Application AddIns.

But to answer the questions for Registry and Deployment.

You can use Active Directory and an OU (Organizational Unit) to deploy registry settings and software to users.

You can use a login script to copy files to the clients when the clients are startet or when the users log on to the domain.

I'm usualy would create a Setup-Application with the SetSecurity project and deploy this msi by Active-Directory or SMS Server to the Clients. From there you can also push a new Version.

The Security and the Registry is changed by the setup project.

Hope this helps,

greets, Helmut

Denis Pitcher

Rakesh,

I've achieved what you describe but it was tricky

First thing I recall is that if you publish to a network location there is an issue that if the network is unavailable when you load your application/addin, your addion is disabled. This is incredibly frustrating. What this means is that the files are not actually copied to your local machine and are run directly off the network which is not ideal for isntances where you want to work offline.

Here is what I did.

1. I created a setup project as normal. (This is how you take care of registry, security policy and inital setup of manifest and files)

2. I then created my own updater class that I call from the addin_startup which checks the local manifest file against the manifest file in the publish location (compare the versions).

3. If the version is newer, I use xDirectory (http://www.codeproject.com/cs/files/xdirectorycopy.asp) to copy the contents of the publish directory (based upon the version of course) into the local machine directory.

4. I wrote a small application that is launched by my addin which passes details such as the process id and file that is open

5. This app then stops the running process and restarts it with the file that was open

Rakesh Rathod

Hi Denis,

Thanks for the response. This seems to be a feasible solution. Just a few doubts, do you mean that the new application will kill all the instances of the host office application and then copy the required dlls. Also, will replacing the local copy with contents of the publish location activate the latest version or will we have to make some changes in the registry settings as well

Would be great if you can share some details of what you did in the application launched.

Thanks and Regards,

Rakesh

Denis Pitcher

Rakesh,

Because I specifically pass the process ID, it only killed the instance that was loaded, not all instances. It may be possible to do so if you can detect which ones are office instances.

As long as you inititally installed the addin using a setup project, you shouldn't have to change any registry settings if you overwrite the files in the install directory with those from the publish directory. VSTO loads addins based upon the details in the manifest, so as long as the manifest is correct (which it should be), it should load the latest version.

Denis

techno_adi

Hi Denis,
I have tried the approach you have mentioned here, but it does not allow me to copy the dll's to the installed directory. It says access/permission denied! Did you face a similar kind of issue
This is a add-in for Outllok and i am running a different console application for updating the dlls of the add-in

Now, when I try to do a File.Copy to the installed folder, it throws the exception.

I had installed the add-in using setup initially.
I kill the outlook process programatically before doing the File.Copy.
I checked to see the permissions of the file/folder and they are not "read-only".

Also, I am currently comaparing the dll files directly using the object of Assembly class. How do I compare the ".manifest" file. Is there a class in .net framework that does it

Any help on this would be of great help.

Thanks in advance!

Denis Pitcher

Hey techno_adi

Have you set up CASPOL (Code access security policy) to ensure that your application has access to read from the network share as well as write to the local directory

Because the .manifest files are xml based, the best means of comparison is using the XmlDocument class

Code Snippet

Dim remoteManifest As XmlDocument = New XmlDocument()

remoteManifest.Load( *** network share manifest location *** )

Dim remoteVersion As String

remoteVersion = remoteManifest.DocumentElement.SelectNodes("//@version").Item(0).InnerText

' load the version info from the local deployment manifest

Dim localManifest As XmlDocument = New XmlDocument()

localManifest.Load(AppDomain.CurrentDomain.BaseDirectory + _appName + ".dll.manifest")

Dim localVersion As String

localVersion = localManifest.DocumentElement.SelectNodes("//@version").Item(0).InnerText

' If the remote and local versions are not the same then modify the local

' manifest to force an update and reload excel.

Dim remoteVer() As String = remoteVersion.Split(".")

Dim localVer() As String = localVersion.Split(".")

_appUpdating = False

If Convert.ToInt32(remoteVer(0)) > Convert.ToInt32(localVer(0)) Then

_appUpdating = True

ElseIf Convert.ToInt32(remoteVer(1)) > Convert.ToInt32(localVer(1)) Then

_appUpdating = True

ElseIf Convert.ToInt32(remoteVer(2)) > Convert.ToInt32(localVer(2)) Then

_appUpdating = True

ElseIf Convert.ToInt32(remoteVer(3)) > Convert.ToInt32(localVer(3)) Then

_appUpdating = True

End If

If (_appUpdating) Then

' Set flag that application is being updated

localManifest.DocumentElement.SelectNodes("//@version").Item(0).InnerText = remoteVersion

localManifest.Save(AppDomain.CurrentDomain.BaseDirectory + _appName + ".dll.manifest")

Restart()

End If

It is important to compare each portion of the version info so you can put out major/minor releases.

Denis Pitcher

If you're unsure about CASPOL, check out the following resources.

The best is Mads' blog writeup & class

http://weblogs.asp.net/mnissen/articles/427490.aspx

Other useful CAS releated articles

http://blogs.msdn.com/chrsmith/default.aspx

In order to access the network share I had to add a vb script in my installer that runs caspol.exe from the command line. This sets up a basic url access group with full trust for my network location.

techno_adi

I have CASPOL in place. It's only after that, that i could see my installed add-in in the outlook.
Now the issue i am facing is during the simple dll copying from server to the client. To be more specific, I first copy the files to temp directory on the client machine and then follow to backup the original installed version of dlls before making a File.copy from the temp directory to the installed folder. Now, I am able to take the backup again to a temporary backup folder on client machine (for rollback, if need be), but when I try to copy the new version of dll from the temp folder to the installed directory using plain File.Copy command with overwrite option set to true, it throws an Access denied error on trying to copy!

I hope this makes the problem more clear

Denis Pitcher

Does it work when you copy directly to the installed folder

Have you setup CASPOL for the temp folder as well

techno_adi

Hi Denis,

I have tried giving FullTrust permission for the Temp folder and the updater exe but in vain. I have also tried adding it to the same permission group as my main add-in application and again the same results. The error still is Access Denied on the dll.

When I do a plain explorer copy-paste ( i.e. not programmatically), it copies perfectly and wrks with the updated version of Add-in.

Any pointers

Denis Pitcher

This doesn't sound like it's VSTO related. Have you tried creating a test app that only copies from the temp directory

By the sounds of it you're copying from the network to the local machine fine. What is the point of the temp directory Could you simply copy the files from the app directory to another one before updating the app

Denis

techno_adi

I think I found out the reason!
It was because of the Assembly that I was loading to check the version was directly from the installed folder. And inspite I making the object null, since Assembly doesnt implement IDisposable I couldn't dispose, the dll file somehow was still being referenced by the object!!

Now I make a copy of the installed dll and then get it's version to finally make a copy if there is a mismatch. This works fine.

Any method how I can cleanly remove the reference of this Assembly object, so that I do not need to make a copy of the dll

Denis Pitcher

Are you trying to check the versions of the assembly files directly

It is best to simply compare the versions in the .manifest files and update those accordingly when you copy.

techno_adi

Yes, I am doing it directly.
That was because, I couldn't find a direct way to access .manifest file except taking it to be a normal XML document and accessing it like wise.

But, probably I now feel to use it rather than accessing it directly!

Thanks Denis.

Also, do you know the way of disposing the Assembly class object, just for the knowledge sake of it