Category Archives: Software Development

Deleting and purging items from Team Foundation Server

When you delete an item from TFS, it’s not actually permanently gone.

You can view deleted items by going to Tools > Options > Source Control > Visual Studio Team Foundation Server and checking the Show deleted items in the Source Control Explorer option:


You can then see folders and files that have been deleted, which allows you to right click on them to choose Undelete (or go to File > Source Control > Undelete).

It’s useful to show deleted items by default, but you may find that your source tree ends up a bit clogged with all the deleted files and folders.

You can purge items you want to delete permanently by using the TFS command-line tools.

TF.EXE is found with Visual Studio 2010 under C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDE for 64 bit machines, and C:Program FilesMicrosoft Visual Studio 10.0Common7IDE on 32 bit.

You might find it useful to add that path to your command line.

The commandlet you want to use is destroy, which tf.exe can give us info on:

C:WindowsSystem32>tf help destroy
TF - Team Foundation Version Control Tool, Version 10.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Destroys, or permanently deletes, version-controlled items from Team
Foundation version control.

tf destroy [/keephistory] itemspec1 [;versionspec]
[itemspec2...itemspecN] [/stopat:versionspec] [/preview]
[/startcleanup] [/noprompt] [/silent]

Date/Time         D"any .Net Framework-supported format"
or any of the date formats of the local machine
Changeset number  Cnnnnnn
Label             Llabelname
Latest version    T
Workspace         Wworkspacename;workspaceowner

To run the command, you have to specify the collection URL. An easy way to get this is open your Team Explorer window in Visual Studio (View > Team Explorer), select the root server node and look in the Properties window at the Url property.

Now you need the server name of the folder or file you want to purge. Locate the file or folder in the Source Control Explorer, right click and choose Properties…

The Server Name: value is what you want and can be selected and copied to the clipboard.

Now you can run the command:

tf destroy $/MyProject/Main/Bin /collection:http://servername:8080/tfs/myproject
Do you want to destroy $/MyProject/Main/Bin and all of its children? (Yes/No) y
Destroyed: $/MyProject/Main/Bin;X3601
Destroyed: $/MyProject/Main/Bin/Native;X3601

Now if you refresh in Solution Explorer, the purged items won’t even show up anymore.

Debugging MSBuild scripts

If you want to debug an MSBuild script from without Visual Studio, you need to use the /debug command line option.

The trick is that this option is not normally available; you need to set a registry key to enable it.

Enable the MSBuild Debugger

Under the HKLMSoftwareMicrosoftMSBuild4.0 key, create a string value called EnableDebugger with a value of “true”.

If you’re on a 64 bit system, you’ll also want to set the same value under the key HKLMSoftwareWow6432NodeMicrosoftMSBuild4.0.


If you then run msbuild /help, you should now see the documentation on the /debug switch:

                    Causes a debugger prompt to appear immediately so that
                    Visual Studio can be attached for you to debug the
                    MSBuild XML and any tasks and loggers it uses.


Now you can pass the /debug option to MSBuild when running it. This will immediately break into the debugger, which will usually give you a prompt to select your JIT debugger:


The debug session will then start at the very top of the root MSBuild project file, and you can go from there.

You can set breakpoints in your MSBuild project files from within the IDE, and inspect the MSBuild variables using Locals and Watch.

Some more tips:

  • Your breakpoints may not show up to be hit yet until the project file they’re contained in actually loads. If you continue on, the project will get loaded and the breakpoint will get hit.
  • To prevent yourself breaking into framework code that you don’t have source for, you can check the Enable Just My Code (Managed only) option under Debug > Options and Settings > Debugging > General.
  • From the Immediate window to evaluate conditions using EvaluateCondition:
Immediate input: EvaluateCondition("'$(MyProperty)' == ''")
Immediate output: false
  • From the Immediate window you can evaluate expressions using EvaluateExpression (remember to escape slashes):
Immediate input: EvaluateExpression("C:\$(MyFolderName)")
Immediate output: C:MyFolder

Original article and full details (recommended reading) is here:

Error building project when referencing native assembly dependency in app.manifest

If you’re using an app.manifest, and defining assembly dependencies (i.e. for SxS / Side by side / Reg-free COM etc), you may encounter this error when you build the project:

Could not find file ‘AssemblyName, Version=x.x.x.x, PublicKeyToken=xxxxxxxxxxx, ProcessorArchitecture=x86, Type=win32′.

This is even when the native assembly is in place where the project can find it.


For example, your app.manifest may contain this fragment:

<assemblyIdentity name=Native.Custom version= processorArchitecture=x86 type=win32 publicKeyToken=12345678/>

This manifest is available to the project, with the manifest file in the project directory or in a subdirectory called “Native.Custom”.

In this case, I have a sub directory called Native.Custom, which contains my Native.Custom.manifest file.


The problem may be because the ClickOnce manifests are being generated.

  1. Open your project file in a text editor (or right click it in Visual Studio and choose Edit Project)
  2. Find the  GenerateManifests element and set it to false:
  3. <GenerateManifests>false</GenerateManifests>
  4. Save the project and reload it.

Now you should hopefully be able to build.

Running .NET 2 Runtime applications under the .NET 4 Runtime

