MN VSTS User Group

Save yourself some heartach

cdpratt — Wed, 20 Dec 2006 18:00:00 GMT

Since you do not get the latest version by default when you check a file out of TFS, it is easy to forget and make changes to a version that is out of date. Most of the time it is just a matter of merging your changes when you check the file back into source control, but at other time it could be more difficult.

In order to avoid the situation I have changed my settings in Visual Studio to always get the latest version when opening a project or solution. This ensures that I always get the latest code changes that other developers have made. The setting to accomplish this is shown in the figure below.

Team Build Solutions -- missing the obvious.

dzimmerman — Wed, 01 Nov 2006 17:23:00 GMT

On the outside chance that I'm not the only that missed the obvious:

I've worked on-and-off for months now with teambuild projects and it is a bit of slow process given the need to check-out and check-in the .proj, .rsp, and .xml everytime you want to test a change to your script. In addition, it's a pain, because every time I go to save I always get nagged that my file is read-only.

When you're developing other code, the development enviornment automatically handles the check-out for you on edit, so I'm just not in the habit of being explicit. Finally, it occured to me to just add these items to a solution and save the solution in the TeamBuildTypes folder along with those files and now it works great.

It seems like a small thing, but it's just a hassle I'm glad to have behind me.

Signing Assemblies with a Common Key File

cdpratt — Fri, 20 Oct 2006 20:36:00 GMT

Microsoft recommends that all assemblies be assigned a strong name by signing them with a key file. It is further recommended that only the build process be allowed to sign assemblies for distribution with a private key.

In order to meet these requirements with a minimum of inconvenience to developers you can allow developers to fully sign assemblies with a developer’s key and reserve the signing with the production key for the build box. An easy way to accomplish this is to create an environment variable on the developer’s machines that points to the developer’s key and change the value of this environment variable on the build box to point to the production key file.

The following steps are intended to help step you through the process of setting up an environment variable that points to the DeveloperKey.snk file and to then alter the project file to use this variable. Setting up the environment variable will only need to be done once on your machine and altering the project file will only need to be done when you first create a new project.

Step One, Open System Properties Dialog.

The figure below shows the advanced tab of the System Properties Dialog. You can access this dialog by selecting the system icon from the control panel

Step 2, Open Environment Variables Dialog

Click the Environment Variables button to open the dialog as shown in the figure below.

Step 3 Create a new variable

Click new under the user variable section of the dialog to open the New User Variable dialog shown below. Enter the values shown below, KEY_FILE for the variable name and D:\IT\Object\Lib\DeveloperKey.snk for the variable value.

This completes the process of creating an environment variable. This is a one time event. As long as the DeveloperKey.snk file appears on your machine everything should compile and be strongly named with your key.

The only other task to discuss on this topic is the alteration to a project file that must be done to take advantage of this environment variable. This task only needs to be done once for each project as the project is created.

Check the project file out of source control for editing.
Open the file in an editing tool. You can use Visual Studio as long as you do not already have the project open.
Change the SignAssembly tag to true as shown in the figure below.
Change or Add an AssemblyOriginatorKeyFile tag to specify the environment variable $(KEY_FILE).
Check the project file back into source control.

The altered file is shown in the figure below

Signing Assembly Tricks

dzimmerman — Fri, 20 Oct 2006 17:51:00 GMT

One of the early frustrating features of 2005 initially was the deprecated ability to specify where your strong name key was in the assembly.info file. In .Net 1.0 -> 1.1 a best practice was to make the location of this .snk file a single location. This helped for code generation purposes and more importantly it made it much easier to change the signature in the future by simply creating a new .snk and dropping it to that same location that all the assembly.info files pointed to. Developers would reference a delayed sign version of the .snk file, and the build machine had the official version.

Now most people understood the reason for making this information more hidden from deployed applications, but VS2005’s answer to this seemed to be that you have your key files referenced locally from every project – resulting in key files sprinkled all over your source tree.

Finally, a Microsoft blog article came out showing you how to work-around this issue with linking. Better yet (in my opinion) was the follow on comment by Mitch demonstrating how you could do it with an environment variable. (See my colleague Chris Pratt’s step-by-step details about this – link pending). I love this answer because it avoids the hassles/security issues of delayed singing which requires that all the developer’s run the command to always trust assemblies signed only with a well-known public key. This solution is even better than 2003 days, because anyone can put the .snk anywhere as long as they specify it in the environment variable (although it makes sense to standardize for developers)—and developers can compile whether they’ve done this step or not.

