This is pretty much a brain dump of things to be aware of when combining ASP.NET and Team Build – not for the faint of heart, we are talking beta/CTP here (and I don’t have the luxury of being able to go back and try all of this on Beta 2), but it can be pretty thrilling to see this all running automatically once you do get it working. Give it time and running ASP.NET projects in Team Build will be dead simple, but if you want to be one of the first ones to break through and see this working, here are some of the things you need to be aware of:
- On the build machine make sure you install either VSTD+VSTT or VSTS prior to installing the team build component. This will give you the prerequisites to do attached unit tests and code analysis in conjunction with the build.
- Take the time to learn about the new standalone WebDev.WebServer.exe and how it is different from IIS. File-based projects in Visual Studio are associated with this standalone web server, IIS-based projects in Visual Studio work differently. Team Build uses that web server to perform the automatic unit tests. I believe the easiest way to do this would be to use the standalone web server for everything including team build, and then when it is ready copy the build outputs to the deployment server. I am curious what feedback people might have on this.
- Use the “Any CPU” platform type for ASP.NET projects – not the “x86” type. I’ve logged an issue related to the fact it does not give you “.NET” as a platform type even though that is what is in the configuration manager. But “Any CPU” should work. On beta builds there may be a typo of “AnyCPU” rather than with the space, if that is the case you may need to adjust the TeamBuild.proj file manually to fix the typo.
- Adding existing solutions and creating new solutions that are outside of the source control root can cause immense pain and suffering – hopefully this won’t be the case by RTM (release to manufacture) – but it is now, please read this post for more information on how to deal with that: http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3968
- ASP.NET unit tests that have hardcoded paths in the attributes of the unit test that work on the dev machine but don’t match the team build machine will of course fail. There is a solution in the works to avoid this hardcoded path problem, but on beta/CTP builds one workaround could be to make sure the source control system has the hardcoded path that will work on the team build machine and that the individual developer machines can check out a private copy and make the path work on theres.
- The documentation is still maturing, there may be different names (for example, in recent builds it is no longer called tbuild.exe, it is called teambuild.exe, and you need to have http://apptier not just apptier as the server name parameter.