Package .exe into .vsix and call from Visual Studio extension

Question

I have a Visual Studio package that does some of its work by starting an external process (using System.Diagnostics.Process) and communicating with it over standard input/output. Currently, I have the path to the .exe hard-coded which is obviously not workable for actually deploying the extension. What is the right way to package and distribute the .exe with the extension? (And, related, once I have done so, how do I programmatically discover the path to the installed .exe file.) Preferably I would like to put it into the .vsix file so installation is easy.

EDIT: I have placed the relevant part of my code on BitBucket (it may be useful to someone else using Roslyn): roslyn_process in order to give a better idea of what I am trying to do. This code sets up communication between a Visual Studio extension using an implementation of AbstractProcessHandler and a separate process using RoslynProcess. The latter is kept informed of modifications to the code files in Visual Studio and which code file is being viewed, so it is able to do analysis with up-to-date information despite not running as a Visual Studio extension which would impose the limitations of Roslyn on all code being edited.

EDIT 2: Using this answer, I can get the directory of the extension. I can include another package in source.extension.vsixmanifest by adding it to the content list as type "Custom Extension Type". Then the .exe appears in the extension's directory. This seems like it's probably the right solution although the way of getting the directory is labeled in MSDN as something I shouldn't be using.

It seems like this might be the best way to do this even though it seems hackish, in which case I'll post this as an answer once I get everything working.

Benton

@Kiquenet: Sorry, I don't have a neatly packaged minimal solution... but the accepted answer is a one-liner. – Benton

Answer 1

One of the simplest approaches to this is have your package DLL have a project reference to the EXE and make your entry point class (or some class within the EXE) be public. Then you can just write:

typeof(ExternalProcess).Assembly.Location

which gives you the path to the EXE inside your extension path.

The other nice part about this is the VSIX packager should include the EXE into the VSIX automatically since it's a project reference. You don't have to put anything at all in your .vsixmanifest for the EXE.

Lonilonier

Because when I tried this: include an EXE (that referenced NancyFX), it told me that NancyFX wasn't strong named, and the build failed. – Thirzi

What was "it"? In any case, starting another question here is far more appropriate than a conversation on this one. – Lonilonier

I don't have a question -- I have a caveat: When you create a VSPackage using the VS 2012 SDK, the template creates a project with strong naming enabled. If you refer to anything else in that project, it needs to be strong named, because strong naming is transitive. – Thirzi

Of course. There's often confusion though around VSPackages: they don't have to be strong name signed at all, just the default template (which admittedly is a poor template) sets it up that way by default. – Lonilonier

How do you have a project reference to the .exe? And what is ExternalProcess in the code snippet you wrote? – Sultana