Code Contracts and the Visual Studio 2015 Preview

I have been attempting to get a project to compile in the Visual Studio 2015 Preview. Unfortunately, it isn't working because I use Code Contracts throughout the project, with the Contract.Requires() method. The current version of Code Contracts does not install or work with the Visual Studio 2015 preview.

I found one work-around, but it only got me part of the way there. From this post about the Visual Studio 2013 Preview, I discovered that you can copy a file from a working installation of Visual Studio into the correct directory for Visual Studio 2015 and the build process will attempt to use Code Contracts. The trick is to copy the file C:\Program Files (x86)\MSBuild\12.0\Microsoft.Common.Targets\ImportAfter\CodeContractsAfter.targets to the folder C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.Targets\ImportAfter\

However, that only solves the first hurdle. The Code Contracts rewriter goes through your compiled code and modifies the IL (Intermediate Language) to  support the Code Contracts. However, the C# Compiler used by Visual Studio 2015 is the Roslyn compiler. When I try to compile, the Code Contracts tool ccrefgen.exe produces the error: AsmMeta failed with uncaught exception: Unknown custom metadata item kind: 5.

The reason is that the Roslyn compiler is producing some meta data that the Code Contracts tools don't handle correctly. There is a switch statement that handles cases for the numbers 1 through 4, but not 5. This article describes the problem and a possible convoluted fix by patching the code contracts tools to ignore the value 5.Trying to update the code is not easy.

I will update this article if I get things working. [8/11/2015 It is FINALLY fixed in the latest release!]

The right solution, of course, is for the Code Contracts people to support the preview. Vote up this forum request so we can get that to happen.

Resharper Code Cleanup Custom Type Member Layout that Works With StyleCop

I am a religious user of StyleCop to enforce coding standards in my C# code. It uses a coding standard that is fairly inflexible. You can turn rules on and off, but customizing the rules requires writing your own rule library, which is difficult. So you either buy into the way StyleCop does things or you don't. While I don't necessarily agree with every choice for how StyleCop does things, I feel StyleCop gets most things right, and the ones it gets wrong I can live with.

In some cases, I feel StyleCop doesn't go far enough. I wrote several additional rules that plug into StyleCop that enforces several coding standards that I use. One complains if members of a given type are not in alphabetical order. Another disallows multiple returns from inside a method: A method should have one exit point. I don't publish my rules since they have bugs in some cases.

I also use StyleCop+, which allows many additional rules. I do have to change a bunch of settings here to use it, because the defaults aren't right. Still, it does have a number of features I find useful when configured the right way.

One thing StyleCop enforces is the order of items in your code. It has a particular layout that it is looking for. I find it sometimes a little odd. For example, delegates and events come after the constructor...I would think putting them before the constructor makes more sense. However, knowing where things should be located in the file is much more important than exactly where that location is.

I just got a copy of Resharper. It seems many .NET programmers can't live without it, but I've gone 13 years so far. I think my rigid coding standards makes it less useful than it would be if I were more flexible. However, there are some things that I find useful. One thing it can do is reorder your code using the "Cleanup Code" command, which I have done by hand up until now. This is particularly useful when you acquire code from someone who doesn't use StyleCop. However, the default reordering in Resharper is incompatible with StyleCop.

Resharper has a way of customizing what Cleanup Code does. You can create custom rules using XML. I have produced a set of Custom Rules that is mostly compatible with StyleCop, shown at the end of this article.

There are a few issues with my rules. They do not order explicit interface implementations correctly: they will violate StyleCop rule SA1202. (Try implementing explicitly IConvertible, for example.) The ordering of overloaded operators is a little odd. Still, using Resharper with these rules is better than doing reordering by hand, as I can fix what it doesn't do right in few minutes.

Here are the rules. Let me know in the comments if you have any improvements. Be warned...I hate regions, and it will remove the region lines from your code. Change the RemoveAllRegions value to false if you want keep yours.

