I was recently presented with an odd problem. The COBOL team at work was making the switch to using COBOL.NET, but the compiled DLLs were constantly becoming locked. Instead, they wanted the COBOL.NET compiler to create INT files. There was no build action for individual CBL files for this, and the cblproj file had no option to compile the .CBL files to INT. For those that may be confused by that sentence, each individual CBL file is compiled to a DLL in COBOL.

I checked the compiler out, and it did have the appropriate switches to create INT files. So, I opened up the project file to find the targets file it was importing. A short time later, I found the targets file and had reflected it’s task DLL. After a little trial and error, I discovered the set of properties necessary to set in your cblproj file to compile COBOL files to INT with Micro Focus.

Unload the project, then edit it. Change these values in the first property group.

<OutputType>IntGnt</OutputType>
<LinkMultiDlls>false</LinkMultiDlls>

In the second property group, under OutputPath, place the following:

<IntermediateOutputPath>$(OutputPath)</IntermediateOutputPath>

The first set changes the type of output to IntGnt instead of Library. Unfortunately, if LinkMultiDlls is true, it will attempt to link non-existent DLLs. IntermediateOutputPath is set so the INT files are output to the appropriate folder. Otherwise, they are placed in the obj folder and never moved because Cobol task doesn’t set the output items when it creates something other than DLL files.

Project management doesn’t seem to like it when they generate reports from Team Foundation Server and see tons of hours remaining for work that should have already be completed. In my organization, it’s not due to lazy developers not completing their tasks, but people tend to forget to zero out the remaining hours in their tasks before closing it. Luckily, there’s a way to fix that.

Open up a command prompt and change directories to %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE. Then run the following command replacing <url> with the url to your team project collection.

witadmin exportwitd /collection:<url> /p:<ProjectName> /n:Task /f:task.xml

You will need to edit the templates of the various work items if you want this for more than task. Edit task.xml and find the TRANSITIONS section. Find <TRANSITION from="Active" to="Closed">. Then, under the FIELDS section put the following snippet of xml.

            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <ALLOWEDVALUES expanditems="true">
                <LISTITEM value="0" />
              </ALLOWEDVALUES>
            </FIELD>

Save the file and import it back to TFS.

witadmin importwitd /collection:<url> /p:<ProjectName> /f:task.xml

Now, any time someone attempts to close an active work item, they will receive a warning… and an error if they actually try to save.

This may be a minor annoyance to developers, but it provides more accurate reporting and saves the time required to go back and correct the work items in the future.

A while back, we upgraded our servers to Team Foundation Server 2010. Recently, I was tasked with the creation of a solution for COBOL.NET. This solution required Visual Studio 2008, so I created the team project while in VS 2008. This morning, I come in to emails that our Team SharePoint sites are down. Here’s the error message.

An error has occurred on the server.http://go.microsoft.com/fwlink?LinkID=96177

The link led me to believe that SharePoint needed to be upgraded, and I thought it was pretty suspicious that Microsoft would prevent use of our sites due to an uninstalled patch. Despite the oddity of the error, I sent a note to the help desk to patch the server and went about my business.

That wasn’t the problem.

I soon received a message back that there weren’t any pending updates. I asked team members when they noticed that the site was down, and I eventually traced it back to Friday. Since I added the team project on Friday, I decided that was unlikely to be pure coincidence.

I got on the server and shifted through the logs. Note that I’m running WSS 3.0, so your locations may be different if you’re running a different version or MOSS. I eventually found this item in a recent log located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS:

Exception stack trace:    at Microsoft.SharePoint.Administration.SPContentDatabase.ValidateDatabaseSchemaCompatibility()

This was among other information where the site could not load. This indicated to me that when the team project was created, it used an old schema. The original message was correct: I needed to upgrade SharePoint. Here’s how. Run the following command.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>PSCONFIG.EXE -cmd upgrade -inplace b2b -wait –force

This corrected this problem. In the future, I will be sure to create the team project in VS 2010, then add the solutions through VS 2008.

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 error. 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 selected, 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, 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>