How to prevent DocSite*.xml from being added to source control?

Topics: Bugs, DocSites, Features, General Discussion, General Questions
May 31, 2007 at 7:36 PM
Since DocSiteContents.xml and DocSiteIndex.xml are build products, I do not want to add them to source control (TFS). I also do not want to have to answer the question every build (about whether I want to add them or not).

Currently I have the following settings in "Include Project Output Dialog":

Apply to all default - TRUE
Include project output default - FALSE
Don't ask me this again - TRUE

How can I prevent these files from being added to source control automatically?
Coordinator
Jun 1, 2007 at 1:49 AM
Hi,

Thanks for using DocProject.

Those two special DocSite files are not treated the same as a build engine's project items, so the Include Project Output Dialog doesn't apply to them. You are never asked to include them and the default settings, therefore, do not apply either.

I'll make sure that they appear in the dialog in DocProject 1.6.0 RC, so your default settings will apply. But note that you can't deploy your site without these files so it may be better to have them included as project items anyway, source-controlled, so that you don't forget about them around deployment time.

I'll do some research to see if DocProject can automatically check-out files (or at least display the check-out dialog) so that you don't get errors when read-only files cannot be replaced by the help-build engine. This will not be a feature of DocProject 1.6.0, however.

For now, you can try to add the following code to your build process component (the BuildProcess.cs file) to exclude the files after each build. I'm assuming that you're using C#, but this should work in VB.NET too with some minor adjustments to syntax. Please note that I haven't tested this myself:

public override void BuildCompleted(BuildContext context)
{
  TraceLine();
  TraceLine("Total Time Elapsed: {0}", DateTime.Now - buildStart);
 
  TraceLine();
  TraceLine("Removing DocSite files from project...");
 
  context.Engine.Project.Project.ProjectItems.Item("DocSiteContents.xml").Remove();
  context.Engine.Project.Project.ProjectItems.Item("DocSiteIndex.xml").Remove();
 
  TraceLine("Done.");
}
NOTE: You must add a reference to the following assemblies, which you should be able to find on the .NET tab:
  • EnvDTE
  • VSLangProj
  • VSLangProj80
If you get an ArgumentException then try using the full path to the items (e.g., c:\...\DocSiteContents.xml).

Please let me know if it works for you!
Thanks :)
Jun 7, 2007 at 2:40 PM
Adding the context.Engine....Remove() lines did indeed fix the problem. Thanks!

We do not include the *.xml outputs in source control for the same reason that we do not include *.htm outputs; you can't run a new build without checking out the files! In my view, whether an output is a *.dll or a *.htm or a *.xml is irrelevant; it's build output, so it shouldn't be source controlled. Just source control the inputs and you have everything you need to get the outputs.

It is very important to us to be able to run an automated build (no human intervention). To the extent that a future version does include a dialog that offers to check out files, I hope it will either not run at all if the files are not source-controlled, or it can be suppressed by project settings.

Thanks for your nice plug-in!
Coordinator
Jun 7, 2007 at 3:23 PM
Edited Jun 7, 2007 at 10:16 PM
Hi,


Adding the context.Engine....Remove() lines did indeed fix the problem. Thanks!

Glad to here it and thanks for letting me know.

We do not include the *.xml outputs in source control for the same reason that we do not include *.htm outputs; you can't run a new build without checking out the files! In my view, whether an output is a *.dll or a *.htm or a *.xml is irrelevant; it's build output, so it shouldn't be source controlled. Just source control the inputs and you have everything you need to get the outputs.

I never thought of it like that, and it does make sense, but the problem is that Visual Studio's deployment mechanisms (such as copy project) require the project items and I assumed that people would rather have the required files deployed automatically and just deal with the source control as a secondary issue. I guess it really depends on how forgetful you are around deployment time and how often you will build the help project.

It is very important to us to be able to run an automated build (no human intervention). To the extent that a future version does include a dialog that offers to check out files, I hope it will either not run at all if the files are not source-controlled, or it can be suppressed by project settings.

I'm going to look into automating source-control and I'll certainly keep your points in mind when I do the research. My goal isn't to have a dialog at all, though, but instead read a project setting that indicates whether checked-in project items, that are build outputs, should be automatically checked-out by DocProject so they can be replaced or deleted by the build engine. - that's the idea for now, anyway.

You may be happy to hear that 1.6.0 supports MSBuild.
Actually, DocProject's build task is used by the templates, so you can simply use: msbuild.exe "myDocProj.csproj" on the command-line without having to change anything.

Thanks for your nice plug-in!

No problem. Thanks for the feedback!