Why would you ever want to delete a team project from Team Foundation Server? It contains your changeset and work history, basically everything about your project. Of course, if you were trying to fix an issue with adding team projects, you probably added an unnecessary dummy project that needs to be removed.

I didn’t see a way to delete my test project through Visual Studio, so I turned to my friend Bing to find an expert. Ben Day came to the rescue.

Drop to a Visual Studio 2008/2010 command prompt and enter: TfsDeleteProject /server:<server name> <team project name>

You will then receive the following message.

Warning: Deleting a team project is an irrecoverable operation. All version control, work item tracking and Team Foundation build data will be destroyed from the system. The only way to recover this data is by restoring a stored backup of the databases. Are you sure you want to delete the team project and all of its data (Y/N)?

It goes without saying that you should only type “Y” and press enter if you really want to do this.

A month or so back, a need arose to upgrade Windows SharePoint Services on our Team Foundation Server box to v3 from v2. I do not recall the exact circumstances, but I remember the error in TFS made absolutely no sense and I guessed the upgrade would fix it. I was right… until the other day when someone tried to create a new Team Project.

Error
The Project Creation Wizard encountered an error while uploading documents to the Windows SharePoint Services server on teamserver.

Explanation
The Project Creation Wizard encountered a problem while uploading documents to the Windows SharePoint Services server on teamserver. The reason for the failure cannot be determined at this time. Because the operation failed, the wizard was not able to finish creating the Windows SharePoint Services site.

User Action
Contact the administrator for the Windows SharePoint Services server on teamserver to confirm that the server is running and you have sufficient privileges to create a project. Also, you might find additional helpful information in the project creation log. The log shows each action taken by the wizard at the time of the failure and may include additional details about the error.

Here’s the event description distilled from the log file mentioned in the error.

Event Description: TF30162: Task "SharePointPortal" from Group "Portal" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: The Project Creation Wizard encountered an error while uploading documents to the Windows SharePoint Services server on teamserver.
Exception Details: The Project Creation Wizard encountered a problem while uploading
documents to the Windows SharePoint Services server on teamserver.
The reason for the failure cannot be determined at this time.
Because the operation failed, the wizard was not able to finish
creating the Windows SharePoint Services site.

This error seems to come every now and then when people are doing updates. The reason for this is that the templates no longer match. You will need to install the wss v3 templates. The utility I will be mentioning, stsadm, can be found in %programfiles%\Common Files\Microsoft Shared\web server extensions\12\BIN\.

• Click Site Settings on an upgraded site.
• Click Save site as template.
• Name the file and template the exact, case-sensitive name stored in your Process Template. You can run stsadm -o enumtemplates, and use the first item on each line (e.g. VSTS_MSFAgile).
• Download the file from the site template gallery to a location of your choosing. For these instructions, we will use c:\.
• Delete all of the WSS v2 templates. Using the list from the enumtemplates step, run stsadm –o deletetemplate –title [title]
• Add the WSS v3 templates to the site. Run stsadm -o addtemplate -filename C:\[title].stp -title [title]
• Run iisreset

You should now be good to go!

I’ve had this tendency to deploy CLR Functions manually by providing the dll and scripts to the data management team. This has generally worked out great, and I’ve always thought I’d have a dba available to perform the database duties. Imagine my surprise when I could not contact anyone today. Apparently database administrators take their holidays and vacations seriously (it’s Independence Day weekend for my non-American readers).

Another developer asked me why I couldn’t deploy my clr functions through the IDE. Having never done this, I asked him how. He showed me the deploy button in his project.

I went back to my desk, heartened that I could still get my work done. I opened the Solution, right-clicked the project… but there was no Deploy. Thinking back on it, I know that I tend to make class libraries rather than database projects. I looked at my coworker’s project and sure enough, he was using a database project.

It seemed rather heavy-handed to create a new database project and move files over, so I dug into the csproj file to figure out how to convert it.

There are two key things that need to be done to convert a class library to a database project. SqlServer.targets needs to be imported, and the ProjectTypeGuids property needs to be added.

  <Import Project="$(MSBuildToolsPath)\SqlServer.targets" />
  <PropertyGroup>
    <ProjectTypeGuids>{c252feb5-a946-4202-b1d4-9916a0590387};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
  </PropertyGroup>

It doesn’t matter where these entries are added, but I place the property in the top property group below the Platform property and paste the import near the CSharp.targets import. The first guid in ProjectTypeGuids specifies that this is a SqlClrProject. The second guid specifies this is a C# project. Visual Basic developers will need to replace the C# guid with F184B08F-C81C-45F6-A57F-5ABD9991F28F.

The deploy button now appears but doesn’t work. When clicked, it fails with no more information than “Deploy failed.” Deducing that it probably needs a database connection, I used MSDN to find out where that configuration is located. This is one place the MSDN documentation is misleading.

