For the most part, getting started is pretty straightforward. However, there are a few gotchas. In general, you want a dedicated server to do the team builds. To get started with that, you need to install the build agent on that machine. The installation bits are on the Team Foundation Server install disc. The important part here is to set up the build service to run under an account that has access to TFS. If you screw this up the first time, just go into services and change the username / credentials for the "Visual Studio Team Foundation Build" (don't forget to restart the service).
After you've installed that, you need to set up your workspace. I followed Buck Hodge's advice on getting that going.
Now, some special cases. If you are signing any of your assemblies with a .pfx key, you'll want to import that onto the local machine. Here's some advice.
Another item to keep in mind is that the solution will be built with a slightly different folder structure. This can cause problems if you have a post build step that copies files (e.g. if you have some plug in type files that aren't directly referenced by the main application project but the app needs them to run).
This approach work fine on the local machine, but not on the build server. To make something like this:
copy "$(TargetPath)" "$(SolutionDir)MyApp\bin\Debug"work on the build machine, you can do something like this:
IF EXIST "$(SolutionDir)MyApp\bin\Debug" copy "$(TargetPath)" "$(SolutionDir)MyApp\bin\Debug"That should work in most cases (your mileage may vary).
I haven't tried setting up an unit tests to run automatically. If / when I'll do, I'll likely post about that too.
1 comment:
very good post, i actually love this web site, keep on it gsn casino slots
Post a Comment