Welcome to MN VSTS User Group Sign in | Join | Help
Wednesday, November 01, 2006 1:23 PM

Team Build Solutions -- missing the obvious.

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. 

Read-only nag dialog

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. 

Sample Build Solution 

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

 

 

Posted by dzimmerman | 0 Comments
Friday, October 20, 2006 1:51 PM

Signing Assembly Tricks

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. 

 Restart build service

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

Posted by dzimmerman | 0 Comments
Monday, October 16, 2006 11:43 PM

Must-have Links

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:

Blogs:

Helpful MVPs:

Must have Utilities:

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. 

MsBuild

Version Control

Posted by dzimmerman | 0 Comments