Select Deploy from the Build menu. The assembly will then be registered in the SQL Server instance and database specified when the SQL Server project was first created in Visual Studio.

This is true only if one has never changed that configuration for the Database project. Since this was a class library converted to a database project, the server and database wasn’t specified when creating the project. Luckily, this can be configured in the Properties window on the Database tab. Be sure to add the connection to Server Explorer (Ctrl+W, L) first.

At this point, the project has been converted and we’re almost ready to deploy. Before doing so, the assembly must be dropped from the database. Visual Studio is smart enough to drop it, but only if the assembly was deployed from Visual Studio in the first place. After the first deployment, it will work automatically in the future.

I was tasked today with fixing the reporting in Team Foundation Server. It hadn’t worked since an upgrade from 2005 to 2008, and it the repair of it was low priority.

Since I worked with alternate software in my previous jobs, I had to research the possible problems. The first step was to figure out what the actual error message was. Browsing the TFS portal from my development box didn’t reveal the necessary information, so I had to browse the portal from the server. Luckily, I had requested the role of configuration management when I joined the team so I had permissions. Here’s the error message.

Reporting Services Error

An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for data set 'IterationParam'. (rsErrorExecutingCommand)
The Team System cube either does not exist or has not been processed.

I binged the last line to discover that it was related to the TFSWarehouse. Typically, this is periodically refreshed by the Visual Studio Team Foundation Server Task Scheduler service, but obviously it wasn’t doing its job. The suggestion I found was to refresh it by using the web services under http://ServerName:Port/Warehouse/v1.0/warehousecontroller.asmx. When you’re there, you invoke the Run operation then invoke the GetWarehouseStatus operation occasionally until it returns Idle.

Well, it returned Idle immediately. I checked the TFSWarehouse database to see if anything had happened, but the latest rows were from the date of the upgrade.

More searching led me to discover a utility called SetupWarehouse.exe located in %ProgramFiles%\Microsoft Visual Studio 2008 Team Foundation Server\Tools.

Since I saw that it would actually rebuild the database, I was sure to do full backups as a precautionary measure. I then executed the commands to rebuild the database and OLAP.

Database:
setupwarehouse -rebuild -mturl "http://ServerName:Port" -s ServerName -d TFSWarehouse -c wareHouseSchema.xml -a TFSServiceAccount -ra TFSReportAccount -edt TfsBuild

OLAP:
Setupwarehouse -o -s ServerName -d TFSWarehouse -c warehouseSchema.xml -mturl "http://ServerName:Port" -a TFSServiceAccount -ra TFSReportAccount

I then executed the the operations on the Warehouse web service. It took around an hour for it to complete, but it was successful.

Yesterday, I wrote about running GacUtil from within the AfterBuild target, due to some constraints with MPF and T4.

I discovered that the path I provided was wrong. It's the only GacUtil.exe under the Microsoft.NET folder, but it won't register the assembly. Since I wasn't sure which path I should be using, I used the GacUtil task from MSBuild Community Tasks. Here is the relevant code it uses to retrieve the path to gacutil.exe:

protected override string GenerateFullPathToTool()
{
    return ToolLocationHelper.GetPathToDotNetFrameworkSdkFile(ToolName, TargetDotNetFrameworkVersion.Version20);
}
protected override string ToolName
{
    get { return "gacutil.exe"; }
}

regpkg : warning : The Assembly specified at [Path]\[Assembly]cannot be loaded because an alternate copy with the same identity exists in the Assembly probing path at 'C:\WINDOWS\assembly\GAC_MSIL\[Assembly]\1.0.0.0__7c2bf94927fd6e28\[Assembly]. The Assembly at 'C:\WINDOWS\assembly\GAC_MSIL\[Assembly]\1.0.0.0__7c2bf94927fd6e28\[Assembly] will be loaded instead.
regpkg : error : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
  Could not load file or assembly '[Assembly], Version=1.0.0.0, Culture=neutral, PublicKeyToken=7c2bf94927fd6e28' or one of its dependencies. The system cannot find the file specified.

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name="BeforeBuild">
   <GacUtil Command="Uninstall" Assemblies="$(TargetName)" ContinueOnError="true"/>
</Target>
<Target Name="AfterBuild" DependsOnTargets="RegisterManagedPackage">
  <!-- .wix is specified instead of .wxi because the RegPkg task requires it to generate the wix script. -->
   <RegPkg ItemToRegister="$(TargetPath)" ProductVersion="$(TargetVSVersion)" SDKVersion="$(VsSDKVersion)" OutputFile="..\Installer\RegistryEntries.wix" Unregister="false" UseCodeBase="false" UseRanu="false" />
   <GacUtil Assemblies="$(TargetPath)"/>
