Sandbox and DSL Tools?

Topics: User Forum
May 3, 2010 at 3:35 PM
Edited May 3, 2010 at 3:53 PM
Hi!

I am currently working with Microsoft DSL Tools and have a lot of custom code, thus Sandcastle is the right tool for generating my doc files. I would love to use Sandcastle for this purpose, however, I do have some problems building my Sandcastle project. I always get the following error message:

SHFB: Error BE0065: BUILD FAILED: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\DSLTools\v2.1\Microsoft.DSLTools.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. E:\Test\Sandcastle\SandcastleDSLTest\Dsl\Dsl.csproj

I overcame this error by commenting out the import directive in the dsl and dsl project file. However, this is more a hack than anything else (moreover the DSL does not work properly anymore after commenting out the import directive in both projects).

An overview what I have done:

First I created a new dsl project, enabled the XML documentation support (according to the Sandbox documentation), compiled the solution and tested it in the experimental hive (everything worked fine). After that I created a new Sandcastle project, added the dsl solution file as documentation source and the project references (dsl project, dsl package project) to the references node in the Sandcastle Help File Builder. Now I tried to build the Sandcastle project but received the error message above. I checked the files and folders and all of them do exist on my machine.

I am pretty new to Sandcastle and therefore have a low experience level. Has anyone experienced the same or similar issues related to DSL projects? Thanks for any hint on that topic.

Best regards,
Tom

PS: Please, excuse my English, I am not a native :-)

Coordinator
May 3, 2010 at 7:05 PM

If you're adding the Visual Studio project as the documentation source, it should find the references automatically.  Try removing the project references from the SHFB project and see if that solves the issue.  If you do need to manually specify the references, add the assemblies created by the DSL projects as the references rather than the projects since it would appear that it can't import the noted target file in that situation.

Eric

 

May 4, 2010 at 11:43 AM
Edited May 4, 2010 at 11:45 AM
Hi Eric!

Thanks for your fast reply!

I tried to fix the problem according to your suggestions but was still not successful. I removed the references and added the project files as documentation sources (thanks for that hint!) accordingly. However, I still get the same error statement telling me that Sandcastle is not able to find the imported project C:\Program Files\MSBuild\Microsoft\VisualStudio\DSLTools\v2.1\Microsoft.DSLTools.targets

One feeling I have about this issue is that the import directive in the csproj file causes some unexpected behavior. A naive question: Could it be possible that the file type (target file) has something to do with it? Below I posted the <import> code line which causes the trouble in the <bold>Dsl.csproj</bold> file (the same applies for the DslPackage project file).

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\DSLTools\v2.1\Microsoft.DSLTools.targets />

Again, thanks a lot for any statement! I would really like to understand the reason for this error message but do not know where to start.

Best regards,
Tom

Coordinator
May 4, 2010 at 3:13 PM

Are they MSBuild 4.0 project files?  SHFB still uses MSBuild 3.5 so it won't be able to interpret some of the newer elements in MSBuild 4.0 files.  Don't add the DSL project files as documentation sources, just the project that you want documented.  If the project that you want to document contains references to the DSL assemblies, it should find them automatically.

Eric

 

May 6, 2010 at 10:13 AM
Edited May 6, 2010 at 10:15 AM

A colleague of mine found the mistake: It has two reasons. First, the MSBuild ($(MSBuildBinPath)) path was not properly resolved and pointed to a wrong directory (in my case X:\Program Files\... instead of X:\Program Files (x86)\.. . Second, as it seems my visual resolver did not work properly, too (I have not recognized the missing (x86)) :-)

As a solution I copied the target files into the requested location. After that everything worked fine. One remark on my system configuration: I have two VStudio instances installed on my machine (VS2k8 and VS2k10 beta). Perhaps this caused the path mismatch. However, the solution is not fine but fits my needs so far.

Thank you very much for your comments and effort, Eric!

All the best,

Tom