Deploy Post-Build Auto-Generated Files in VS2013

If you're like me, and I know I am, you just spent the last hour hunting down an answer to what should be widely documented: how do you get that auto-generated xml documentation from your Web Api to publish to your website from your TFS build agent? I know we all struggle with this question daily. Well let me help you out.

Context

Just so we are all on the same page, I'm talking about the auto-generated xml doc you get when you check the XML documentation file box in the Build tab of the project properties.

Build tab

What I do now, I've modified the code generated by the Microsoft ASP.Net Web API 2.2 Help Page nugget package to load up all xml documentation in the App_Data folder (maybe I'll write up how I did this later). I also have a post-build event command:

copy $(TargetDir)Acme.*.xml $(ProjectDir)App_Data /Y

I need those xml files in the App_Data folder to get published or my Web Api help page will not contain any code comments.

Potential Answers

Let me run down some answers that have been posed on the web that just don't work for me.

Q: Why not just include the xml doc in the project?
A: Because the file is auto-generated. I don't need to be asked to check-in this file every time my local machine modifies it. And I certainly don't want everyone else on the team checking in new copies just because they don't know that they did not intentionally change the file. It takes too much effort to explain to people to ignore this file.

Q: Why not just include the xml doc in the project as a link to a file so that TFS doesn't know about it?
A: Because when the build agent downloads the latest source from TFS, it will not find the file and will then generate an error before it even tries to build (which is what generates the xml doc).

Q: I don't have this problem.
A. Firstly, that is not a question. Secondly, you are probably not referencing a library whose auto-generated xml documentation you want included in your web app's API documentation. I am. I like to write my API in a library, and then reference it from the Web Api project because a Web Api project should not contain the core logic of your API. It should be more like a transport layer, a presentation layer. It's just another way that people can get at your API. Maybe you want to use your API library and make it accessible to a native app without HTTP being involved. I can do that since I separate my concerns.

Q: Why not modify the project file to use CopyAllFilesToSingleFolderForMsdeployDependsOn like so many answers on stackoverflow, etc?
A: I seriously could not get them to work. I must have been doing something wrong. I know that I'm using VS2013 which is one or more version ahead of the answers I was reading, but otherwise I don't know what I was doing wrong.

My Solution

Modify the project file to include files of that pattern. Add the following to the project file:

        <ItemGroup>
            <Content Include="App_Data\Acme.*.xml" />
        </ItemGroup>

Apparently the solution will build without files there initially, and it will not complain when those files are overwritten. They will publish just fine then.

One major flaw

The build agents must have a copy, even if it's an old copy, of the xml documentation in place pre-build before they can include it. So what this means is that your build definition cannot wipe out all files every time the agent starts a build. Also it means that your agent must build at least once before you can expect an xml doc to show up. So if you reference a new library with an xml doc you'd also like to include, you can expect to queue that build up twice before that build agent properly publishes that xml doc.

Let me know if you have a better solution. For now, this works for me.

Comments