Referenced assemblies are not copied over

Topics: Bugs
Oct 19, 2007 at 5:58 PM
When I am trying to build my DocProject I am getting the following error:

Error Missing source assembly or file in output directory: C:\AIM\WorkflowServer\Manuals\bin\Debug\WorkflowServer.Foundation.dll

It looks like the build process does not copy the referenced assembly to the proper location. If I copy the file there manually, it builds just fine. Another issue which may or may not be related to this one is that every time I run build command on the doc project, the assembly referenced in in the docproject is rebuilt regardless of whether there were any changes in the source code of referenced assembly.

Any idea what I am doing wrong?

Below is the content of the output window:

------ Build started: Project: Foundation, Configuration: Debug Any CPU ------
Build started 10/19/2007 10:48:46 AM.
Target _CopyAppConfigFile:
Skipping target "_CopyAppConfigFile" because all output files are up-to-date with respect to the input files.
Target CopyFilesToOutputDirectory:
Foundation -> C:\AIM\WorkflowServer\foundation\bin\Debug\WorkflowServer.Foundation.dll
Copying file from "WorkflowServer.Foundation.xml" to "bin\Debug\WorkflowServer.Foundation.xml".
Target PostBuildEvent:
"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\..\..\SDK\v2.0\Bin\gacutil.exe" /i C:\AIM\WorkflowServer\foundation\bin\Debug\WorkflowServer.Foundation.dll /f
Microsoft (R) .NET Global Assembly Cache Utility. Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.

Assembly successfully added to the cache

Build succeeded.

Time Elapsed 00:00:00.32
------ Build started: Project: Manuals, Configuration: Debug Any CPU ------
Build started 10/19/2007 10:48:48 AM.
Target ResolveProjectReferences:
Target GetCopyToOutputDirectoryItems:
Target CopyFilesToOutputDirectory:
Manuals -> C:\AIM\WorkflowServer\Manuals\bin\Debug\Manuals.dll

Starting help build for Manuals...
Preparing target directory...

System.InvalidOperationException was thrown during build preparation:

Missing source assembly or file in output directory: C:\AIM\WorkflowServer\Manuals\bin\Debug\WorkflowServer.Foundation.dll

Total Time Elapsed: 00:00:00.0781260

No steps executed.

Manuals help build failed.


Time Elapsed 00:00:01.12
========== Build: 1 succeeded or up-to-date, 1 failed, 0 skipped ==========
Oct 19, 2007 at 7:41 PM

Strange error you got there ;)

First, I'd like to address the second issue that you mentioned. DocProject does not build the source projects - MSBuild does. So if you're building your DocProject in Visual Studio and you're using project references to define the source assemblies, then Visual Studio/MSBuild are going to determine when the source project needs to be rebuilt (this occurs even before DocProject gets control of the build process). If you find this to be a problem then you may want to add your project's assembly as an External Source, which may inadvertently fix the first problem that you're experiencing; although, I recommend keeping a project reference instead if you can.

As for the error, DocProject does not copy the referenced projects to its bin folder, MSBuild does; however, it's strange that the file path in the error is pointing to your DocProject instead of the source project. In other words, the path should probably be, C:\AIM\WorkflowServer\foundation\bin\Debug\WorkflowServer.Foundation.dll. (That is, foundation instead of Manual.)

The output directory that the error refers to is the output directory of the source project. DocProject acquires this information from MSBuild. I don't see how you could have possibly added the DocProject as a source project to itself, so I have to assume that you've either modified paths or VS/MSBuild is, for some unknown reason, giving DocProject an invalid path.

Have you changed any MSBuild properties in the WorkflowServer.Foundation project file, such as <OutputPath>? Have you modified the DocProject's project file in any way?

If you want to see the output paths of your project as DocProject sees them then you can try adding the following code to the BuildStarting method of your Build Process Component (e.g., BuildProcess.cs or BuildProcess.vb):

context.TraceLine("Project reference paths:");
foreach (ISourceProject source in context.Engine.Project.Sources)
You can cancel (Ctrl+Break) the build process when the first step begins. Look at the build output window in Visual Studio and see what paths have been written.

In my tests the output paths written do not point to the DocProject or DocSite, but instead point to the bin\Debug folder of the source projects themselves.

What version of Visual Studio are you using?

- Dave
Oct 19, 2007 at 10:13 PM
Thank you for a prompt response. No I did not change any properties of the Foundation project nor did I modify the project file. After reading your response I removed the reference to the Foundation project from the doc project, closed Visual Studio, reopened it and re-added the Foundation project. to the doc project. And guess what - now it seems to work fine. So whatever was wrong we will never know.

- Mike
Oct 19, 2007 at 10:28 PM
Nope. I was wrong. It does not work. I cleaned the bin folder in the manuals project and now I am getting this problem again. I will keep digging
Oct 19, 2007 at 11:20 PM
I do not get it. From what I can see in the project files I do not see what can confuse this thing. Below I included a (trimmed) copy of my project file. There is a project reference to the foundation prokject at the bottom of the file. Can you see what's wrong with it?

