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.
ACTION REQUIRED
Upgrade all projects using PostSharp 3.1.0-3.1.40 using NuGet Package Managers:
-
Open the solution in Visual Studio
-
Click on menu item Tools / NuGet Package Manager / Manage NuGet Packages for Solutions…
-
Go to the Update tab.
-
Update all PostSharp packages to version 3.1.42 or higher.
-
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.
Summary
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
CEO
UPDATE: Edited the article to mention our build 3.1.42 fixing minor issue and licensing friction.