Contents tagged with Team System
-
March 2008 TFS/Team Suite Download List
Just what I was looking for - a list of all the URLs to the VPC-parts, easy to add to a download manager. Steve got the links from Martin Danner and I'm passing the links on :)
Martin Danner has passed along a list of the URLs to use to download the TFS/VSTS 2008 Trial VPC using Free Download Manager. Just copy the list and paste (using Ctrl+Shift+V) into Free Download Manager then wait...
This VPC includes Office 2007 SP1, all Windows Updates and the December 2007 power tools. It also contains 38 hands-on labs for your learning pleasure. The VPC is set to expire on Dec. 31, 2008.
-
[Team System] TFS 2008 - Better Build Support, But Good Enough?
I picked up the blog post written by Buck Hodges today about some of the new features related to Build in TFS 2008. I'm glad to see CI built into the product and better control of the build process as well as better support for editing the build steps. Not that I fear editing some XML, but GUI support is always welcome as long as you can do some 80% of what you normally need to do in that interface.
The build support in TFS 2005 is, compared to some other build servers out there, not top notch. When we started a version 2 of a project just recently, I moved our whole build process to CruiseControl.NET. It took me a day or so to get the basic structure of 10+ solutions (and CI projects) to build and deploy. The same stuff took me days and days to set up in TFS. So now we're building and deploying wcf services, generating data contracts from schemas, generating service proxies from those services and even generating service proxy documentation with reflection. Everything controlled by Cruise Control. And I like cctray :)
It looks like MS is trying hard to step up to the features offered by solutions like CC.NET, but I think it will take some real effort to make developers used to CC, NUNIT and NANT to make the final move.
-
[Team System] Team Foundation Server Power Tools February Release
Rob Caron just wrote:
The February release of the Team Foundation Server Power Tool is now available for download. Formerly known as the Team Foundation Power Toy, these utilities pack too much punch to be considered toys.
I'm very interested in the "Test Tools Build Task". Seems to be what I'm looking for.
-
[Team System] Team Building Web Application Projects and Deploying
I've been battling with Team Build and Web Application Project (WAP) solutions. I first thought that Web Deployment Project (WDP) was the way to go, but I found out the hard way that WDP + WAP + Team Build isn't best mates.
What I want to do is to build a number of solutions (which includes a bunch of projects) and after the build has completed, xcopy the web applications to a specific place, like under IIS webroot.
There are many, many different solutions to this scenario, but I think it's a very common one. Here's what I'm thinking of doing now. Step by step dummy:
1. I create a TFS project "WebApplication1"
2. I create a solution called "WebApplication1" with 2 projects in it; "WebApplication1" (WAP) and "LibraryX" (Class library), I create some dummy code where a web page calls some code in the class library (mostly for fun).
3. Compile and test.
4. I add the solution to SourceControl.
5. I then create a new Team Build called "WebApp1".
6. Go to Source Control Explorer and check out the TFSBuild.proj file for edit, then double click it to edit.
7. Page down to the end of the build file and add (before the </Project> tag):
<ItemGroup>
<WebFiles Include="$(BinariesRoot)\Release\_PublishedWebsites\**\*.*"></WebFiles>
</ItemGroup>
<PropertyGroup>
<DeployWebDir>c:\websites</DeployWebDir>
</PropertyGroup>
<Target Name = "AfterDropBuild" >
<RemoveDir Directories="$(DeployWebDir)" Condition="Exists('$(DeployWebDir)')" />
<MakeDir Directories="$(DeployWebDir)" Condition="!Exists('$(DeployWebDir)')" />
<Copy
SourceFiles="@(WebFiles)"
DestinationFiles="@(WebFiles->'$(DeployWebDir)\%(RecursiveDir)%(Filename)%(Extension)')"
/>
</Target>What the stuff above does is that it declares what files to copy (WebFiles) and where these files should go (DeployDir). Then there's a Target section which is called by Team Build after the drop has been made (AfterDropBuild) that removes the old files and copies the files from WebFiles to DeployDir. The $(BinariesRoot) property points to where the files have been built. WAP files are always built to the _PublishedWebsites\<project> directory.
My web application is now deployed to c:\websites\WebApplication1\ and I'm manually creating an IIS virtual directory which will always be pointing at this directory.
There are a number of additional things you might want to do as well, but I just wanted to show you a very simple way of always copying WAP files to the same place after a build.
If you don't want to use the Tean Build drop directory at all, you should be able to skip that step by setting the SkipDropBuild property to true in the TFSBuild.proj file.
MSBuild / Team Build Resources:
List of targets that can be customized in Team Build (like AfterDropBuild in my sample):
http://msdn.microsoft.com/en-us/library/aa337604(VS.80).aspx
MSBuild Task reference:
http://msdn.microsoft.com/en-us/library/7z253716.aspx
Brennan's blog with a 7 step tutorial on MSBuild:
http://brennan.offwhite.net/blog/2006/11/29/msbuild-basics-1of7/
How to create your own MSBuild task:
http://msdn.microsoft.com/en-us/library/ms400767(VS.80).aspx
-
[Team System] Getting Rid of Default Document Folders in the Quick Launch Bar
I just recently blogged about how to display document folders in the Quick Launch area of the TFS Sharepoint portal. Here's a follow-up to that one on how to remove the default folders which are created when you set up a new Team System project. It's all about modifying the Sharepoint template. You should only try this if you are creating a custom Team System Process Template.
1) Create a new test-project in Team System, don't bother to add any source control to it.
2) In Team Explorer, remove the Document folders and files you're not interested in. This will be reflected on the project portal. As is explained in detail at the MSDN site, you must also edit the Process Template XML files to reflect these changes to the template content. While at it, you may also delete any reports you don't want (or add for that matter), but again - modify the template XML files to reflect this. I'm pretty sure it will still work well, but you never know, things will probably be messed up if you don't. If you change the portal content, change the XML files (repeat as a mantra).
3) On the project portal, go to "Site Settings", "Go to Site Administration" and click "Save site as template". This will create an .stp file on the portal that you can download and put anywhere on your Team Foundation Server for now. Write down the name of the Sharepoint template because you need it in the following steps.
4) The rest about how to add the template to the server and so on is well described on the TFS site on MSDN. In short - Go to the server, add the template to the TFS by using the stsadm.exe tool and pointing at your .stp file. Then get back you your lovely Process Template files and refer to it (by name) in the <site> section of the WssTasks.xml file.
5) Now, upload the new Process Template to TFS, create a new project and see if it looks alright.
As I wrote earlier, to change the overall look and feel of the Sharepoint portal, you still need to use Frontpage, but that is something I will go into later.
-
[Team System] Displaying Document Folders in the Quick Launch Bar
Some people who are editing their Team System process templates and are new to Sharepoint wonder how to publish their own document folders in the menu of the portal home page. There are at least 2 ways - either use Frontpage (which I haven't tested yet), or in Sharepoint go to "Documents and Lists", click the folder in question, click "Modify settings and columns" in the left hand menu and then "Change general settings" and tell it to "Display this document library on the Quick Launch bar".
To modify the Quick Launch bar when it comes to reports and such, I think Frontpage is the tool. I'll try that as soon as I get Frontpage installed... not even sure which version of Frontpage to use actually.
Last thing to do is to modify the Sharepoint portal template in a way that suits the new process template, then create a new template out of it, make sure it's installed on the Team System server and then point at it from the WssTasks.xml file:
<site template="Your_Sharepoint_template" language="1033" />
Who said creating your own process template for TFS was easy? :) I'll get back to this process in a later post.
-
[Team System] Great Tool for Modifying Process Template
I found a great tool for those of you who wants to modify the process template - Process Template Editor from imagiNET, and it's free. It won't see to all your needs, but it's a great help and the best tool I've seen so far to get you started. You still need to do some manual XML editing if your goal is to create a completely new template, and I still need to find a good way to modify the document folders and the content within there. So far I've been editing the WssTasks.xml file by hand, and it *beeps*... :)
-
[Team System] Migrating Code From VSS to VS2005 and Team Foundation Server
UPDATE: I really, really recommend that you check out this GUI for VSSConverter at http://www.epocalipse.com/blog/2006/04/06/vssconverter-gui/ It was created by Eyal Post and it works like a charm!
We recently tried to migrate old VS2003 code from VSS to VS2005 and Team Foundation Server using the vssconverter utility that ships with Team System, and it worked pretty well... after a while.
It's pretty straight forward if you follow the guideance on this page, http://msdn.microsoft.com/en-us/library/ms253060.aspx, but I really recommend you make sure the old code and VSS database is backed up first and that you try the migration to a test-project first.
We set up a local VSS database on a client machine and moved (via archiving) the code to that local database first. Then we ran the analyze, test migration, tweaked the user mapping file and then finally kicked off the migration to the production TFS project. It worked without any major problems except that we had to be logged in as a user on the domain and with proper right to the team project. But it's all in the TFS documentation on MSDN... somewhere :D
What may be somewhat itchy is the work you may get into after that, when you open up old solution and project files. It may be that VS2005 fails to load the old project files, but try to do a "get latest" and check out the .vbproj and .csproj files, then try to reload the projects. Good luck!
UPDATE: It looks as if the best way to open up a migrated solution is to locate the solution file in the Source Control Explorer window and double-click it. I will probably ask you to re-bind the projects, so do that and they should "connect" automatically. Make sure you have "Visual Studio Team Foundation Source Control" selected as your Source Control Plug-in in Tools->Options. It happens that the plug-in selection reverts back to VSS sometimes when the solution is opened.
-
[Team System] How to Delete a TFS Team Project
There are several ways to delete a TFS team project, but not via the Team Explorer. Steven Smith writes:
If you need to delete a Team System Project you need to do it through a command line utility that is installed with Team Explorer. In my case, I created a test project but wanted to also test project deletion. There is no way to delete a project from Team System except through the command line tool, TFSDeleteProject.exe. This utility is in the c:\program files\Microsoft Visual Studio 8\Common7\IDE\ folder by default. To delete a project, use the following syntax:
TFSDeleteProject /server:ServerName ProjectName
Julien Lavigne got a utility which does the same thing via a web service.
-
[Team System] How to Delete a TFS Build Type
To delete a build type
1. On the View menu, click Other Windows and then click Source Control Explorer.
2. In the Folder pane of the Source Control Explorer, locate the build type that you want to delete in the ${Team Project}\Team Build Types\{Build Type Name}\TeamBuild.proj tree. The build type is represented by the TeamBuild.proj file, but you need to delete the folder as well.
3. With the desired build type folder selected, choose Delete from the shortcut menu. You will also need to check in the changes that were made to the directory. The build type entry is deleted and the action removes all underlying XML files.Good shortcut for how to manage Build Types in TFS -> Working with Build Types in Team Build
I also found good info about deleting build types on the Vertigo's Team System blog -> http://blogs.vertigosoftware.com/teamsystem/archive/2006/05/03/Deleting_Team_Build_Types_and_Team_Builds.aspx