<Project DefaultTargets="Build" xmlns="">
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(DocProjectBuildPath)\DaveSexton.DocProject.targets" />
<!-- To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
<Target Name="AfterBuild">
<Compile Include="Properties\AssemblyInfo.cs" />
<UserProperties DoNotAskIncludeOutputInProject="True" SandcastleUseFriendlyHtmlFileNames="True" DefaultApplyToAll="False" DeploymentSandcastleDeploymentContent="Chm" SandcastleProduceHelp2x="False" SandcastleProduceHelp1x="True" BuildEngineProviderName="Sandcastle/Deployment" Sandcastle_PresentationName="Visual Studio 2005" IsDocProject="true" ProcessComponentTypeName="Manuals.BuildProcess" />
<Reference Include="DaveSexton.DocProject, Version=, Culture=neutral, PublicKeyToken=af1a4bab65cc4ece, processorArchitecture=MSIL">
<Reference Include="System" />
<Compile Include="BuildProcess.cs" />
<Content Include="Help\Comments\project.xml" />

<Content Include="Help\Styles\Presentation.css" />
<None Include="Help\Presentation\Shared\configuration\xamlSyntax.config" />
<None Include="Help\Presentation\Shared\copyHavana.bat" />
<None Include="Help\Presentation\Shared\HxsTemplate\template.HxF" />
<None Include="Help\Presentation\Shared\HxsTemplate\template_A.HxK" />
<None Include="Help\Presentation\Shared\HxsTemplate\template_B.HxK" />
<None Include="Help\Presentation\Shared\HxsTemplate\template_F.HxK" />
<None Include="Help\Presentation\Shared\HxsTemplate\template_K.HxK" />
<None Include="Help\Presentation\Shared\HxsTemplate\template_N.HxK" />
<None Include="Help\Presentation\Shared\HxsTemplate\template_S.HxK" />
<None Include="Help\Presentation\Shared\SharedDocModel.ps1" />
<None Include="Help\Presentation\Style\Configuration\MRefBuilder.config" />
<None Include="Help\Presentation\Style\Configuration\sandcastle.help1x.config" />
<None Include="Help\Presentation\Style\Configuration\sandcastle.help2x.config" />
<Service Include="{B4F97281-0DBD-4835-9ED8-7DFB966E87FF}" />
<ProjectReference Include="..\Foundation\Foundation.csproj">
<Folder Include="Help\Art\" />
Oct 20, 2007 at 12:02 AM
Hi Mike,

A workaround might be to ensure that the project reference has Copy Local set to True so that MSBuild automatically copies the project's output to your DocProject's output folder. (Although, that is usually the default anyway so I wonder if it's already set). To set this property, find the project reference to the Foundation library under your DocProject's References folder in Solution Explorer and open the properties window.

Would you mind running a test to see what VS returns for the source project's path?

Add the following code in the BuildStarting method of your Build Process Component file:

context.TraceLine("Source projects: ");
foreach (ISourceProject source in context.Engine.Project.Sources)
  context.TraceLine("{0} ({1}):", source.Name, source.GetType().Name);
  context.TraceLine("\tProject directory: {0}", ((IAnyProject) source).Directory);
  context.TraceLine("\tRelative output path: {0}", source.Output.RelativeOutputPath);
Cancel the build after the first step starts and please post the output of the code above here, thanks. It should be something like the following:

Foundation (VSSourceProject):
  Project directory: C:\AIM\WorkflowServer\foundation\
  Relative output path: bin\Debug\
Although, I expect the project directory to incorrectly point to the Manuals project instead of the Foundation project.

- Dave
Oct 20, 2007 at 12:07 AM
Hi Mike,

I've just seen your post with the project file contents and I realize that you can fix the problem by setting Copy Local to True, as I stated previously (this setting corresponds to the <Private> element in your project reference, which either should not be present at all or should contain the value: True).

I just tried building a DocProject with Copy Local set to False on a project reference and got the same error as you! I'm investigating...

- Dave
Oct 20, 2007 at 12:15 AM
Hi Mike,

It's a bug in BuildEngine.cs that I've fixed for the next release. Setting CopyLocal to True should work for now though.

- Dave
Oct 20, 2007 at 12:16 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Oct 25, 2007 at 6:48 PM
Hi, Dave,
I followed your recommendation and changed the CopyLocal to true and now this thing seems to work. There is still a glitch. It seems that when you add a reference to an up to date project and then build the doc project the refrenced dll is not copied and I am getting the same error. If you rebuild the project though, the dll is copied over and from this moment on everything goes smoothly. It seems that for up to date projects, the CopyFilesToOutputDirectory step is skipped even though the dll is not there yet.
As to another issue I originally rported - it turned out to be a figment of my imagination.
Anyway, now the doc project seems to work and I am really impressed by the speed and quality of your response,
Oct 26, 2007 at 12:16 AM

The glitch that you see is still caused by the same bug that has been fixed for the next release. Basically, DocProject was never supposed to reference the assembly that is copied over from MSBuild. It has always referenced the assemblies from their source locations and this bug was a regression issue, probably in 1.8.0.

Thanks for reporting the problem.

- Dave