Setting up a build dependency without using a reference?

Question

All: I am working on a solution where one of the projects is actually plug-in to the main exe that the solution builds. Since this one project is a plug in, it's wrong to reference the plug-in from the main exe (that assembly isn't guaranteed to be present in a deployment, it's optional).

So here's my problem: If I modify code in my plug-in project, and then hit F-5 to run, Visual Studio will not alwyas build my plug-in (since based upon the reference tree, the main exe does not appear to depend upon it).

Is there a solution or project-level setting that I could change to cause this plug-in project to be included when I run (without adding a reference)?

I know about the global setting in tools | options | Build and Run, but I'd rather not have to change VS's behavior globally just to get this solution to build right (also, if the setting goes with the solution or project, then when other developers check it out, they should simply inherit the setting)

BTW: these are c# projects in a VS 2005 solution.

Answer 1

Can I suggest creating a dummy (empty) project, to represent the combination of the main exe and the plugin, and configuring that project to be dependent on both, but run the EXE on launch?

Answer 2

Right click the root node in Solution Explorer -> Properties -> Project Dependencies. (VS 2008 users: this feature gets its own dialog box that's directly accessible from the context menu.)

The dependency graph is represented as an adjacency list of checkboxes. Each project you select will have its direct references checked & disabled [assuming you use project refs, not assembly refs]. Other checkboxes might be disabled if they would create a circular dependency.

For any checkbox not disabled, checking/unchecking will write a ProjectSection(ProjectDepedencies) section into your solution file. So your settings will propagate to other developers via source control.

Fair warning though: if you use MSBuild (including any version of Team Build), it does not always handle *.sln file customizations the same way that builds inside Visual Studio do. *.sln is not a native MSBuild file type, unlike *.??proj files. I myself have run into the problem described here; I've also seen the opposite behavior on occasion.