Thursday, October 29, 2009
We recently had
Stephen Toub, a Senior Program Manager on the Parallel Computing Platform team at Microsoft, swing by our office and walked us through some really cool ways to start implementing parallel programming using Visual Studio 2010 and the 4.0 Framework. I'm thankful that I had the opportunity to attend this, it was one of the best presentations I've ever seen. It's exciting to see the technology evolving :)
Anyway, during his presentation we caught a lot of Visual Studio 2010 Beta 2 in action. There's a bunch of cool improvements and everything seems a lot faster and more responsive. TFS 2010 is also available for download on Microsoft's web site. The links have been changing around since it's been released but here's where it's all currently at:
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx
Check it out!
- mike
Wednesday, September 16, 2009
Team Foundation Server allows you to see who has what file checked out at any time. If you would like to see a list of files that any TFS User has checked out, follow the steps below:
- Open Visual Studio 2008 > Click File > Source Control > Find In Source Control > Status
- Select "Display all checked out" or "Display files checked out to" (to filter changes by user)
- Hit Find
The screenshots below show the type of results you should expect. Another great way to get this info is by using
Team Foundation Sidekicks. If you go this route, you will be able to export the results to a spreadsheet to make them easier to work with. I had to use this the other day to generate a list of all files that were checked out by multiple users. It was easy to work with the data once I got it in Excel. If you prefer getting these results from the command line, you can use the
tf status command in the Visual Studio 2008 command prompt as another option to view pending changes by TFS Users.
If you ever need to undelete a file/folder in TFS, here's how you can do it. I found a couple of people who didn't know this feature existed so I figured I'd throw a blog up about it.
- Open Visual Studio > Click Tools > Options > Source Control > Visual Studio Team Foundation Server
- Check Show deleted items in the Source Control Explorer, hit OK
- Right click on deleted file/folder in Source Control Explorer
- Click Undelete
- Check In
Tuesday, September 15, 2009
In one of our meetings the other day a few developers on our team asked if there was an Auto Shelve feature in TFS to shelve their pending changes automatically each night. I couldn't find anything in the Visual Studio 2008 IDE that allowed us to do this. After some research, I did find a work around.
Basically, I just created a batch file that uses the
Visual Studio 2008 Command Prompt to run
tf shelve on the highest level folder of your local TFS workspace mapped on your C drive. It uses tf shelve to create a TFS shelveset called "Daily Backup - Your Name". It will replace that same shelveset every day with all your current changes (or however often you have the Windows Scheduled Task runs).
This way, you will always have a backup copy of your daily changes. It's always nice to be on the safe side, even if you think you don't need it. A few developers have had their machines crash on them and had to have the machine re-imaged. This would have came in handy back then. I could have built a custom TFS add-in or app, but I figured this was extremely easy to just use a batch file and windows task. Anyway, to set this up, just follow the steps below:
- Open notepad and paste these two lines in:
call "C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
tf shelve "Daily Backup - YOUR_NAME" /noprompt /replace > "C:\TFSBackupLogFile.txt"
- Edit the title in the 2nd line to include your name and edit the path at the end of the 2nd line to map the log file
- Save the file to your desktop (or anywhere you'd like) and name it TFSBackup.bat
- Click Start > Control Panel > Scheduled Tasks > Add Scheduled Task
- Walk through the scheduled task Wizard and point it to the TFSBackup.bat file you created
- Set the Task to run daily at whatever time you want
- Run the task to make sure it runs executes the bat file successfully and check TFS to make sure your shelveset was created
You can view TFS Shelvesets by opening Visual Studio > File > Source Control > Unshelve Pending Changes.
Thursday, September 03, 2009
If you're accessing work items in Team Foundation Server from the Visual Studio IDE, you will end up using this plugin more than you might think. I'm surprised they only have 3194 downloads. It basically does exactly what it says. You can either type in a work item ID to immediately bring up the work item, or type in text to search through work items (like a word or two that would be in the Title or Description). If you're using Visual Studio 2008, check it out. Here's the link to where it lives on codeplex:
http://searchworkitems.codeplex.com/
- mike
Monday, August 10, 2009
If you're a big search junkie, check out this site: http://www.bing-vs-google.com/. It's the best comparision tool that I've seen out there so far that will really let you see the differences between the two huge search giants in the industry.
Developers love tools :)
.jpg)
.jpg)
Wednesday, August 05, 2009
Using TFS and Team Build to deploy to Development, Integration, QA, Stage, Pre Production, or any other testing servers you have can be quite a bit of a challenge sometimes. I haven't really found a lot of documentation or best practices out there for it either. There are plenty of ways to move the files across each environment. I'm going to try this build definition out for a while and see how well it works.
When I queue a new build definition up, I'm going to pass in the following parameters (they will be different each time I queue a new build so I can specify exactly what I need):
/p:GetVersion=C1306
/p:DeployTo=Dev
These parameters are used to tell my build definition which source control version I want to build and which environment I want to deploy the files to. The GetVersion parameter can accept a changeset number, label, date, "W" (Version last fetched to your workspace), or "T" (latest version). The DeployTo parameter can accept Dev, QA, or Stage. You can also default the parameters by setting the values in the .rsp file. See the following links for more information on how these are being used:
Building a Specific Version with Team Build 2008
MSBuild Conditional Constructs
Here's a sample build definition that uses the parameters:
<?xml version="1.0" encoding="utf-8"?>
<!-- DO NOT EDIT the project element - the ToolsVersion specified here does not prevent the solutions
and projects in the SolutionToBuild item group from targeting other versions of the .NET framework.
-->
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ProjectExtensions>
<ProjectFileVersion>2</ProjectFileVersion>
<Description></Description>
<BuildMachine>TFSRTM08</BuildMachine>
</ProjectExtensions>
<PropertyGroup>
<TeamProject>MikeTFS</TeamProject>
<BuildDirectoryPath>c:\bw\-1</BuildDirectoryPath>
<DropLocation>\\UNKNOWN\drops</DropLocation>
<RunTest>false</RunTest>
<RunCodeAnalysis>Never</RunCodeAnalysis>
<WorkItemType>Bug</WorkItemType>
<WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>
<WorkItemTitle>Build failure in build:</WorkItemTitle>
<DescriptionText>This work item was created by Team Build on a build failure.</DescriptionText>
<BuildlogText>The build log file is at:</BuildlogText>
<ErrorWarningLogText>The errors/warnings log file is at:</ErrorWarningLogText>
<UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>
<AdditionalVCOverrides></AdditionalVCOverrides>
<CustomPropertiesForClean></CustomPropertiesForClean>
<CustomPropertiesForBuild></CustomPropertiesForBuild>
<SkipWorkItemCreation>true</SkipWorkItemCreation>
</PropertyGroup>
<Choose>
<When Condition=" '$(DeployTo)'=='Dev' ">
<PropertyGroup>
<DeployPath>\\MikesDevServer\Websites\MikesWebApplication</DeployPath>
</PropertyGroup>
</When>
<When Condition=" '$(DeployTo)'=='QA' ">
<PropertyGroup>
<DeployPath>\\MikesQAServer\Websites\MikesWebApplication</DeployPath>
</PropertyGroup>
</When>
<When Condition=" '$(DeployTo)'=='Stage' ">
<PropertyGroup>
<DeployPath>\\MikesStageServer\Websites\MikesWebApplication</DeployPath>
</PropertyGroup>
</When>
</Choose>
<ItemGroup>
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../Development/Websites/MikesWebApplication/MikesWebApplication.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
</ItemGroup>
<ItemGroup>
<ConfigurationToBuild Include="Release|Mixed Platforms">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Mixed Platforms</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
<Target Name="AfterDropBuild" >
<!--Delete Previous Deployment-->
<CreateItem Include="$(DeployPath)\**\*.*" Exclude="$(DeployPath)\**\Web.Config">
<Output ItemName="PreviousDeployment" TaskParameter="Include" />
</CreateItem>
<Delete Files="@(PreviousDeployment)" ContinueOnError="true" />
<!--Define New Deployment Files To Be Copied-->
<ItemGroup>
<Compile Include="$(DropLocation)\$(BuildNumber)\Mixed Platforms\Release\_PublishedWebsites\**\*.*"
Exclude="$(DropLocation)\$(BuildNumber)\Mixed Platforms\Release\_PublishedWebsites\**\Web.Config"/>
</ItemGroup>
<!--Deploy-->
<Copy SourceFiles="@(Compile)" DestinationFolder="$(DeployPath)\%(RecursiveDir)"></Copy>
</Target>
</Project>
Hope this helps! Leave me some feedback if you get a chance. Thanks everyone.
Monday, August 03, 2009
A few days ago I needed to delete all files except for web.configs out of a deployment folder using Team Build. I added the code below to the build definitions .proj file. It's a quick and easy way to clean out some, but not all, of the files in the deployment folder. You can use wildcards in the CreateItem tag. It's not perfect because it isn't made to deal with deleting empty sub folders but it got the job done for what I needed.
<PropertyGroup>
<DeployPath>\\MikesServer\Websites\TestWebsite</DeployPath>
</PropertyGroup>
<Target Name="AfterDropBuild" >
<CreateItem Include="$(DeployPath)\**\*.*" Exclude="$(DeployPath)\**\Web.Config">
<Output ItemName="PreviousDeployment" TaskParameter="Include" />
</CreateItem>
<Delete Files="@(PreviousDeployment)" ContinueOnError="true" />
</Target>
There are a few other ways you can clean out a folder. The
delete task is the one I used above.
An easy way to delete everything is to use the
<RemoveDir Directories="$(OutputPath)\dir" /> and
<MakeDir Directories="$(OutputPath)\dir" /> tags. You can also use a MSBuild tasks library such as
SDC Tasks and use the CleanFolder task to delete everything in a folder.
Thursday, July 02, 2009
All of our developers have recently been dealing with a lot of
shelving and unshelving in Team Foundation Server to share code. When unshelving shelvesets, we get prompted to fill in an Owner name text box. If you don't know the owners user name, an easy way to search through shelvesets is by entering an asterisk in the Owner name text box and then pressing the find button. This wildcard will bring up all the shelvesets available for you to unshelve. It's a handy little trick when you need to broaden your search.
I thought this was a pretty common known trick among TFS users but I've found more and more people didn't even know this existed, so I figured I'd throw a blog up about it. Hope that helps.
- Mike
Saturday, June 20, 2009
We've recently implemented a new branching strategy for our Team Foundation Server's Source Control. It was a great idea that's working out well but it caused a few problems with our Continuous Integration builds. The builds were failing with this error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
It's a pretty common error and I'm sure most of you build engineers have seen this before. Keep in mind that this is not a TFS limitation, it is caused by a Windows limitation. An easy way to fix this it to change the working directory of your Build Agent:
- In your Team Explorer 2008 window, right click on the Builds folder
- Click on Manage Build Agents
- Make sure your build agent is highlighted and click the Edit button
- Change the default working directory from $(Temp)\$(BuildDefinitionPath) to C:\b\$(BuildDefinitionId)
This will give you a lot of extra characters for your build server to work with. The file path still needs to be under 260 characters though. If you're wondering which C drive this references, it's the C drive on your build server. By changing this I've shortened the working directory path:
- From: C:\Documents and Settings\tfsBuild\Local Settings\Temp\MikeTFS\Development - MikesProgram
- To: C:\b\1
You can delete everything out of the old working directory to free up some space on the build server if you're no longer using those builds.
So that should fix the issue. I did also want to give a little more information on working directories. Working directories are stored on your build server. The working directory can be referenced by each build definition. Each time a new build is queued, a working directory folder will be created or modified under
C:\b\$(BuildDefinitionID). Three sub folders are created inside this working folder (Binaries, BuildType, and Sources):
Binaries folder: Contains the binary output from the build
BuildType folder: Contains the build log and MSBuild files (TFSBuild.proj, TFSBuild.rsp, TFSBuild.tbrsp)
Sources folder: Contains the files downloaded to the build server mapped by the build definition you set up. See below.
For example, for the sources folder, TFS will perform a GET on the workspace you specify in the build definition and place all the files into
$(SourceDir), which in our case would be
C:\b\1\Sources. It uses these files to build your application on the build server. So it's important that each build definition is mapped out correct. You can also only map the workspace working folders that you need in order to speed up your build.
Hope this helps! Leave me some feedback if you get a chance. Thanks everyone.
- Mike