<?xml version="1.0" encoding="utf-8" ?>
<!-- StyleCop compatible custom rules by Greg Reddick, http://blog.xoc.net -->
<Patterns xmlns="urn:shemas-jetbrains-com:member-reordering-patterns">
 <!--Do not reorder COM interfaces and structs marked by StructLayout attribute-->
 <Pattern RemoveAllRegions="true">
  <Match>
   <Or Weight="100">
    <And>
     <Kind Is="interface" />
     <Or>
      <HasAttribute CLRName="System.Runtime.InteropServices.InterfaceTypeAttribute" />
      <HasAttribute CLRName="System.Runtime.InteropServices.ComImport" />
     </Or>
    </And>
    <HasAttribute CLRName="System.Runtime.InteropServices.StructLayoutAttribute" />
   </Or>
  </Match>
 </Pattern>

 <Pattern RemoveAllRegions="true">

  <Entry>
   <Match>
    <Or>
     <Kind Is="constant" />
     <Kind Is="field" />
    </Or>
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Static />
    <Readonly />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="constructor" />
   </Match>
   <Sort>
    <Static />
    <Access Order="public internal protected-internal protected private" />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="destructor" />
   </Match>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="delegate" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="event" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Static />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="enum" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="interface" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="property" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Static />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="indexer" Weight="100" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Or>
     <Kind Is="method" />
     <Kind Is="operator" />
    </Or>
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Static />
    <Name IgnoreCase="false" />
   </Sort>
  </Entry>
 
  <Entry>
   <Match>
    <Kind Is="struct" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

  <Entry>
   <Match>
    <Kind Is="class" />
   </Match>
   <Sort>
    <Access Order="public internal protected-internal protected private" />
    <Static />
    <Name IgnoreCase="true" />
   </Sort>
  </Entry>

 </Pattern>
</Patterns>

Microsoft Open Sourcing .NET is the Right Move

Microsoft announced a few days ago that it was open sourcing .NET. I consider this a huge move in the right direction. One of the principles of .NET was to separate the code from the underlying hardware. You code to the framework, not to the machine. If the framework (and the CLR) is portable, then the code is portable. In theory, Microsoft could then just port the framework to Apple or Linux hardware, and the code would just work, possibly without even a recompile.

But that was just theory. In practice, Microsoft only ported the framework to different versions of Windows, including the Windows phone and the Xbox, but not any of the competitors operating systems. This lost one of the huge potential advantages of .NET.

The Mono project tried to code around this by creating a compatible version on the other platforms, but they had to do a complete reimplementation. I have compared the code produced in one class in the Mono project to the code in the .NET Framework, and they are not at all the same. This tends to result in subtle differences in functionality between running on Windows with Microsoft's framework versus running on Mono. With the new open source available, Mono moves out of the fringes and becomes the main cross-platform version of the .NET Framework, as they incorporate Microsoft's code.

With the new announcement, Microsoft essentially makes porting possible without spending any resources to actually make it work on these other platforms. This is a win for Microsoft, but also for all of the programmers who have spent the last 13 years programming for .NET. Our investment in learning the ins and outs of .NET can now be used on a much wider set of machines. We don't have to learn a separate technology for programming for Android or the iPhone.

It is still unclear exactly how much Microsoft is going to open up. My biggest question is whether Microsoft will be open sourcing Windows Presentation Foundation (WPF). Mono had avoided working on this because it was a difficult project. The Mono developers estimated 30-60 person years to implement it in Mono. This cost would go down considerably if Microsoft open sources WPF. It still will take quite a bit of resources to port it, since WPF uses DirectX, whereas the ports would probably have to use OpenGL underneath it. However, the port would become a possible thing for Mono if they can just grab the source code.

Microsoft also simultaneously announced that Visual Studio would be free for classroom, education, and very small companies. The version they are giving away is essentially Visual Studio Professional, although with the name "Community Edition". Before this, they were giving away the Visual Studio Express version, but it had serious limitations, and wasn't really practical for developing real production code in many cases.

I would still like to see two things in the cheap/free versions of Visual Studio: 1) Code Coverage. The easiest way to tell whether your test suite has hit all the methods and properties in your code is Code Coverage. This currently only ships in the Premium edition (or better) of Visual Studio. 2) CodeLens. CodeLens provides information about your code directly in the Visual Studio interface. It is currently only available in the Visual Studio Ultimate edition. There may be other features I'd like to see move down, but these are the two that I could make immediate use of. I'm crossing my fingers and hoping they are in the Community and/or Professional Edition in Visual Studio 2015.

All of these moves are great moves for all of us who have invested in learning .NET, and I think this will eventually pay off for Microsoft as well. The .NET platform and the C# programming language are generally considered to be a well thought out easy-to-use environment for getting work done. Being able to leverage that across other platforms makes it a win for everyone. It's a bold move by Microsoft and its new CEO Satya Nadella.

All Encrypted, All the Time

The EFF, Mozilla, Cisco, and Akamai announced Let's Encrypt. Let's Encrypt will give out free certificates for encrypting web servers. You just use an automated interface and get a certificate. There will be no excuse for not using SSL/TLS everywhere. I talked about this in a previous post, but this really makes it a reality. Coming summer of 2015.

Certificates plus IPv6 will give us a more secure Internet.