views:

342

answers:

5

I have an Excel 2003 add-in deployed in one of our departments that occasionally needs updated. What currently happens is that I publish the new version from my machine to a central location, this updates a version number stored in a database that the add-in checks each time any of the modules within it are run, and if a newer version number is found then the add-in halts with a message informing the user that they need to update the add-in.

This currently involves them running another workbook with a workbook_open event that changes the add-in.

What I'd like to have is the add-in detect that a newer version is available and silently install it before carrying on with the user's operation. The problem is that this fails on the first step of uninstalling the existing version because any code in the add-in immediately finishes when the add-in in uninstalled.

I would create some code in the user's personal.xls on-the-fly to handle the changeover but I am unable to set the 'Trust access to Visual basic project' flag in the users' machines so can't have replicating code in the add-in.

The only way I can see from here is to have two add-ins, one that handles the updates and one that actually does the work. The problem comes when I inevitably have to update the update add-in!

Can anyone else suggest a better solution? This must be 100% Excel, no VSTO etc.

A: 

One way I achieved something similar, albeit, a while ago is as follows:

Provide a button called Update on a common page (may be a common file, if you are using many) and when users click that, it opens a xls in a network location and copies the code from that file to the local file and closes the newly opened files.

That way, whenever I had an update, I would send an email asking them to update code locally.

It worked as I had few users and updates were fairly few in number. If you want an auto update, what prevents you from checking the version number during each and every opening of the file.

Lakshman Prasad
Yes, this was along the lines of me providing two add-ins; one resident to provide a menu item to handle the updates and an updateable one that does the grunt work.Unfortunately the users in question don't use any common workbooks, other than the raw CSVs that our production DB spits out that the add-in then processes.I already check for an update and flag the user very time an action is called via the add-in.
Lunatik
A: 

Using out of the box ClickOnce deployment, the add-in version is checked whenever the app using it (Excel) starts. Not sure if you can deploy non-managed code in this way.

geejay
That's part of VS2005/2008, not in the Excel VBE.
Lunatik
+1  A: 

It was nice of Dick Kusleika to blog about managing add-ins today!

http://www.dailydoseofexcel.com/archives/2009/07/29/conditionally-load-excel-add-ins/

Some good suggestions that can be applied to my situation there.

Lunatik
Yes, very timely. I almost asked here instead of blogging. :)
Dick Kusleika
A: 

I tried something different, step as following: 1. write an addin and put it on shared drive space 2. add the project to VBA references 3. your functions and macros used in excel sheets add as references to addins every time excel sheet loads, new addin and references refreshes.

i chabge the solution to update button, because of problems when network is not online.

krzysztof
+1  A: 

We use a separate addin as a bootstrapper.

  1. The main addin can update the bootstrapper
  2. If the main addin needs an update, it loads the bootstapper, then uses an OnTime call to schedule a call to the bootstrap routine in the bootstrap and immediately unloads itself.
  3. The ontime call executes.
  4. bootstrapper loads main addin, relaunches main addin, unloads itself.

Complicated, but it works.