One important caveat about getting this to work on the build machine. Because the compiler doesn’t complain if the .snk file isn’t there, your build box happily builds even though it may not be strongly naming the components. When you create the environment variable on your build box, make sure to RESTART the Team Build service on that box so it can find your new environment variables.

Buck Rodgers to the rescue!!! I mean Buck Hodges to the rescue!!!

Must-have Links

dzimmerman — Tue, 17 Oct 2006 03:43:00 GMT

While Google Searches can help, there is still something in knowing where some primary sources are. This is by no means an exhaustive list, but it’s a start which is better than “not-a-start” (my anti-pattern of a successful blog):

Where to Start:

If you’ve got a question, you go here first: http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=5&SiteID=1
Then here of course: http://msdn2.microsoft.com/en-us/library/ms181232.aspx
Official Known Issues: http://msdn.microsoft.com/vstudio/teamsystem/tfsknownissues.aspx

Blogs:

Key team system guy at Microsoft http://blogs.msdn.com/robcaron/default.aspx
Nice, mature blog/forum site http://teamsystemrocks.com/
You gotta like the name, and he has been a very reliable, dedicated inside source from Microsoft on the nitty gritty of what works and what doesn’t. http://blogs.msdn.com/buckh/default.aspx
Nice tips & tricks: http://blogs.vertigosoftware.com/teamsystem/default.aspx:
MSBuild: http://blogs.msdn.com/msbuild/

Helpful MVPs:

Marcel de Vries: http://blogs.infosupport.com/marcelv/default.aspx
Martin Woodward: http://www.woodwardweb.com
Mickey Gouseet: http://teamsystemrocks.com/blogs/mickey_gousset/default.aspx

Must have Utilities:

TFS PowerToys (Now with many features seamlessly integrated into the IDE): http://www.microsoft.com/downloads/details.aspx?FamilyId=3F21144A-4E98-4CE0-830F-D1F3E8AC9D67&displaylang=en
These guys did us all a big favor in filling in some of the GUI wholes of the 1.0 product

http://www.attrice.info/downloads/index.htm. My order of usefulness:

1. This bundle is a must: http://www.attrice.info/cm/tfs/index.htm

2. This is useful for exploring the endless rabbit hole of MSBuild imports http://www.attrice.info/msbuild/index.htm

3. Others, optional.

You can get used to editing the XML after a while, and sometimes you still have to, but here’s a great graphical UI for it, and the layout tab saves hours!: http://www.gotdotnet.com/workspaces/workspace.aspx?id=812a68af-5e74-48c6-9623-1a4469142a84
SDK Downloads – Used to be critical for TFS powertoys as well , but Microsoft has moved away from this as the primary distribution channel for these utilities: http://msdn.microsoft.com/vstudio/extend/
Admin Tool: I’ve had issues with this tool, but I would feel remiss if I didn’t mention it because some of had more success than me: http://www.gotdotnet.com/codegallery/codegallery.aspx?id=cea30722-cd0a-4ef4-9c75-a5a5e4932b05&newsId=a3f8afe1-9920-43f5-8814-3122d5ec2a90

MsBuild

The overview: http://windowssdk.msdn.microsoft.com/en-us/library/ms171452(VS.80).aspx
(Don’t write your own custom tasks until you’ve perused these:
Out-of-the-box task reference: http://msdn2.microsoft.com/en-us/library/7z253716.aspx
Additional Open Source Tasks from Microsoft UK: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=2cb20e79-d706-4706-9ea0-26188257ee7d
Tigris Open Source MSBuild tasks: http://msbuildtasks.tigris.org/
And, the always popular: “Keep assembly info versioning/info in synch task” (and nice mock build engine for testing.) http://www.gotdotnet.com/codegallery/codegallery.aspx?id=93d23e13-c653-4815-9e79-16107919f93e

Version Control

Gotta start somewhere: http://blogs.msdn.com/mrod/default.aspx
Specifying ultimate merge tools for comparisons: http://blogs.msdn.com/jmanning/articles/535573.aspx

Windows 2003 Firewall with TFS and port 8080 Exception

Davin — Thu, 05 Oct 2006 20:20:00 GMT

Anybody ever have this problem? When I try to connect to my TFS server from my VS Team Suite (VSTS), it states that I cannot connect.

I turn temporarily off the Windows 2003 firewall and try it again - with success! I turn the firewall back on and VSTS continues to communicate just fine with TFS over the exception port of 8080.

When I installed TFS, it automatically created the Firewall Exception for TCP port 8080 but it seems the server discovery process for VSTS needs some other port initially.

What am I missing?

Any tips are greatly appreciated.