Final location of VS project executables
I'm writing a Visual Studio extension, and I need to know the final location of the end user's project's executable for each of their projects. Let's assume I'm specifically targeting C# desktop applications, so they should be using MSBuild. This is normally fairly simple, but some end user projects can be quite complex. The simple answer is to query
DTE for each project and get their
OutputPath. Sometimes, it's not so simple. Here's an example where this doesn't work:
Some solution contains three projects:
Mainproject uses the standard output path.
Plugin2projects get copied to a
pluginsfolder after they're built, through a
Copy AfterBuilddirective in their respective project files.
The user runs the
Mainproject and tells it, at run-time, which plugin they need.
Mainproject uses that information to dynamically load the selected plugin.
Note that this means that the selected DLLs are not shown as references in the
Main executable. If they were, I could figure out a way to retrieve that information, but they're dynamically calculated. I need to know this information before execution.
The main problem I have is that I don't have a reliable way of retrieving the "final output path" of the plugins (the result of the
AfterBuild directive in the project files), and that is what I really need to know. Unfortunately, I can't just change the project files, since this extension needs to work with as many VS solutions as possible.
As I see it you have the following options:
You could likely put the dlls inside a vsix file see here which is a zip file. You can use reflection from your entry point (ie main method) and then you can find your main methods executable location (ie exe, dll etc). If it shows as in vsix path then you know your vsix location and can load the other dlls relative to that.
You can work around your issue by having the dlls download as required see here with a framework like MEF or MAF see here. That way you don't need to know the location. You could also choose to store the downloaded dlls standalone or within a section of your dll as a resource etc. (your choice)
For both options you would end up creating interfaces in new dlls that would be refernced by both the plugins and your main project. This will enable you to have certainty between your different projects. There is nothing that an interface can't represent practically as you can even put function call backs in there.