6

In Visual Studio VSTO, how can I specify the document to open each time I run the project to debug it?

By default, it always opens a blank document and of course I want to test against features that would already be present in a document.

ForEachLoop
  • 2,508
  • 3
  • 18
  • 28

3 Answers3

2

I tried as Cor_Blimey suggested but it opens only the specified when something changes (haven't figured what yet). In addition breakpoints don't work at least in VS2013 implementing the upper solution.
So what I did is to open the specific debugging/testing file each time the add-in is started up.
It works excellent, breakpoints are functional, no blank workbook is loaded and changes in a sheet a available in the next debugging session. In order to avoid that the file is opened in the released add-in I put it in #if DEBUG.
More information about that method are here but it has as to be used with precaution as described here.

         private void ThisAddIn_Startup(object sender, System.EventArgs e)
        {
#if (DEBUG)
            this.Application.Workbooks.Open("C:\\Users\\c563368\\Documents\\Visual Studio 2013\\Projects\\...\\debug.xls");
#endif
        }

But there is one disadvantage, as long as you debugging environment (visual studio) is running, Office will always open the add-in build from the debug folder. You can avoid this by running an the office application as external program, as described here.

Community
  • 1
  • 1
Stefan
  • 372
  • 1
  • 16
1

You need to use the command line you can set to run on a successful build (there is no way to only get it to run on Debug (as in F11) and you cannot set it on a per Configuration basis. However, there is a good workaround to get it to only do things on the Debug configuration etc.

The basic behaviour is:

Open the solution. Open the project's properties. Go to Build Events. In Post-Build Event Command Line enter in the path to Word (e.g. "C:\Program Files (x86)\Microsoft Office\Office14\Winword") (or if it is in your %Path% then just Winword) and pass in the path to the document you want opened as an argument. This will open Word and the document on every successful build (you can set the trigger to being all builds, whether successful or otherwise etc)

What I prefer to do, however, is simply point it to a batch file, passing in the details about the build event as arguments to the batch file. Then, within the batch file, I run the logic to decide if it should launch Word, open a document etc.

For example, you can point it to

$(ProjectDir)buildScript.bat "$(ConfigurationName)"

Then within the batch file have something like

if %1=="Debug - Excel" "C:\Program Files (x86)\Microsoft Office\Office14\excel.exe" "%~dp0\testbook.xlsx"

This will run a batch file called buildScript in the project directory. The first argument (%1 to access in the batch file) will be the configuration. You can therefore set the batch file to launch Word and pass in the document as the argument if the config is e.g. "Debug" but not if it is "Release", thereby sidestepping the limitation within VS2012 Post-Build Event command line.

Edit:

A list of switches for Word can be found at http://support.microsoft.com/kb/210565

What you need to instruct Word to do will depend on the type of addin you are making:

If it is a standard COM addin then, so long as the DLL is registered and you have set the registry entries (or selected it in the Word addin settings) to open the addin then it should open when Word opens.

If it is an addin document, however, then the procedure is different -> try playing with the commnd switches to instruct Word to open the particular addin document.

I am more familiar with Excel COM addins, so you will have to experiment with the specificities of a Word addin. But the basic principles are to use the post-build event commnd line, coupled with the right switches and arguments to Winword.

Hope that helps.

Cor_Blimey
  • 3,260
  • 1
  • 14
  • 20
  • That's a great answer, thanks. However, while it does open a document, I'm working on an add-in and it opens that document with in a normal window and still opens a second empty document with all the controls I'm working with. It's this second window with the add-in's controls I'm interesting in seeing. – ForEachLoop Aug 04 '13 at 04:59
  • @ForEachLoop I think I need more details on the type of the addin then. Is it a standard COM addin? See my edited answer above. – Cor_Blimey Aug 04 '13 at 12:52
0

The simpliest way to achive it is to replace .docx / .xlsx file in solution location

Tomasz
  • 426
  • 2
  • 10