My team and I share this workbook on a network drive. This workbook utilizes a few custom add-ins necessary for some custom functionality. These add-ins get automatically installed by custom VBA code I have added without any action on the part of the user. It seems that only I can use the add-ins - other team members have problems trying to load the add-ins, they get this error:
Run-time error 1004 Unable to copy add-in to library.
The error occurs when trying to run
Application.AddIns.add(<addin_name>)
The add-ins are located only on the Windows network share. I've written the code to ignore the prompt for copying the add-in to addins folder on local drive, because I don't want this to happen. This is a very annoying problem because I cannot debug it fully myself, I need the cooperation of my team members which is limited. Help greatly appreciated, thanks.
I would suggest just opening the XLA read-only from the network drive as if it was a workbook (which of course it is) rather than using Addins.Add - opening an XLA makes it available to the Excel session so it will function as an addin without being in the addins collection.
Related
I have recently moved from developing VBA Excel Add-Ins to using the new Office JavaScript Add-ins platform. I am used to my VBA Add-In being active across the whole of Excel and the state of the variables is available no matter what workbook you are interacting with.
This does not seem to be the case with JavaScript Add-ins. I have been testing my Add-In and happened to create a new workbook and noticed that none of the Add-In state appeared to be active any longer.
Am I missing something or is this a consequence of the new Office JavaScript Add-ins architecture where it runs inside a browser within Excel?
Just to confirm I have already enabled the Shared Runtime option, that is not my question. I am able to share state between Commands, Takspane and Functions. But all within a single workbook.
I have tried one of the example Yeoman generator for Office Add-ins and it certainly seems that global variables are not shared between the Add-In in two different workbooks.
This behavior is expected. With Office (web) add-ins, each add-in runs in an embedded JavaScript runtime that is a completely separate process from Office and any other add-ins, so it cannot share data across add-ins. Some people have made sharing across add-ins work using the OfficeRuntime.storage object, but it only works in Windows. It won't work on Mac or in Office on the web. Frankly, the Office platform team considers it a bug that it can be done on Windows and that may be fixed at any time, so you should not create an add-in that depends on it even if you know your add-in will only be run on Windows.
Depending on what your scenario is, you might be able to store state in the document with either Office.document.settings or Office.document.customXmlParts. Another possibility is to store state in a database on your server side.
I’ve done a LOT of googling about this and haven’t found anything specific to this situation. Apologies if I missed it.
I have a .xlsm workbook that has a few macros—-one to refresh connections to a Microsoft Access Database, one to refresh pivots, and one to save it to multiple locations.
When I open the file, I get the standard yellow security bar that some active content has been disabled—-but it used to just say ‘macros have been disabled’. When I check the macros, they are there.
BUT when I hit ‘enable’, there’s 2 issues:
it doesn’t enable anything and I have to go to the Trust Center to enable both Macros and External Data Connections. Before yesterday, I never had to do that.
Once I enable macros and external data in the Trust Center, suddenly I get an alert that VBA “can’t find a project or library” and all my macros are now gone.
When I reload the workbook, we’re back to where I started. I have one other workbook with this issue. The other 5 or 6 macro-enabled workbooks do not have this issue.
The issue with these docs persists across 2 other colleagues’ remote laptops. However, when I remote into the office and access the same files in the same folder using VMWare to remote into an office PC environment, they work just fine.
I have tried accessing Tools>References in VBA—-nothing happens when I click ‘References’. I have restarted. I have emailed the files from the VMWare environment to myself, and they don’t work. I have enabled all macros and data connections by selecting those radio buttons, but still have VBA throwing that error and my macros disappearing until I reopen the file.
I truly don’t understand. Can somehow the files be corrupted only when I access them from home? Is there any fix?
Do any of you have advice on methods for deploying an office VSTO addin, especially Excel, that makes it easy to update and deploy the document as well as the addin.
I have a document level addin for Excel 2010 that I created using VSTO. I currently deploy it using click once. However, this has a few problems. The first problem is that I publish it to ftp then users install it from my website. Since the document and addin are downloaded from the internet, I obviously have trouble getting proper permission for the addin to run and the document to be trusted. Currently I just have users manually adjust permissions and grant access when the solution is installed. That part works and is fine, but if any of you have suggestions on how to automate this that would be great.
The second problem, the main one I am wanting help with in this post, is deploying updates. I generally like using clickonce because of its ease of installation and automatic update features. The solutions I develop are used in rapidly growing fast changing companies, which means I am often making updates. Click once makes it easy enough to update the "code" or addin itself. I just have it automatically check for updates when it is started, and if there are updates it will prompt the user to download them. But what about the document? My solution doesn't only include the code. It also includes the highly customized Excel workbook.
When the solution is initially installed a copy of the workbook is just downloaded to the local computer. But what about after it is deployed to dozens of computers? Does a document level change (adding a column for example) mean going to each computer and downloading the updated workbook manually?
Surely there is a better way to automatically deploy updated versions of the workbook. Any suggestions?
Here are a few ideas I thought of:
Use some installer other than clickonce. Any suggestion on one that allows easy automatic updates?
Somehow package the workbook as an application resource. I have actually done this in some situations, but not in cases where the document itself included a VSTO addin.
Related to the previous idea. Make a "wrapper" project that includes the workbook & VSTO addin. Then the addin would be launched by clicking on a regular icon on the desktop, which would download the workbook (if an update was needed) then open it in Excel. I would prefer that method of launch over simply opening the workbook anyway.
Note: No user data needs to be preserved in the Workbook when an update is done. The old version could simply be overwritten by the new one. The workbook gets all its data from an SQL server.
You could use a Visual Studio Setup Project which leverages Windows Installer. See this deployment walkthrough guide on using VSTO 4.0.
In Visual Studio 2012, support for Setup Projects is being deprecated in favor of InstallShield LE which is another alternative.
I have a Windows 2003 Server box with Excel 2010 installed, upon which I am unable to create new or execute existing macros in spreadsheets. Note: this machine is in a Windows Domain (and I am not getting much help from the network folks here.)
I can and have edited the macro security levels within Excel (File, Options, Trust Center, Macro Settings --> Enable All Macros) but despite this, when I try to:
Open a spreadsheet with macros, I get an exception "Excel found unreadable content...." which goes on to refer to the VBA macros within the spreadsheet
Create a new macro in a brand new spreadsheet created on this machine, all the toolbar buttons providing access to the VBA editor are disabled.
Could this be a Group Policy setting that allows me to edit the macro security settings, but overrides these settings and prevents me from actually creating, editing, or executing VBA macros? (If so, does anyone happen to know which group policy setting I should be looking for?)
I've run rsop.msc (Resultant Set of Policy) on the machine and looked through every single thing under both Computer Configuration and User Configuration, but I don't see anything related to Excel (or Office) Security/Macros.
In this case, the problem was that Visual Basic for Applications hadn't been installed when Excel itself was installed.
(As usual, Microsoft could do a much better job of alerting the user to this unusual configuration, but what can you do.)
I have a .NET (C#) addin that uses a COM Shim dll to load itself into Excel. The addin works fine without any problem when Excel is run normally. The addin displays its own custom toolbar in Excel that is used to execute different commands.
When I embed Excel into another application (e.g. DSOFramer etc), the addin starts behaving strangely. It seems that if I disable a button on its toolbar then it does not get enabled again after setting the Visible property.
Also, I get a bunch of "Object reference not set" errors because the Application::Selection object is NULL which never happens when Excel is running normally. Sometimes I also get permission errors when Application::GetAddIns() method is called.
I am not sure what is happening here and I could not find an articles that explains the behavior of Excel COM Addins when Excel is embedded inside other application.
I have to admit I don't know much about dSOFramer, but I did run across the following items. I don't know if these help at all.
link text
link text
I contacted Microsoft Professional for this issue and found out that Microsoft now discourages embedding office applications. I was suggested to either stop embedding Excel into the application OR use only Excel 2007 that has a Ribbon UI. According to MS, the Ribbon UI does not have these issues.
The problem with the CommandBars is that the negotiation only happens during the OnConnection and no changes can be made afterwards.