Resharper Nullability FxCop integration available as nuget package

Bart Koelman has released a nuget package which automatically adds a check for missing ReSharper  annotations to the Visual Studio Code Analysis (formerly FxCop) for VS2013 or lower.

During installation a ruleset file will be automatically created so that the first build after installation already runs all the checks. Very comfortable for newcomers to Code Analysis. However if you have code analysis already enabled in your project then the installer does not make any modifications (great!), instead you’ll need to add the new rule manually.

VS2015 users can also install a plugin to get an even better integration into VS, thanks to the Roslyn-based approach which provides hints in the editor, quick fixes and of course also compiler warnings. Very cool!

So – if you rely on the Resharper annotations then you should give these plugins a definitely a try, I find them very helpful.

Output Colorizer Extension for VS2013

I have updated the Output Colorizer extension for Visual Studio 2013 (all editions).
Download the vsix installer.

VS Extension bring color to the Output window

What happens when you are debugging an application which logs extensively to the VS Output Window? Information overflow, right. It becomes hard-to-impossible spotting the important messages.
Based on a sample I have developed an VS2010 Extension which allows highlighting lines matching a regex in Color. Here you can see the difference:

It defines four “output definitions” for errors, warnings, messages and noise. For each of these definitions you provide multiple regex patterns for an “include” or “exclude”. Details can be found in the readme file.
Feel to download it here: Download from SkyDrive

The value of a Nobel Peace Price

The Nobel Peace Price laureate of 2012 will not protect Edward Snoden from prosecution by the Nobel Peace Price laureate of 2009.
Extremely disappointing and disillusioning (mildy put).

Enforce ReSharper Code Annotations via Code Analysis (FxCop)

The ReSharper Code Annotations are extremely helpful when you want to catch potential bugs as soon as possible (in other words: while typing). Here is a brief example:

Now what happens when you forget to annotate your code? Well, there is simply no feedback then. Since I do not use for my private projects (build time penalty is too high…) I thought I could at least enforce the annotations via FxCop.

Thanks to sites like this that turned out to be rather simple. The result are some new Code Analysis rules which can be configured via Vistual Studio:

Installation & usage
Copy the dlls either into the FxCop folder (c:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\), or put them somewhere in your solution. I personally prefer the later approach.

In VS2010, create a new solution item (Code Analysis Rule Set).

If you were copying the rules dlls into your solution then you’ll need to point FxCop to that dll.
Add manually a RuleSetHintPaths element into your ruleset xml file.
The path can be absolute or relative to your project.
Sample:

<?xml version=”1.0″ encoding=”utf-8″?>
<RuleSet Name=”TEST RE# Ruleset” Description=” ” ToolsVersion=”10.0″>
<RuleHintPaths>
<Path>D:\Projects_CH\FxCopRules\ReSharperRules\bin\Debug\ReSharperRules.dll</Path>
</RuleHintPaths>
</RuleSet>

Finally, open the solution, project properties, code analsysis, and there your should see the “Custom.ReSharper” rules.

Download
Please be aware that due to the limitations in WordPress I can only share media files. Each of these links is a actually a .zip file, please renamed the files manually after downloading them.
Rules only: Binaries v1.0.0
Source code: Source v1.0.0

NHibernate – Unsigned Integer Mapping

My client has been insisting that using “uint” in code and in MS SQL is a good idea… well, so be it.

MS SQL however does not have a native “unit” datatype, therefore NHibernate does (quite reasonebly) not offer such a mapping.

There are two ways around it: Using a user type, or patch Hibernate’s MSSQL dialect class.

Via IUserType

This solution is described here and works really well. It stores an C# UInt32 in a MSSQL INT column.

Downside: Large unsigned numbers appear as negative value in the database, and in the mapping you must specify that type.

Via Patched Dialect

The other solution involves a patched SQL Dialect and also a patch SQL Driver:

public class ExtendedMsSql2008Dialect : MsSql2008Dialect
{
  public ExtendedMsSql2008Dialect()
  {
    // Tell NH that we can handle the ADO DbTypes
    RegisterColumnType(DbType.UInt16, "INT");
    RegisterColumnType(DbType.UInt32, "BIGINT");
    RegisterColumnType(DbType.UInt64, "DECIMAL(28)");
  }
}

