In the previous post, I showed how to use the Session.Get<T> syntax against an arbitrary property on the entity. The primary limitation with that method is that it only works for constant values. The following will work with constants, local variables, return values from methods, etc.

While many of my entity classes use surrogate primary keys, they also have natural keys (Product SKU for example). When I want one of those entities it's more natural to use the natural key, naturally. Normally that requires a CreateCriteria call, I'd rather just call Get<T> like I can with the surrogate keys. So I created an extension method that lets me do this:

For some reason, every project in my solution has decided to rebuild every time I try to build the solution -- even if that particular project has no changes and none of the dependent projects have any changes. I thought it might have been cause by my recent change to turn Copy Local off for inter-solution references to help speed up the build process. But even reverting the code didn't seem to fix it. Deleting the .suo and .user files that Visual Studio keeps it's editor state in didn't help either. So I decided to track down the issue.

From time to time .NET developers will need to use a native Win32 API to get some platform specific work done. One of the first things I ask myself when I start writing out Interop signatures is "Does the .NET framework already support this?". The breadth of classes in the framework can be daunting and it's not always easy to answer that question. Often the conversations and references online revolve around the native API so that isn't always a help. Searching the MSDN docs can also lead to dead ends as the concepts and naming conventions are often modernized in the framework.

When developing web applications I like to use FQDN when testing locally. Primarily because it more closely matches the deployed state of the application. Cookies have specific rules when sub-domains come into play and you're much more likely to catch any variances. Traditionally I'd set just edit the hosts file on my dev machine (at C:\Windows\System32\drivers\etc on most machines) like so:

Visual Studio 2008 offers a great suite of testing tools for developers. One of the the nicest things is the ability to generate reflection based accessor assemblies that let you access the private members of classes. There is still opendebate about the benefit of testing private methods but for some things -- especially security related -- where it makes a great deal of sense. Getting at those private methods however is not the easiest thing to do.

As part of our migration to TeamCity and our Continuous Integration efforts we've integrated our xUnit.net tests into the build and test process. One of the primary limitations I've found with xUnit is the inability to batch tests outside of the IDE. During development it's easy to run only a specific set of tests ala R#. However as part of the build process don't have that luxury.