This project has moved and is read-only. For the latest updates, please go here.

SandCastle projects need to honor excluded projects

Topics: Developer Forum, Project Management Forum, User Forum
Jan 5, 2010 at 9:29 PM
Edited Jan 5, 2010 at 10:57 PM

When a SandCastle project includes a solution (.sln) file and that solution references projects that are excluded from being built, SandCastle still expects to find ALL of the projects' output assemblies, and fails with an error message such as:

SHFB: Error BE0040: Project assembly does not exist: [path\assemblyname]

This forces developers to either resort to:

a) Remove non-built projects from the solution

b) Do not add .sln files to sandcastle projects and instead explicitly add each project (.csproj, .vbproj, etc) to it

I suggest if SandCastle is going to process .sln files then it should correctly exclude all projects that are naturally excluded from build.

Note: Before you say "Why do you have projects included in the solution that are excluded from the build?" I will answer that. Suppose some project(s) is/are excluded from the build for certain build configurations but included on others. For example, there may be a project that is only built in Release builds but excluded in Debug builds. This scenario is perfectly valid and supported by Visual Studio solutions. Then if a Debug build is performed, and SandCastle is instructed to use the Debug configuration, it still demands that the output assembly exists for the project in question, which of course it does not and never will exist.


Edit: I should have put this on the Issue Tracker list instead. First time using the forum, wasn't sure what was available.
Posted on Issue Tracker as well (with just a link to this), at

Jan 6, 2010 at 2:56 AM

It's a valid request and I use that option too, it's just not something I thought of when I added the feature to SHFB.  As far as I can tell, the indication to either build or not build is determined by the presense or absense of the "xxx.Build.0" ID in the "GlobalSection(ProjectConfigurationPlatforms) = postSolution" section.  There's no documentation on the format of the solution file that I can find so the implementation will be based on my best guess.  I don't know if values other than zero are possible in the ID (xxx.Build.1 for example).  You can also define an alternate configuration and platform to use when the given ID combination is specified so the change should also take those settings into account too.



Jan 6, 2010 at 2:32 PM

Thanks for responding, Eric.

An approach to possibly consider for this enhancement, could be to simply demote the error into a warning and continue processing the rest of the projects. Example case: Assume ProjectA's output is missing, and ProjectB's output is present and the documentation xml files reference something in ProjectA. Issue a warning instead of an error that ProjectA's assembly could not be located. Also issue warnings for documentation references that could not be resolved (for the references in ProjectB to ProjectA as well as any other missing links) as is done currently.

Another approach to consider would be to truly integrate with Visual Studio (I see an enhancement request for this already posted) and assuming Visual Studio provides a suitable API to deal with the .sln file, you wouldn't need to parse it yourself, but rather work through the VS API to enumerate the projects and query them if they are build enabled.