public class ExtendedSql2008ClientDriver : Sql2008ClientDriver
{
  protected override void InitializeParameter(System.Data.IDbDataParameter dbParam, string name, NHibernate.SqlTypes.SqlType sqlType)
  {
    if (sqlType == SqlTypeFactory.UInt16) sqlType = SqlTypeFactory.Int32;
    if (sqlType == SqlTypeFactory.UInt32) sqlType = SqlTypeFactory.Int64;
    if (sqlType == SqlTypeFactory.UInt64) sqlType = SqlTypeFactory.Decimal;
    base.InitializeParameter(dbParam, name, sqlType);
  }
}

And of course these two classes must be added to the NHibernate config file:

<property name="connection.driver_class">MyLib.ExtendedSql2008ClientDriver, MyLib</property>
<property name="dialect">MyLib.ExtendedMsSql2008Dialect, MyLib</property>

This solution makes it easier for inexperienced users, but it comes at a price: The SQL data type is wider than the C# datatype, therefore wasting some space/performance.

Conclusion

Pretty obvious – NHibernate is quite flexible, and there is no perfect solution 🙂

NHibernate, FirstOrDefault() and Fetch() – not what I expect

I am a huge fan of Linq, mostly since I like to use it as a default query language across multiple products such as LinqToSql or NHibernate. Sadly, not all implementations behave identically…

Suppose you have a parent-child object model (in my case, a Product class with N Roles). This relationship is mapped as “lazy”, any eager loading must be done case-by-case via code.

My initial implementation was as simple as that:

var product = session.Query<Product>()
	.Fetch(p => p.Roles)
	.FirstOrDefault(p => p.Name == "bla");

Turns out that it fetches only one of associated Roles… The workaround is to load all parent entities and apply FirstOrDefault() in-memory:

var product = session.Query<Product>()
	.Where(p => p.Name == "bla")
	.Fetch(p => p.Roles)
	.AsEnumerable()
	.FirstOrDefault();

The difference is the way the SQL queries are generated:

• LinqToSql submits TWO selects, one per table
• NHibernate submits a SINGLE join-query with a “TOP(1)” statement at the end

The presented workaround is ok when the query will really only return one row – otherwise the parent information would be unneccessarily transferred with each row, which could lead to another performance problem.

 

Localization of standard terms

Were you ever wondering what the best translation for a term term is?

Microsoft has put up a website were you can check whether and how Microsoft has been translating terms: http://www.microsoft.com/Language/en-US/Search.aspx

Saved us a lot of headaches, thanks!

Moq – Mocking internal types

I am currently working on a platform project, which internally uses DI heavily.

Unit-testing internal types is quite easy by make internals visible to the unit test assembly.

So far so good – but when a internal type expects some internal interfaces via DI, then Moq complains about “Type … is not public. Can not create proxy for types that are not accessible“. Making the interface visible to the Moq assembly doesn’t help as the interface proxies are not accessed by Moq but by an in-memory created dynamic assembly… the solution is:

[assembly: InternalsVisibleTo("My.UnitTests")]
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]

Why I won’t use Moles

Moles and Pex are two rather interesting frameworks for Unit Testing.

Despite all the cool possibilities, especially Moles is just not quite right for me…

• Not ready for 64 bit – not even the suggested workaround  helps. The only option is to force running your Unit Tests in 32 bit mode…
• Running in 32 bit is works. but while debugging a test I found the Moles testrunner host is not fond stopping the debugger, indicating its disapproval by crashing…
• When it runs, it runs fine – but slowly. The simplest tests involving a Mole take 2+ seconds, that’s 10x of a normal test

The final straw is however the lack of support from Microsoft:

• The forum has been moved to Stackoverflow 
• The last release was in 2010
• The next promised release date, Nov 2011, is overdue without any comment
• The Moles website lists only two team member blogs, both appear to be working for more than a year on different projects

Sorry… I tried to like it, really. But as it is I simply cannot justify using it on a long-term project.