In the process of installing Orchard tonight, I encountered the following error.

The configuration section 'system.web.extensions' cannot be read because it is missing a section declaration.

The web.config clearly had an empty system.web.extension section.

<system.web.extensions/>

But there was no corresponding section declaration, just like the error said. However, Orchard runs fine on my local machine, and I’ve deployed it to my server before. What could be going on?

It turns out that it’s quite a simple issue, and probably a common problem. If you upgrade a site to .NET 4, and don’t upgrade the application pool to use .NET 4, you will get this. The machine.config file for .NET 4 declares this section, and earlier version did not have it (unless you manually added it).

In IIS 7, with the site select, choose Basic Settings in the right pane. This will bring up a dialog that contains the name of your application pool. Then select the application pools tree node and the application pool from the list that shows up. Choose Basic Settings from the right pane here, and you can change the framework version.

The posts I see for setting up MSBuild on the tool menu in Visual Studio assume that you want to build the current project. If you’re working with custom msbuild files, this will not be the case. Here’s how you can set up MSBuild in Visual Studio 2010 to compile the currently selected build script and output it to the Output window.

In my situation, I have multiple build scripts for demonstration purposes.

Then open the Tools menu and select “External Tools…” A dialog will appear. Click the ‘Add’ button, and type MSBuild in the name text box. Browse for MSBuild.exe in the command text box, my copy was C:\Windows\Microsoft.NET\Framework64\v4.0.30128\MSBuild.exe. For the Arguments text box, type $(ItemPath). Check “Use Output window.” Your window should look like mine below.

The key here is using the ItemPath property as the argument. This uses the full path and filename of the selected item in Solution Explorer

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.