By David, on August 8th, 2011
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.0\Common7\IDE for 64 bit machines, and C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE 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:\Windows\System32>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]
[/login:username,[password]]
[/collection:TeamProjectCollectionUrl]
Versionspec:
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.
By David, on July 28th, 2011
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 HKLM\Software\Microsoft\MSBuild\4.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 HKLM\Software\Wow6432Node\Microsoft\MSBuild\4.0.
Verify
If you then run msbuild /help, you should now see the documentation on the /debug switch:
/debug
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.
Debugging
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: http://blogs.msdn.com/b/visualstudio/archive/2010/07/06/debugging-msbuild-script-with-visual-studio.aspx
By David, on January 14th, 2011
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.
Example
For example, your app.manifest may contain this fragment:
<dependency>
<dependentAssembly>
<assemblyIdentity name=“Native.Custom“ version=“1.0.0.0“ processorArchitecture=“x86“ type=“win32“ publicKeyToken=“12345678“/>
</dependentAssembly>
</dependency>
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.
Solution
The problem may be because the ClickOnce manifests are being generated.
- Open your project file in a text editor (or right click it in Visual Studio and choose Edit Project)
- Find the GenerateManifests element and set it to false:
- <GenerateManifests>false</GenerateManifests>
- Save the project and reload it.
Now you should hopefully be able to build.
By David, on December 17th, 2010
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:
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
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 http://go.microsoft.com/fwlink/?LinkID=155570 for more information.
To avoid this, you have to enable the legacy support by adding a runtime element :
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true"/>
</runtime>
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"/>
</startup>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true"/>
</runtime>
References
<startup> Element @ MSDN
<supportedRuntime> Element @ MSDN
<NetFx40_LegacySecurityPolicy> Element @ MSDN
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true"/>
</runtime>
By David, on August 25th, 2010
I’ve updated the IPFilter Updater for uTorrent to version 1.0.0.1 and you can get it here.
By David, on July 6th, 2010
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.
By David, on June 30th, 2010
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.
- HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x86
- HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x64
- HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\ia64
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"?>
<Include>
<!-- Visual C++ 2010 x86 -->
<Property Id="HASVCPP2010">
<RegistrySearch Id="HasVCPP2010Search" Root="HKLM" Key="SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x86" Name="Installed" Type="raw" />
</Property>
<Condition Message="This application requires Microsoft Visual C++ 2010 Redistributable Package (x86).">Installed OR (HASVCPP2010)</Condition>
</Include>
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.
Reference: http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx
By David, on June 28th, 2010
Prerequisites:
- Determine the name of the custom action you want to debug
- Ensure you have the source code and debug symbols for your custom action
Steps
- Set the MsiBreak environment variable (user or system) to the name of the custom action. For example:
Setx MsiBreak MyCustomActionName
- Run your installer
- At the point where your custom action is about to run, you should get this message box prompt:

- Now you can use Visual Studio or another debugger such as WinDBG to attach to the specified process.
- Click OK on the message box
- This should break into your debugger. This is a good time to set your breakpoints in your custom action code.
- When ready, run/continue the debug session.
- Your custom action should run and your breakpoint(s) will be hit.
References:
Debugging Custom Actions @ msdn.microsoft.com
By David, on June 22nd, 2010
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.
- Open up %Program Files%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config in a text editor
- Find the MSBuildPath property, which will likely be empty, and enter the path to the .NET Framework 4.0 folder (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\):

- Save the file
- Restart the Visual Studio Team Foundation Build service
Reference: http://blogs.msdn.com/b/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx
By David, on September 30th, 2009
I find I have to generate GUIDs often (mostly due to using WiX) and the in-built Tools > Create GUID tool is too cumbersome for this.
I found a blog post that has a simple macro you can customize to bind a keyboard shortcut to paste in a new GUID
Here are some full instructions, using their simple macro code:
- Tools > Macros > Macro Explorer (or hit ALT+F8)
- Right click Macros, choose New Macro Project…
- Choose a location for the Macro project and give it a meaningful name then click Add
- Rename Module1 to something more meaningful, then double-click to edit the module
- Insert the code to paste a new GUID into the current cursor position / selection:
Public Sub PasteNewGuid()
DTE.ActiveDocument.Selection.Text = "{" & System.Guid.NewGuid().ToString("D").ToUpper() & "}"
End Sub
- Save the macro project and close the Macro IDE
- In Visual Studio: Tools > Options, select Environment > Keyboard
- Find the macro command you created (you can use the Show commands containing: to search on guid)
- Select the command in the list
- Ensure Use new shortcut in: has Global selected
- Place the cursor in Press shortcut keys: and hit the shortcut (ALT+G for me)
- Hit OK
- Test it out
|
|
|