Unable to disable copying XML to output/bundle XML as embedded resource

[ansteele]

Hi,

I'm looking to use your project to trim down the generated XML docs to just public symbols but I'm having trouble fitting it into my existing build.

My build sets CopyDocumentationFileToOutputDirectory to false and adds a new target that embeds the XML file (@(DocFileItem)) as an assembly resource, but I can't figure out how to do this with InheritDoc in the mix.

InheritDoc requires CopyDocumentationFileToOutputDirectory to be true (which it then sets to false and does the copy itself I believe) so I've been trying to modify DocFileItem/FinalDocFile to point to the intermediate build directory without much luck.

Obviously my embed target needs to run before the assembly is generated but I think InheritDoc is maybe set to run after that? Which would explain why changing the paths doesn't work.

Any thoughts on how I can achieve this? Many thanks

[ansteele]

I think I've got renaming the FinalDocFile working so it doesn't copy to the OutDir.

<Target Name="RenameDoc" BeforeTargets="PrepareForBuild">
	<ItemGroup>
		<FinalDocFile Remove="@(FinalDocFile)" />
		<FinalDocFile Include="$(IntermediateOutputPath)FinalDoc.xml" />
	</ItemGroup>
</Target>

[saucecontrol]

Obviously my embed target needs to run before the assembly is generated but I think InheritDoc is maybe set to run after that?

Yeah, the XML file is generated by the C# compiler at the same time it generates the assembly. I assume your current process must build twice so that the first build generates the file and then the second embeds it?

InheritDoc's CopyDocumentationFileToOutputDirectory behavior was implemented in order to support incremental builds (https://github.com/saucecontrol/InheritDoc/pull/13) because if the intermediate files are modified by the post-processor, the change is detected by MSBuild, which always triggers the task on build since the intermediate doc file is tracked as an output of the compile step.

[ansteele]

Don't need to build twice, following this. I'd imagine this target is just registering the resource at the start of the build, and then somehow the file exists at the time the assembly is generated. Whether these are distinct steps that InheritDoc could sit in between I don't know.

[saucecontrol]

Hmmm... I'm not sure how that would work. Both the XML doc file and the output assembly are produced by the CoreCompile target (which is called as part of outer Build step in MSBuild terms). It's possible the compilation itself is done in separate stages internally, but there's no mechanism for interaction there that I'm aware of.