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.

While reading the comments on the post Constraints are not part of the signature (which is interesting in itself,) I found this little gem in the comment section. It’s from the post author, who is a language designer at Microsoft (emphasis mine.)

Reasoning about C# design choices by pointing out that VB does it differently is not compelling. The VB language designers are building a different language and are making different design choices, in accordance with the design principles for their language. C# has always been a "complain loudly if something looks potentially incorrect" language, and VB has always been a "do your best to figure out what the user meant even if it means sometimes guessing wrong" language. Both philosophies are sensible and useful, and we offer you the choice.

That is a fundamental philosophical difference between the two languages.

This reinforces my impression that VB is designed for beginners. If you don’t know enough to tell the compiler exactly what you want, then VB will try hold your hand for you. The tradeoff is that you might not get the executable you were hoping for.