Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
DiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWord
DirectoryUser Groups
Related Topics
Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ...

MS Office Forum / Excel / Programming / February 2006

Tip: Looking for answers? Try searching our database.

sharing Add-In on a network

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
bodhi2.71828@gmail.com - 22 Feb 2006 14:02 GMT
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.
GS - 23 Feb 2006 01:18 GMT
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
Vic Eldridge - 23 Feb 2006 04:26 GMT
> 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

> 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
[quoted text clipped - 6 lines]
> Regards,
> GS
GS - 23 Feb 2006 16:45 GMT
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
Vic Eldridge - 24 Feb 2006 06:51 GMT
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

> Hi Vic,
>
[quoted text clipped - 32 lines]
> Regards,
> GS
GS - 24 Feb 2006 16:08 GMT
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 here:
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
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.