I have a bug in an Excel VSTO 4.0 C# add-in that I've developed but it is only occurring when double-clicking on an existing file to launch Excel. I'm trying to figure out a way to start the VS2013 debugger so that I can put in some breakpoints but none of the ways I've tried to start the debugger mimic the process of launching Excel by a double-click on a file.
Ways I've tried so far:
Launching Excel itself and then attaching to the process
Double-clicking an Excel file and then attaching to the resulting process
In the VS project Debug properties under Start Action, entering the path to Excel Excel.exe in the Start external program box and the path to an existing Excel file in the command line arguments box
Adding Excel.exe as a new existing project to my VS solution with the path to an existing file as an argument in the project properties, the setting it as the startup project for the solution.
None of these methods for starting the debugger are reproducing the bug. Is there another way to start debugging when double-clicking a file to launch Excel?
For what it's worth, the bug I'm experiencing is that an empty workbook will be created when double-clicking an existing file when Excel is not already running. I need to find out where / why that empty file is getting created. It doesn't happen if Excel is already running and you double-click a file to open it.
This works for me:
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
System.Diagnostics.Debugger.Launch();
...
}
Try to use any logging mechanisms to log any action in the code. Thus, you will be able to find what is going on in the code at runtime. For example, you can write actions to the log file. You may find the log4net library helpful.
I am assuming that you are puuting breakpoint in a method which handles the WorkbookOpen event.
When you double click an Excel file, it gets loaded and event WorkbookOpen is raised. VSTO add-in is not yet loaded so you can't get that event. After loading the workbook, Excel loads VSTO add-in.
So when your add-in is loaded, your handler for AddinStartup comes in action.
In vb.net, the handler line appears as...
Private Sub ThisAddIn_Startup() Handles Me.Startup
You can now check for loaded workbook in ThisAddIn_Startup
If Application.ActiveWorkbook IsNot Nothing Then
DoSomething(Application.ActiveWorkbook)
End If
The other way to mimic some of these debugging is to open file and close file, loading and unloading your addin using excel options manually.
Put a breakpoint on Addin_Startup.
Start normal debugging of VSTO Project.
Load File.
Go in excel options and unload your addin by unchecking it.
Go in excel options and LOAD your addin by checking it.
Related
I created a simple vba addin that colors cells based on their value, and I created a function that calls it with a shortcut then I saved it as an Excel addin and added it to Excel.
The problem is the addin works fine when I add it the first time, but when I open a new Excel file, I need to disable and enable the addin for it to work.
Update: I tried it on another computer and it works, but it shows an error that when I ignore it works fine. I am adding screenshots for the error and code
Error Message
Code
Sometimes, Excel will open workbooks in another Excel Application. This second application can sometimes face some issues with addins. You should double-check that the new file is opened in the same Excel Application. By looking at the task manager:
In this example, I'm using Window 10 and you can see that Book3.xlsx is in a different Excel Application than Book2.xlsx and Book1.xlsx
EDIT:
This question could also be of interest to you. The accepted answer reads:
This problem results from security patch in KB31152, released in July 2016. According to private communication with Microsoft software engineers:
"With this update, we changed the behavior of Excel so that it will
not load certain file types (including .xlam) when they are untrusted.
The easiest workaround is to find the add-in that is causing you
trouble, right-clicking on it in Windows Explorer, and checking
Unblock"
An easier approach is to simply place the add-in in a Trusted Location
(in Excel, go to File > Options > Trust Center > Trust Center Settings
Trusted Locations), such as the following folder, and load it from there:
C:\Users\%USER NAME%\AppData\Roaming\Microsoft\Excel\XLSTART
EDIT2:
And don't forget the option of just restarting your computer just to make sure that the problem is still there.
I have created a simple VSTO project based on a Binary Excel file, the name of the file is Text.xlsb. When I run this in debug mode from VS, the file gets renamed as Test1.xlsb and opens, also my open even is not getting fired, but the Activate event if triggered.
Can some one help me to resolve this? I think VSTO is treating the Excel file as a template and assigning a different name on open.
I am trying to develop an Excel add-in by using JavaScript API for Excel.
I can already make some samples run, launch debugging under Visual Studio. Every time when i launch debugging, it opens a new workbook of Excel.
However, most of time, I need to debug an add-in on an existing workbook. For instance, here is an add-in sample, which opens a blank workbook and adds blank sheets to it. However, I want it to add blank sheets to an existing (opened) workbook. Does anyone know what I should set to debug it on an existing (opened) workbook? Should I modify some lines of code?
Edit 1:
From http://dev.office.com/docs/add-ins/get-started/create-and-debug-office-add-ins-in-visual-studio
To use an existing document to debug the add-in
In Solution Explorer, choose the add-in project folder.
Note Choose the add-in project and not the web application project.
On the Project menu, choose Add Existing Item.
In the Add Existing Item dialog box, locate and select the document
that you want to add.
Choose the Add button to add the document to your project.
In Solution Explorer, open the shortcut menu for the project, and
then choose Properties.
The property pages for the project appear.
In the Start Document list, choose the document that you added to the
project, and then choose the OK button to close the property pages.
Here is the resulting configuration that you should see:
After that just press F5 (start debugging), and you should be good to go.
~ Michael Zlatkovsky, developer on Office Extensibility team, MSFT
For anyone else running into this same issue (i.e. tying to set up an existing worksheet for debugging) without having to jump through 3 hoops to insert the add-in every time, this worked for me:
Set the Start Document to "New Excel/Word/etc Document"
Hit F5 to start debugging.
The resulting new document will be read-only and it will be in the Debug/Release folder.
Close the document, don't save it.
Copy the document to the folder where your Web Add-In manifest is and renamed it to whatever name you prefer.
Uncheck "Read Only" int the file's properties.
Set the Start Document as described by Michael in his response above.
If you start debug now, the add-in "should" load automatically. If you start without debugging (Ctrl + F5), you should be able to close the document and open it (or a copy of it) from anywhere in the PC and it should load automatically. You can even make changes to your JS code and reload the taskpanes/dialogs and it should take effect.
What did NOT work:
Using a blank start document and saving it after inserting the add-in. Once you save it, it loses its connection to the developer add-in.
If you start any document in debug mode and save it, it will NOT work the next time! If you want to make any changes to it, DO NOT start in debug mode.
I am not sure if any of these quirks are by design or if a Windows/Office update messed it up for me. Regardless, this is a very painful experience compared to developing VSTOs.
I have a c# application that uses Microsoft.Office.Interop.Excel. The application runs for a long period of time! If I try to open Excel manually on a different worksheet from the one the c# application is processing the c# application fails with some HResult cryptic message.
Is there a limitation with Microsoft.Office.Interop.Excel in that only 1 excel process can run at once?
Any information around this issue would be great!
thanks for any help!
Mostly, it is how your code is interacting with Excel that is the problem. Many people use ActiveCell, ActiveWorkbook, and so on. Therefore, when you open another workbook during this process, you will generate some kind of error. To avoid this, open another instance of Excel. In our shop, we created a shortcut in our "Send To..." folder. We could then just right-click on the file in Windows Explorer, select "Send To..." menu, then click on our shortcut. This saved us from having to open Excel, select file open, browse to file, and so on.
I've writen an Excel-based, database reporting tool. Currentely, all the VBA code is associated with a single XLS file. The user generates the report by clicking a button on the toolbar. Unfortunately, unless the user has saved the file under another file name, all the reported data gets wiped-out.
When I have created similar tools in Word, I can put all the code in a template (.dot) file and call it from there. If I put the template file in the Office startup folder, it will launch everytime I start Word. Is there a similar way, to package and distribute my code in Excel? I've tried using Add-ins, but I didn't find a way to call the code from the application window.
Simply move your code into an Excel Addin (XLA) - this gets loaded at startup (assuming it's in the %AppData%\Microsoft\Excel\XLSTART folder) but if it's a addin, not a workbook, then only your macros and defined startup functions will be loaded.
If the functions depend on a spreadsheet itself, then you might want to use a combination of templates and addins.
I'm distributing part of an application like this, we have addins for Word, Excel and Powerpoint (XLA, PPA, DOT) and also Office 2007 'ribbon' versions (DOTM, XLAM and PPAM)
The addin startup code creates toolbar buttons if they're not found, this means in any workbook/document/etc they can simply hit the toolbar button to run our code (we have two action buttons and one button that displays a settings dialog)
Templates aren't really the way to go for VBA code, Addins are definitely the way to go...
So to load the toolbars on startup we're using something like.. (checking to see if toolbar exists though - code will run for each worksheet that is opened, but toolbars are persistent for the user session)
Public Sub Workbook_Open()
' startup code / add toolbar / load saved settings, etc.
End Sub
hope that helps :)
I always use an Add-in(xla)/Template(xlt) combination. Your add-in creates the menu (or other UI entry points) and loads templates as needed. It also write data that you want to persist to a database (Access, SQLServer, text file, or even an xls file).
The first rule is to keep your code separate from your data. Then, if you later have bug fixes or other code changes, you can send a new add-in and all of their templates and databases aren't affected.
You can modify the user's personal.xls file, stored in the excel startup directory (varies between Office versions). If you have lots of users though, that can be fiddly.
An alternative way to get over your problem is to store the macro in a template (.xlt) file. Then when the users opens it they can't save it back over the original file, but have to specify a new filename to save it as. The disadvantage of this method is that you then get multiple copies of your original code all over the place with each saved file. If you modify the original .xlt and someone reruns the old macro in a previously-saved .xls file then things can get out of step.
Have you looked into ClickOnce deploying the Excel file?
What about to save an excel to network folder with read only permissions ? The authentication can be done with integrated windows authentication and you don't need to store connection password to the database in the VBA. Then you only need distribute a link to this location to your users only once. If you will do an update, you only change data in that folder without user notice.