I created an add-in to be used on several (10-15) networked computers.
My plan was to just put the .xla file on the server and have each local
machine link to that add-in. That way, when I make changes, I don't
have to go copy them to everyone's local folders. This has worked
great for most machines, but there are a couple machines that insist on
copying the Add-In to the local AddIns or Documents & Settings folder.
They are running XP like the others, so I'm not sure why they are so
fussy. Is there a setting or something that I can change to prevent
this, or should I just bite thte bullet and copy the Add-In to
everyone's local machine, then overwrite them all whenever I make
changes? Thanks.

You are getting the default question that pops up on networked machines,
after you select the add-in in the browser. Just answer "No" so it
references the server file. This means it won't be added to the user's
Documents and Settings folder, which I assume is what you want.

I service this exact scenario from home via Remote Desktop, to a company
running add-ins on 12 machines. ...works great!

Regards,
GS

after you select the add-in in the browser. Just answer "No" so it
references the server file.

I have a little question you might be able to clarify for me.
When the .xla file resides on the server as you have described, it means you
can't update the .xla file until all users have closed Excel - is that right ?

Regards,
Vic Eldridge





"GS" wrote:

You are getting the default question that pops up on networked machines,
after you select the add-in in the browser. Just answer "No" so it
references the server file. This means it won't be added to the user's
Documents and Settings folder, which I assume is what you want.

I service this exact scenario from home via Remote Desktop, to a company
running add-ins on 12 machines. ...works great!

Regards,
GS

Hi Vic,

It depends on how it is used.

If it's opened like a workbook, then the file is in use and you won't be
able to overwrite it. It's treated like any other open file.

If the .xla is an Add-in, you can update the file anytime. The next time
someone opens it, they'll get the new version.

The difference here is whether or not it has been added to the AddIns
collection via the Add-ins Manager dialog (or some other means by which it
has been "registered" as an Add-in). This requires entries to be added to
the Registry via an installation utility or some such means. The Add-ins
Manager dialog does all this when you use this method.

One thing I find common with my clients/users is they seem to have
difficulty with manually installing .xla files via the Add-ins Manager.<??
So for local installs, I distribute my projects packaged in an install
utility that does all the Registry entries, installs the files, then opens
Excel with everything ready to go. It's a nice, clean way to handle it.

This doesn't handle shared add-ins on a network drive, but I've been
thinking of making an Add-in Installer that simply asks for a filename via
"GetOpenFilename" dialog or the like, where the user selects the .xla file
and it does everything else necessary, just as my install utility does. This
won't fix the problem of someone answering 'Yes" in the OP's scenario because
it would need to remove the file and registry entries for every user, on
every machine. This means that it's not available to any user but the one who
added it via Add-ins Manager. Answering "No" points it to the server location
instead of making a copy on the local machine.

I hope this is helpful!

Regards,
GS

Thanks for your reply GS.

I think I'm back on track now.
I had a situation where windows was telling me I couldn't overwrite the .xla
on the server because the file was in use. It led me to believe the file was
deemed "in use" whenever a user was running Excel with the addin installed.
I can't reproduce the situation now so I'm happy again !


Regards,
Vic Eldridge



"GS" wrote:

Hi Vic,

It depends on how it is used.

If it's opened like a workbook, then the file is in use and you won't be
able to overwrite it. It's treated like any other open file.

If the .xla is an Add-in, you can update the file anytime. The next time
someone opens it, they'll get the new version.

The difference here is whether or not it has been added to the AddIns
collection via the Add-ins Manager dialog (or some other means by which it
has been "registered" as an Add-in). This requires entries to be added to
the Registry via an installation utility or some such means. The Add-ins
Manager dialog does all this when you use this method.

One thing I find common with my clients/users is they seem to have
difficulty with manually installing .xla files via the Add-ins Manager.<??
So for local installs, I distribute my projects packaged in an install
utility that does all the Registry entries, installs the files, then opens
Excel with everything ready to go. It's a nice, clean way to handle it.

This doesn't handle shared add-ins on a network drive, but I've been
thinking of making an Add-in Installer that simply asks for a filename via
"GetOpenFilename" dialog or the like, where the user selects the .xla file
and it does everything else necessary, just as my install utility does. This
won't fix the problem of someone answering 'Yes" in the OP's scenario because
it would need to remove the file and registry entries for every user, on
every machine. This means that it's not available to any user but the one who
added it via Add-ins Manager. Answering "No" points it to the server location
instead of making a copy on the local machine.

I hope this is helpful!

Regards,
GS

Hi Vic,

I'm glad I could help!
As I said, it depends how the file is opened. There's nothing to prevent
users from opening an .xla as a workbook. This will cause it to be treated as
any other open file, regardless of whether its "IsAddin" is set to TRUE or
FALSE. Thus, if you see the warning message again, you'll know someone's
opened it that way.

It might help if I clarify what's happening he
Excel handles Add-ins via the Add-ins Manager. This works similar to how
..xlt's are handled when the Add-in is opened. The original file is not "in
use" so you can modify it however you want while it's open, just as you can a
..xlt file while the 'copy' is open.

For example, say you're using a sheet or book created from a template and
find you need to change the template. You can open it, modify it, save it,
and close it without any objections from Excel or Windows. The same holds
true for add-ins, but not if they're opened like a workbook. Opening an
add-in like a workbook is like having the .xlt file open. You can't open a
second instance of any file in Excel, so this applies to add-ins. To modify
an add-in, you need access to its instance via the VBE. Saving it overwrites
the original file, but it's not held "in use" afterward. (-Obviously, you
can't access it while it's being overwritten)

If your user opened it like a workbook, you can't open it that way without
getting the "in use, read only" message. (-just another confirmation of how
people might be using the file)

I avoid all this nonsense by using a "frontloader" add-in that places a
menuitem on the Excel menubar, for the user to open and close the add-in.
This way I can deal with version checks, registration and licensing, trial
version validation, and et cedera before the add-in even starts. But the main
advantage is to provide the use with correct access to the add-in via a mouse
click. You can even hide it in the normal Open dialog if you give it a
non-Excel file extension. Of course, it can be found by changing the 'Show
Files of Type' to "All Files...", but most average users wouldn't think that
it doesn't have an Excel file extension.

Regards,
GS