NDC Oslo 2014 is almost there. As every year, software developers will converge to Oslo. If you haven’t done it yet, watch David Appenborough’s fun documentary about this surprising seasonal migration.

PostSharp will have a strong presence with three team members, one workshop and one presentation!

NDC is connected with a few “firsts” for us: NDC 2011 was the finish line of the first PostSharp road tour ever. And this year will be the very first time we’ll have a booth! Well, this was quite an experience to get prepared to a conference of this size. We got new brochures, video loops and t-shirts, and you don’t want to miss this opportunity to meet Gael and the PostSharp team:

  • Pre-Conference Workshop on Monday, June 2nd: a deep dive from the horse’s mouth. Disclaimer: attendees may change the way they look at software development. It’s still time to register for your workshops if you haven’t done it yet.
  • Taking Design Patterns to the Next Level on Thursday, June 4th challenges popular dogmas about design patterns and shows how design pattern automation is possible today in .NET.
    The presentation starts at 9:00AM in Room 5.
  • You can meet us at our booth! We’d love to hear how we can improve what we’re doing and you'll get a chance to win some nice PostSharp gifts!

As every year, the 2014 speaker alignment is awesome; we hope to see you there!


We’re sorry to announce that a critical defect affects all builds of PostSharp versions 3.1.0-3.1.40 and 3.2.0-3.2.20. We strongly recommend all projects using PostSharp 3.1 to be upgraded to PostSharp 3.1.42.

Which projects are affected?

It is important to understand that the defect acts as a “time bomb”. You will be affected by the project even if (a) you did not modify its source code, (b) you did not upgrade PostSharp and (c) you did not install any Windows update.

Projects that (a) are bound to PostSharp 3.1.0-3.1.33 AND (b) that don’t cause PostSharp to emit an error or warning message are not affected.

Does the issue affect run-time behavior of applications built with PostSharp?

No. The defect only affects build-time behavior.

What are the symptoms of the error?

You may see one of the following symptoms, according to the kind of host:

  • With PostSharpHost=PipeServer (typically on developer workstations): “connection unexpectly closed by the server” followed by “Retrying to execute the pipe server” followed by “Error connecting to the pipe server. See previous warnings for details”

  • With PostShatpHost=Native (typically on build servers):

    • error MSB6006: "postsharp.4.0-x64.exe" exited with code -199

    • error MSB6006: "postsharp.4.0-x86.exe" exited with code -199.

    • error MSB6006: "postsharp.4.0-x64-cil.exe" exited with code -199

    • error MSB6006: "postsharp.4.0-x86-cil.exe" exited with code -199.

  • With PostSharpHost=Managed: The license dialog of Nove.CodeDOM appears.


Upgrade all projects using PostSharp 3.1.0-3.1.40 using NuGet Package Managers:

  1. Open the solution in Visual Studio

  2. Click on menu item Tools / NuGet Package Manager / Manage NuGet Packages for Solutions…

  3. Go to the Update tab.

  4. Update all PostSharp packages to version 3.1.42 or higher.

  5. Deploy the new source code to build server and team members.

Note: Updating the PostSharp Visual Studio Extension (VSiX) is not required and does not solve the issue.

What happens if I don’t upgrade the projects?

If you don’t upgrade the project, the issue may appear later, and your team may lose productivity in diagnosing it.

What is I don’t have an active maintenance subscription?

We “tricked” the 3.1.42 build so it is available to anyone who was properly licensed for PostSharp 3.1 RTM, even with an expired license subscription. You should then specifically upload to build 3.1.42. Other builds don’t have the license “trick”.

What is the cause of the defect?

The error is caused by the license enforcement component of Nova.CodeDOM, a library that we lawfully sourced from Inevitable Software. PostSharp uses this library to provide file and line number information of error messages.

Previously to 3.1.33, PostSharp initialized Nova.CodeDOM lazily, when the first error message needed to be resolved. Starting 3.1.33, PostSharp initialized Nova.CodeDOM unconditionally. This is why projects built with PostSharp 3.1.33 and later are more likely to be affected by the issue.

Why was this issue not anticipated?

We anticipated issues in the Nova.CodeDOM library and implemented a fail-safe behavior, so that a failure in the library would just cause a failure to locate the file and line number of error messages, but except of having no file and line information, the build would work as usually. However, we did assumed that all failures would be in the form of a managed exceptions. We did not anticipate that the library would terminate the process.

When did the symptoms first occur?

The issue first hit our support line on May 20th at 16:00, Central Europe Time. We became aware of the severity of the issue on May 21st at 10:00 when more support tickets were filed.

When was a fix released?

We uploaded the build 3.1.41 fixing this issue on May 21st at 14:00, Central Europe Time.

Completed in a rush, this build contained two non-blocking issues, which were fixed in 3.1.42 and uploaded on May 23rd.

How was the issue solved?

As we lost trust in Nova.CodeDOM, we decided to immediately remove the library from our product. As from version 3.1.41, we will no longer ship Nova.CodeDOM with our products.

Therefore, we unfortunately had to surrender the feature that was using Nova.CodeDOM. Namely, current versions of PostSharp no longer resolve the file and line number of error messages. We will restore the feature with Roslyn as soon as the license will allow for redistribution.


At PostSharp, we are taking our customers’ productivity extremely seriously. We are aware that this issue prevented whole teams of developers from working during several hours, and that the potential impact of the issue may account for dozens of thousands of dollars of combined productivity losses.

Although the defect was caused by a third-party component, we are ultimately responsible for the overall quality of our product, and this includes selection of suppliers.

Therefore, on behalf of PostSharp Technologies, I would like to profoundly apologize for the inconveniences caused by the issue.

Gael Fraiteur

UPDATE: Edited the article to mention our build 3.1.42 fixing minor issue and licensing friction.