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.

People have used the “Lu” prefix on database tables since time eternal, but it means very different things to different people. I’m reading a specification right now that has 24 tables; 18 of them are “lookup” tables. Several of these can be configured from within the application. I find that weird.

Here’s my view:

A table is always considered “lookup” if adding or removing rows, or changing their meaning, would break the application, or result in unexpected behavior. For instance, a table that corresponds to a status enumeration in the code. You might change the friendly name of one of these statuses, but you wouldn’t change the ID, or the general meaning of it. And you wouldn’t have a “status description maintenance” screen in your application.

A table is probably “lookup” if it is sufficiently static that there is no provision for editing it in the user interface. For instance, a list of US states, counties within a state, genders, or the like. Sure, Puerto Rico might become a state, but we’re going to call it a static list.

What do you think? Does “lookup” mean:

• static (changes break the app)
• not editable through the UI (but changes don’t break the app)
• not changed very often
• all ancillary data (everything but a few primary tables)