In some situations, you might want to run a .NET 2 Runtime application (.NET 2, 3.0, 3.5 SP1 etc) under the .NET 4 Runtime – without recompiling.

You can configure your app to execute under the .NET 4 runtime by adding these lines to the executable’s configuration file, under the root  configuration element:

  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

Because the security framework has changed in the .NET 4 runtime, you will likely encounter some exceptions containing a message similar to:

System.NotSupportedException: This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see for more information.

To avoid this, you  have to enable the legacy support by adding a runtime element :

  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  <NetFx40_LegacySecurityPolicy enabled="true"/>

If your application also uses mixed assemblies that contain both managed and native code (such as System.Data.SQLite.dll), you’ll see an error message like this:

Mixed mode assembly is built against version ‘v2.0.50727′ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

You will need to enable the legacy activation to allow these to be loaded also:

<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  <NetFx40_LegacySecurityPolicy enabled="true"/>


<startup> Element @ MSDN

<supportedRuntime> Element @ MSDN

<NetFx40_LegacySecurityPolicy> Element @ MSDN

<startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
        <NetFx40_LegacySecurityPolicy enabled="true"/>

Dependency Property ReSharper Live Template

Dependency Property ReSharper Live Template

Don’t you love Dependency Properties?

After the ease of automatic properties though, dependency properties are a chore to define.

If you’ve got ReSharper (if not, why not?), I’ve got a simple Live Template you can use to create your dependency properties.

I’ve set it up to use the dp keyword.

Here it is in use. Typing dp first to pop up the template:


Hitting tab or enter will run the template, with the name macro already selected:


Type in the name of the property. This will set up the wrapper property with that name, and the dependency property’s name will be the name you chose, with “Property” added to the end.

For example, I type in MyCaption as the property name:


Hitting tab shifts me to the next macro, which is the type for the dependency property:


My property will be of type string, so typing that in will bring up string in the suggestions. Hitting tab will select this; hitting tab again will confirm this as my type, and select the next and last macro, the owner type:


This will automatically be set to the name of the containing type anyway, so you can normally leave this as is; hit tab one more time and you’re done.

HOW TO: Detect if the Visual C++ 2010 redistributable package is installed with WiX

As noted by Aaron Stebner, there is now a registry key you can search for to detect if the Visual C++ 2010 redistributable package is installed a machine, when installing your application.

There are 3 different (but very similar) registry keys for each of the 3 platform packages. Each key has a DWORD value called “Installed” with a value of 1.

  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistx86
  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistx64
  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistia64

Here’s an example of using this in WiX, detecting the presence of the x86 version of the redistributable:

<?xml version="1.0" encoding="utf-8"?>
        <!-- Visual C++ 2010 x86 -->
        <Property Id="HASVCPP2010">
        <RegistrySearch Id="HasVCPP2010Search" Root="HKLM" Key="SOFTWAREMicrosoftVisualStudio10.0VCVCRedistx86" Name="Installed" Type="raw" />
    <Condition Message="This application requires Microsoft Visual C++ 2010 Redistributable Package (x86).">Installed OR (HASVCPP2010)</Condition>

When someone runs your installer and they don’t have this package installed, they will get something like this message box when the installer initializes:


It’s a good idea to have a setup bootstrapper that automatically installs this package if it’s missing, but this WiX snippet is a good safe-guard for if someone directly runs your MSI.


HOW TO: Debug a Windows Installer custom action


  • Determine the name of the custom action you want to debug
  • Ensure you have the source code and debug symbols for your custom action


  1. Set the MsiBreak environment variable (user or system) to the name of the custom action. For example:

    Setx MsiBreak MyCustomActionName

  2. Run your installer
  3. At the point where your custom action is about to run, you should get this message box prompt:

  4. Now you can use Visual Studio or another debugger such as WinDBG to attach to the specified process.
  5. Click OK on the message box
  6. This should break into your debugger. This is a good time to set your breakpoints in your custom action code.
  7. When ready, run/continue the debug session.
  8. Your custom action should run and your breakpoint(s) will be hit.


Debugging Custom Actions @

Building Visual Studio 2010 Solutions in Team Foundation Server Build 2008

Visual Studio 2010 and Team Foundation Server 2010 have been out for a while. But what if you still have Team Foundation Server 2008 but want to build Visual Studio 2010 solutions on it?

You can do so by updating the Team Foundation Build Service configuration to use the latest version of MSBuild that comes with the .NET Framework 4.0.

  1. Open up %Program Files%Microsoft Visual Studio 9.0Common7IDEPrivateAssembliestfsbuildservice.exe.config in a text editor
  2. Find the MSBuildPath property, which will likely be empty, and enter the path to the .NET Framework 4.0 folder (C:WINDOWSMicrosoft.NETFrameworkv4.0.30319):
  3. Save the file
  4. Restart the  Visual Studio Team Foundation Build service


Castle Project update

Hamilton has applied a bunch of patches and fixes to the Castle Project for the Components and Windsor sub-projects. Including 2 minor and insignificant patches that I submitted +D. It’s good to feel part of a major Open Source project, even for a small contribution.

While I’m currently focusing my efforts on ASP.NET MVC and moved away from MonoRail, I use Castle extensively in my .NET projects, particularly ActiveRecord and Windsor/MicroKernel.