views:

331

answers:

1

I have a custom project type based on the C# Class Library project type in a VSX Package (2008+). For this project type, even though the output is a class library, I want to be able to debug this app just by pressing F5 (etc). I have a prebuilt executable that takes an assembly path as a command-line argument and loads it for workbench testing.

I can simulate this behavior manually by using the Project's "Debug >> Start Action >> Start External Program" in the property pages by providing the path to the executable and providing the relative path to the output dll as a command line argument. But this is too much setup. I would want the project type's package code to be able to grab the assembly of the active configuration and the installed location of the workbench executable automatically.

The worst case scenario would be that after every successful build, the property pages for that project are updated programmatically with the correct values. I don't particularly like this solution because it seems messy, seems like it would be easy to get out of sync and expose those potential errors to the user.

The best solution that I can imagine involved intercepting the Start Debugger event (only for this project type) before it craps out with "A project with an Output Type of Class Library cannot be started directly" and executes the workbench instead (debugger attached, of course). I don't know if VSX exposes the necessary parts.

I would pay to have this simple (?) package (along with a few other requirements, mainly a project-level menu item, already partially implemented) written by someone with experience, but I haven't found any consultants that specialize in VSX packages. Recommendations are welcome.

Am I taking the wrong approach? I'm assuming I need a package rather than an add-in.

Thanks!

+1  A: 

Based on your description, it sounds like you don't have a custom project type, but rather a custom project template. (You would typically only have your own project type if you had your own custom programming language).

Assuming this is the case, I think you should be able to create your own IWizard implementation which would set the project up for launching your host executable, etc... at project creation time (i.e. after the user goes through the New Project dialog).

For example, you could do something like the following in the IWizard's ProjectFinishedGenerating implementation:

public void ProjectFinishedGenerating(Project project)
{
  foreach (Configuration config in project.ConfigurationManager)
  {
    config.Properties.Item("StartAction").Value = 1; //Launch external program
    config.Properties.Item("StartProgram").Value = <pathToYourEXE>;
    config.Properties.Item("StartArguments").Value = <argumentsToYourExe>;
  }
}
Aaron Marten
You're right, I don't have my own language - it is just based off the C# Class Library. All I want to be able to do (so far) is add the project-level context menu item, and this ability to launch-external-program. Does that all fit in a project template? I was under the impression that I'd need a separate guid for the project type in order to get project-specific context menu items.
uosɐſ
But even so, if I were to use this IWizard approach, is there an appropriate hook to make sure that the values are properly updated after the project has been created? Maybe the assembly name was changed or maybe the location of the provided exe is different on a new machine that the project got copied to. I wouldn't want to leave that job to the developer.
uosɐſ
Hi Aaron, any thoughts on this?
uosɐſ
Hi Aaron, these bounty points are about to expire so I'll award them to you in hopes that you can clarify the solution. Thanks for responding!
uosɐſ
Hi Jason, Perhaps the best place to hook this in would be the DTE BuildEvents.OnBuildDone event?For the issue of only getting this behavior for particular projects, you could hook up your addin as a solution addin (an addin that only loads for a particular sln file). http://msdn.microsoft.com/en-us/library/ms165621.aspx
Aaron Marten
Hi Aaron, I like the Solution Add-In idea, but I'd still need a way to differentiate among the various class libraries that might be present in the solution - only some of them should get this additional functionality. Given what I'm interpreting as limitations, it seems that possibly I'd need an Add-In that can permanently mark a project as being Special and treat special projects in this way for debugging - and also provide the additional required Project-level-context-menu command and Project-menu command. Any further ideas? Thanks.
uosɐſ