</Target>

Due to circumstances involving a MPF package and Text Templating (t4), I had to add an assembly to the GAC after compiling if I wanted to be able to run the generator in the VS Experimental. So, I added the following line to the AfterBuild target of the csproj file:

<Exec Command="gacutil /i $(TargetPath)"/>

Unfortunately, I received the following error when I compiled: 

Error 155 The command "gacutil /i [PathToDll]" exited with code 9009. C:\Projects\AperioVisualStudioAddins\AperioVisualStudioAddins\AperioVisualStudioPackage.csproj 202 2 [DllName]

The problem is that when Visual Studio is building the project, it does not have access to the path. The way to make it work is to specify the fully qualified path and filename to gacutil.

<Exec Command="C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\gacutil.exe /i $(TargetPath)"/>

In a prior post, I claimed that MSBuild parses a file in order. Further testing shows this is only partially true.

MSBuild loads the project file and any imported files. The imported files are inlined; imagine if the imported file was copied and pasted where the import element is defined. Then, all PropertyGroups are parsed in order. After that, ItemGroups are parsed in order. This means you cannot define a property, use it as metadata in an item, then redefine the property later.

It doesn't matter whether or not you define properties and items above or below a target, the target will use them.

I've been struggling through a Team Foundation Server 2008 install with Sql Server 2008 over the weekend. It seems to be having an especially hard time with the SQL Server Reporting Services. After analyzing a few things, I determined that the configuration tool was having an issue due to some prior installations of software. The report urls were pointing to a SQL Express directory.

I went about setting up the virtual directories manually. This required setting up an application pool, and I assigned my service user to run the pool. After I did that, I had to grant the user write access to the RSTempFiles folder. Then I received an error when browsing the site, "the path is not a legal form."

I couldn't find a site anywhere with a solution, though there was a dead thread on the old msdn forums with the same problem with SRSS. Since the tubes held no hope for me, I had to resort to old fashioned troubleshotting.

If you receive this error, you need to add your application pool user to the SQLServerReportServerUser (followed by $servername$instancename) group. It's that simple, but the error doesn't indicate what is necessary to fix it.

There are scenarios where the situation calls for performing set operations on item collections. You may want to join them together, subtract one from another, or perform an inner join. I originally came up with the idea to demonstrate these from this forum question. These examples work in both MSBuild 2.0 and MSBuild 3.5. A 3.5 only version is included with the attachment to this article.

Set Up

Create an empty msbuild file. Add a default target that you will use to perform the set operations and display messages to show your results.

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup>
        <SetA Include="alpha;beta;gamma;delta"/>
        <SetB Include="alpha;gamma;epsilon"/>
    </ItemGroup>

    <Target Name="Build">
    </Target>        
</Project>

Union All

Perhaps the easiest set operation is the Union All. This operation combines one collection with another, including duplicates. We only have to use the CreateItem including both sets. Add the following code inside your target to see this in action.

<CreateItem Include="@(SetA);@(SetB)" >
    <Output TaskParameter="Include" ItemName="UnionAllSet"/>
</CreateItem>

<Message Text="Union All: @(UnionAllSet)"/>

Minus

The Minus operation works similar to the Union All operation. However, instead of including both sets, you include one set and exclude the other.

Intersect

Intersect only takes items that are in both collections. It starts to get tricky with this operation and in fact was the catalyst for this article. I attempted to perform this one using conditions, but nothing seemed to work. I finally realized I would have to perform multiple operations to get the desired intersection: take the first set and exclude the minus set.

<CreateItem Include="@(SetA)" Exclude="@(MinusSet)" >
    <Output TaskParameter="Include" ItemName="IntersectSet"/>
</CreateItem>

<Message Text="Intersect: @(IntersectSet)"/>

Union

The Union operation pulls elements from both item collections. This is very similar to Union All except that it does not include duplicates. To accomplish this, take the UnionAllSet and exclude IntersectSet. Since this removes the original and duplicate items, add IntersectSet back to the results.

<CreateItem Include="@(UnionAllSet)" Exclude="@(IntersectSet)" >
    <Output TaskParameter="Include" ItemName="UnionSet"/>
</CreateItem>
<CreateItem Include="@(IntersectSet)" >
    <Output TaskParameter="Include" ItemName="UnionSet"/>
</CreateItem>

<Message Text="Union: @(UnionSet)"/>

Conclusion

These are basic examples of doing set operations in MSBuild. Combined with batching and transforms, there isn't much standing in the way of defining your item collections how you wish.

Be sure to download the samples below. It includes an MSBuild 3.5 version using the new, cleaner ItemGroup syntax.

MSBuildSetOperations.zip (1.12 kb)