Last Thursday, our PostSharp MVP Yan Cui joined us for an awesome webinar about how to use AOP to get near-realtime performance information from their servers running in the Amazon Cloud, using AWS CloudWatch.
The video and slides from the live webinar are now online for your viewing pleasure:
And here are the slides:
In the second part of the webinar I give a sneak peek at the PostSharp Diagnostic Toolkit. Download and install it today via NuGet, or get the source code on Github.
It’s not often that a bug fixes deserves a blog post, but today it happened :-(
64-bit programs (*.exe) processed by PostSharp 126.96.36.199-188.8.131.52 are unable to allocate more than 2GB of memory because of a invalid flag in the NT Header (IMAGE_FILE_32BIT_MACHINE instead of IMAGE_FILE_LARGE_ADDRESS_AWARE). Yes, just one bit.
This issue is especially nasty because generally invisible during testing. It’s only in production that a process attempts to use more memory. The program would them have terminated with an OutOfMemoryException.
Big thanks to Augustunbear Zhang for diagnosing this issue.
The issue is fixed at revision 184.108.40.206.
We recommend customers who have PostSharp-enhanced 64-bit programs (*.exe) in production to rebuild their project and redeploy them.
We sincerely apologize for the inconvenience this issue is causing. For any question or assistance, do not hesitate to contact me personally.
With all the good reasons mentioned by Ayende, we decided to officially switch PostSharp 2.1 to a continuous deployment process. We are abandoning the distinction between “milestone releases” and “hotfixes”. Since today, you will know always download the latest revision from the principal download page, as well as on NuGet.
Ayende’s article came at a time when we were frustrated with our release cycle. Although we released dozens of hotfixes, the front-page download was still the initial 2.1 RTM release because we constantly deferred the SP1. Clearly, the majority of people were not downloading the best-quality release, and were therefore hitting bugs that have already been solved for a long time. Not the best user experience!
Technically, the difference is quite small. PostSharp’s build and test processes have always been automated. It takes about 50 minutes to build and test all components. Uploading to our download manager is very easy too – copy the build output to a network share and execute a script that synchronizes with Amazon S3. Therefore, the time-to-market of a bug fix has always been very short – a couple of hours, typically. The fact that deployment is now integrated with the build script does not really change this fact.
Thus, the most significant difference is that we will actually publish hotfixes as front-page downloads.
Unlike “hotfixes”, “milestone releases” got additional manual testing on virtual machines, where the later got only automated testing. Installation tests are still not automated, so there’s a slight chance to get a regression in a front-page release. We bet that these defects will be infrequent and quickly detected by the community.
Bottom line: we bet that the overall quality will be higher by switching to continuous development.
Happy PostSharping, now with a fresh version!
We have just released an update for the PostSharp Diagnostics Toolkit – Log4Net and System.Diagnostics.Trace now join NLog and System.Console as the supported logging frameworks.
What does this mean for you? It means that you can now add logging to your application without any code changes – just by downloading a NuGet package:
- For System.Diagnostics.Trace support:
We have changed the NuGet package name a bit to make it more readable, and made the version number match that of the PostSharp build the package depends upon.
As I mentioned in the previous blog post, the NuGet package creates a .psproj file in the project’s directory named after the project. This is an XML file, which contains the configuration that is processed by PostSharp during compilation.
I will go into much greater detail about the XML configuration in the next blog post.
As always, the source code for the PostSharp Toolkits is available on Github. Your feedback is very appreciated – please tell us your suggestions and issues on our Support Forums for PostSharp Toolkits.