New Visual Studio 2010 CTP

Microsoft just released a new CTP of Rosario, now officially known as Visual Studio Team System 2010. It comes in 11 (!) parts so you'll either want to use Firefox or Free Download Manager or some other utility to get it. Enjoy!

UPDATE: Jeff Beehler (same initials!) has posted a great rundown of the new walkthroughs in this CTP.

jb

Not @ PDC 2008?

If you're like me, you're probably not at Microsoft's Professional Developers Conference (PDC2008) in LA right now. Fear not! There are options for virtual attendance! Free! Just in the last 24 hours I've seen tons of content out there available to the masses.

Check out the MicrosoftVSTS feed on Twitter for some official tweets including quotes from some of the panel discussions. It's like you're there!

A group called NotAtPDC has started up with a variety content mediums including a website, a Twitter feed, and a Facebook group. Thanks to them, I learned about the new .NET logo! Nice!

jb

TF30063: You are not authorized to access...

Ever try to delete a team project and get the above message? Are you in the Team Foundation Administrators group and scratching your head? I thought TFS admins could do everything! So I finally decided to get a clear understanding of the root cause of this problem.

The resolution is simple: add your account to the site collection administrators for the SharePoint project portal (described here). You can also do this as a Farm Administrator under the Application Management section in Central Administration. Hopefully, as a TFS admin, you've been added to the Farm Administrators group in SharePoint. The nice thing about the Farm Admins group is that it supports AD groups. The site collection administrators, however, does not. From Central Administration, you can specify a primary and secondary site collection administrator. Within the settings for the project portal site, you specify additional users, but you cannot specify groups.

Why can't Farm Administrators admin site collections by default? That's just the way it is. TechNet has a great article describing how SharePoint security works. The key content is as follows:

"Members of the Farm Administrators group have no administrative access to individual sites or their content by default. However, they can take control of a specific site collection to view any content. For example, if a site collection administrator leaves the organization and a new administrator must be added, farm administrators can add themselves as site collection administrators, which action is recorded in the audit logs."

So there it is. In short, the MSDN entry on TFSDeleteProject should include a prerequisite step to make sure you have site collection administrator permissions before running the command.

jb

New MSBuild Extension Pack

Brian Harry posted today about a new MSBuild Extension Pack project on CodePlex. I figured this would be a good opportunity to demonstrate how you can use it to version the assemblies in your builds. Here are the steps for setting up assembly versioning for your builds using the MSBuild Extension Pack.

1. Download and install the MSBuild Extension Pack on your build machine(s).
2. Create a base target file with the following XML:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
<Import Project="$(MSBuildExtensionsPath)\ExtensionPack\MSBuild.ExtensionPack.tasks" />

<!-- ASSEMBLY VERSIONING -->
<PropertyGroup>
<AssemblyMajor>1</AssemblyMajor>
<AssemblyMinor>0</AssemblyMinor>
</PropertyGroup>

<Target Name="GenerateAssemblyVersion">
<!-- Get a version number based on the elapsed days since a given date -->
<!--TfsVersion TaskAction="GetVersion" BuildName="$(BuildDefinition)" TfsBuildNumber="$(BuildNumber)" VersionFormat="Elapsed" StartDate="17 Nov 1976" PaddingCount="4" PaddingDigit="1" Major="$(AssemblyMajor)" Minor="$(AssemblyMinor)">
<Output TaskParameter="Version" PropertyName="AssemblyVersion" />
</TfsVersion-->
<!-- Get a version number based on the format of a given datetime -->
<TfsVersion TaskAction="GetVersion" BuildName="$(BuildDefinition)" TfsBuildNumber="$(BuildNumber)" VersionFormat="DateTime" DateFormat="MMdd" PaddingCount="5" PaddingDigit="1" Major="$(AssemblyMajor)" Minor="$(AssemblyMinor)">
<Output TaskParameter="Version" PropertyName="AssemblyVersion" />
</TfsVersion>
<Message Text="New Version is $(AssemblyVersion)" />
</Target>

<Target Name="VersionAssemblies">
<!-- Run the CreateItem task to populate the group after the source code has been downloaded. -->
<CreateItem Include="$(SolutionRoot)\**\AssemblyInfo.cs">
<Output TaskParameter="Include" ItemName="FilesToVersion" />
</CreateItem>
<!-- Set the version in a collection of files -->
<TfsVersion TaskAction="SetVersion" SetAssemblyVersion="true" Files="%(FilesToVersion.Identity)" Version="$(AssemblyVersion)" />
</Target>
</Project>

3. Save the file and copy it out to the MSBuild directory under Program Files on your build machine(s).

The GenerateAssemblyVersion target shows a couple of ways to use the GetVersion action of the TfsVersion task to generate different assembly version formats. The task has several attributes that allow you to customize the format to fit your needs. Check out the help file included with the MSBuild Extension Pack installation for more details.

To actually use this functionality in your builds, just add the following XML to your TFSBuild.proj files.

<Import Project="$(MSBuildExtensionsPath)\My.TeamFoundation.Build.targets" />

<PropertyGroup>
<AssemblyMajor>3</AssemblyMajor>
<AssemblyMinor>5</AssemblyMinor>
</PropertyGroup>

<Target Name="AfterGet">
<CallTarget Targets="GenerateAssemblyVersion;VersionAssemblies" />
</Target>

Here, you override the base values of the AssemblyMajor and AssemblyMinor properties from your base target file. In addition, you're overriding the built-in AfterGet target that is part of Team Build to call the custom targets in your base target file. This keeps the amount of duplicated MSBuild script very low.

UPDATE: Mike Fourie has a great post on some additional things you should consider when setting up assembly versioning in your builds. Of note is the separation of the AssemblyVersion and AssemblyFileVersion attributes when working with strong-named assemblies.

jb