Our IT guy recently deleted my domain account (because in Exchange 2010 “delete mailbox” really means “delete mailbox and domain account,” but that’s a whole unrelated story.)

One of the results of this fiasco for me was an orphaned workspace on Team Foundation Server, for my old account, which prevented me from mapping folders in source control with my new domain account.

“The working folder is already in use by the workspace…”

The solution to this problem is to delete the cached workspaces on the TFS Server. This is done with the tf command-line utility.

Start by displaying workspaces for all users:

tf workspaces /collection:http://myserver:8080/tfs/CollectionName /owner:*

Or just on the local machine:

tf workspaces
  /collection:http://myserver:8080/tfs/CollectionName
  /owner:* /computer:MYCOMPUTER

Then delete the problem workspace from the server. In my case it’s the old domain account with “:4” appended to the end, which differentiates it from the new account. The full designation for the the workspace is COMPUTER;DOMAIN\username.

tf workspace /delete /collection:http://myserver:8080/tfs/CollectionName MYCOMPUTER;DOMAINNAME\username:4

This last action requires administrative permissions on the server.

The Custom Controls for TFS Work Item Tracking site on CodePlex has a couple of useful controls for your TFS work item forms. I need a link on our form which points to an external site that interfaces with TFS. And I needed to add parameters to this link, in order to transfer the work item id to the external site.

My answer to this is a hyperlink custom control, which I added to the WITCustomControls project from the CodePlex link above.

To compile, install, and use this Hyperlink control, download the source files and add them to the CodePlex project. Follow the installation instructions there. The XML to include in your work item template looks like this:

<Control FieldName="System.Id" 
  Name="MyLink1"
  Type="HyperLinkControl" 
  Label="Some Page" 
  LabelPosition="Left"
  LinkText="Some Page"
  URL=http://MyServer/SomePage.aspx 
  ParamNames="id,date" 
  ParamFields="System.Id,System.ChangedDate" />

The ParamNames list is optional; if not included, the control will use the field names for the URL parameter names.

Do you need to get your SSIS output to convert numbers to strings, with a specific number of decimal places? I needed my derived columns to be blank if the number is zero, or show as money (2 decimals places) if not.

Converting to decimal has no effect; the output does not show a fixed number of digits after the zero.

Amount < 0 ? (DT_WSTR,20)(DT_DECIMAL,2)(0 - Amount) : ""

The trick is to convert to DT_NUMERIC, instead. The conversion to DT_WSTR will then include zeros to pad to the desired scale. (Scale is the number of decimal places, and precision is the total number of digits.)

Amount > 0 ? (DT_WSTR,20)(DT_NUMERIC,15,2)(Amount) : ""

If you’re using the Sql Server Reporting Services ReportViewer control, specifying the export filename is simple, if not immediately obvious.

In your Page_Load - or wherever appropriate:

DateTime startDate = DateTime.Parse(Request.Params["start"]);
DateTime endDate = DateTime.Parse(Request.Params["end"]);

string filename = string.Format(
    "PerDiem {0:yyyyMMdd} to {1:yyyyMMdd}", startDate, endDate);

ReportViewer1.LocalReport.DisplayName = filename;

The DisplayName is used as the export file’s name, with an extension depending on the export type.

For the second time recently, I’m working on an ASP.NET website that uses windows authentication, and gets roles from Active Directory (AD) using WindowsTokenRoleProvider. The roles correspond to the AD groups that the logged-in user is a member of.

I don’t have permission to modify AD group membership, so how do I test my application’s role and permission code? Do I ask our IT guy to swap me in and out of groups while I’m testing?

Yeah, that’s not going to happen.

My solution to this problem is to use a different provider for the roles; the role provider and the membership provider don’t need to be a matched pair. So I can continue to use windows authentication to verify membership (all domain logins are associated with the application, by default.) But I get roles from an XML file, making them easy to change.

How to set it up:

Microsoft has a description of role providers with an example, the ReadOnlyXmlRoleProvider, which is perfect for our purposes. That sample was for IIS6. If you’re using IIS7 on Vista or Windows 7, the provider must be in the Global Assembly Cache. You can find detailed instructions for creating and registering the provider for IIS7 here. We only need the role provider, but the membership provider might be useful in other scenarios. Be careful about that PublicKeyToken when adding the provider to web.config.

Once the provider is installed and configured, just add the desired windows accounts to Users.xml, in the App_Data folder.

<Users>
  <User>
    <UserName>MYDOMAIN\jsmith</UserName>
    <Password>boo</Password>    <!-- doesn't matter what's here -->
    <EMail>jsmith@mycompany.com</EMail>
    <Roles>Admin,SuperGuy,Etcetera</Roles>
  </User>
</Users>

Now we can access roles in the usual way, without having to bug IT…

string[] userRoles = ((RolePrincipal)User).GetRoles();
            
bool inRole = User.IsInRole(SomeRole);

In production, I just change the web.config to use WindowsTokenRoleProvider rather than my ReadOnlyXmlRoleProvider; no recompiling is necessary.