We’re thrilled to finally announce the availability of PostSharp training, worldwide. We’ve assembled an experienced team of trainers and consultants to offer a comprehensive 2 day course that’s designed to bring you up to speed fast on aspect-oriented programming and PostSharp.
The course includes hands-on labs and discussion where you’ll learn how to:
- create PostSharp aspects; and
- successfully introduce PostSharp aspects into complex projects.
Upon completion, you’ll be able to apply what you’ve learned to your own applications, and produce cleaner, more efficient, higher quality code than ever before.
Meet our Training & Consulting Partners
Donald Belcham is a senior software developer, independent contractor, and agile development expert who is a strong supporter of fundamental OO patterns and practices. He is co-author of the book, Brownfield Application Development in .NET (Manning Press, 2008), and actively shares his expertise with other technical professionals at user groups, code camps and conferences held throughout the world. Past lectures have covered topics that encompass development practices, quality team leadership, and the intricacies of new and emerging technologies.
Endjin is a collaboration of like-minded people who are imbued with an infectious enthusiasm for solving business problems through the smart application of technology. Their endjin-eers are outstanding individuals who have come together from across the business, creative and technology community having demonstrated a mastery of their craft. Unconstrained by industry vertical, company size or budget; endjin is motivated by solving problems. Their goal is to energize your business whether it is through a 2 hour conversation or 2 years of team effort.
PostSharp Training Agenda
The standard public agenda is composed of the following modules (note: for private training other topics can be introduced after discussion with the trainer):
- Introduction to AOP
- Basic aspects
- Applying aspects to code
- Interception aspects
- Aspect composition
- Composite aspects
- Deployment and build process integration
- Targeting different platforms
- Best practices
We’ve got more exciting training news coming in the weeks ahead and, if you sign-up now to request more information about PostSharp training, we’ll let you in on the exciting news (including an exclusive offer) before we announce it publicly.
I’m pleased to announce the second release candidate of PostSharp 2.1, available for download today on our web site and on NuGet. The first RC proved to be very stable, so this new version contains only relatively minor bug fixes. This RC also contains all bug fixes from the 2.0 branch.
Here’s the list of bugs that have been fixed in this release:
- CopyCustomAttributes causes exception when several types are passed to the constructor
- Fields are not visible by the debugger when a class has been moved to a binding class
- ImageWriter sets the section virtual size to an invalid value, causing failure in Windows Phone
- Invalid code generation when introducing a property or event of an open generic type
- Invalid code generation when introducing a property with a private property setter
- MainForm.CloseNotificationIcon throws InvalidOperationException after hibernation
- MSBuild failure when building a project on a FAT system (hard links not supported)
- PostSharp HQ throws exception when saving a license key for all users
- Setup program displays maintenance dialog when in silent mode
- Setup program prompts to uninstall previous version of the VS extension even in silent mode
- The license registration wizard should not be displayed after a silent installation.
- Exception in MulticastAtributeTask when a parameter-level MulticastAttribute is applied to a property
- Unused AssemblyRefs are included in the final assembly
- MulticastAttribute.TargetMemberAttributes is not respected for properties and events
PostSharp 2.1 is the fastest and most stable version of PostSharp and the upgrade is recommended for any one. To convert your projects, either use NuGet, either open PostSharp HQ and click on convert projects.
We’re now planning for PostSharp 3 and a new, truly disruptive, product that will change the landscape of instrumentation and diagnostic of in-production applications. We are hiring; drop us an email if you’re interested in joining the team.
This is one of these unpopular but necessary decisions that every software publisher has to do now and then. It’s generally accepted that pulling off expensive but little-used features is a healthy decision because it frees resources that can be spent on more popular features. This is what we are doing with documentation and support of PostSharp SDK.
What is PostSharp SDK?
PostSharp is made of two principal components: PostSharp.dll and PostSharp.Sdk.dll.
PostSharp.dll is the high-level public API. It mostly contains interface definitions, abstract classes and custom attributes from which developers can derive their own aspects. This library is designed to be used by developers of business applications. It offers transformation primitives (such as: intercepting a method, wrapping a method, introducing an interface) that developers can add to their code. PostSharp.dll leverages real aspect-oriented programming, a disciplined extension of object-oriented programming. Just as a normal compiler, the high-level API enforces syntactic rules, and you will get a reasonable error message if you violate them.
PostSharp.Sdk.dll is the opposite of PostSharp.dll. Its public API allows you to modify .NET assemblies at a very low level. You can do everything. The API does not enforce any programming discipline or syntactic rules. You can create invalid assemblies without even getting a warning. It requires you to learn the MSIL specification and to understand most of the 565 pages of the ECMA-335 specification. PostSharp.Sdk.dll is made of several components. The most low-level ones (code model, image reader, image writer) are also found in Mono Cecil and Microsoft CCI, although PostSharp SDK has its own implementation. PostSharp SDK also includes several middle-level components such as the project loader, the aspect infrastructure (which could allow you to use PostSharp SDK to develop an aspect weaver that has different syntax than PostSharp.dll), the aspect weaver (the implementation of the PostSharp.dll), the custom attribute multitasking components, and much more.
PostSharp SDK is more complex than you think
Contrarily to PostSharp itself, PostSharp SDK has a very steep, but misleading, learning curve. You get quite quickly the illusion that you “got” it, but the devil is in details. The 80-20 rules does not apply to PostSharp SDK: what applies is 95-5: 95% of time is spent in addressing 5% of cases. Think of MSIL programming as hiking in high mountains without a map. You always have the illusion that the top is near, but whenever you climb on what appeared to be top, you discover another, higher top. If you want to have an idea of the effort you’ll need to reach the goal, you need a map; ECMA-335 and the PostSharp SDK class reference will give you a fair overview of the complexity of your task.
So why do we have PostSharp SDK? First, for our own needs. From our own point of view, PostSharp SDK is the most important component of PostSharp. Secondly, because this API is useful to a tiny minority of ISVs with very specific needs (for instance: high focus on speed). They can afford to maintain MSIL skills because the effort is leveraged to thousands of customers. Third, because PostSharp SDK can be used to overcome missing features of PostSharp.dll. But this is where things can go wrong.
PostSharp SDK is undocumented and unsupported
There has been some criticism that PostSharp SDK is undocumented. This is not accurate: the class reference is quite complete and contains more than what’s obvious from the method signature. Many actually claim that PostSharp SDK has the best documentation of all MSIL rewriting tools.
What is true is there is no conceptual documentation. Let me be clear: the lack of conceptual of documentation is a feature, not a defect. The SDK will not be better documented. As any company, we have to allocate limited resources to a potentially unlimited number of features. It does not economically make sense to spend time in documenting a very complex API that is used by a dozen of customers.
The same holds for support. We cannot provide support on a highly complex and incompletely documented API. We cannot guide you through baby steps. PostSharp SDK is not supported. You use it at your own risks.
On the support forum, you could often read answers that sounded like “this is not possible to do with PostSharp.dll but can be done with PostSharp.Sdk.dll”, followed by a disclaimer that PostSharp SDK is hard and you should maybe not try. This had led some customers to ask for more information for these specific cases, which I published on the blog. Mistake! These blog posts have been interpreted as an advertisement of and an invitation to use PostSharp SDK. I apologize for that. I will not advertise PostSharp SDK again. It will remain unsupported and undocumented. The harmful blog posts have been withdrawn.
PostSharp SDK still available
That said, PostSharp SDK is still available for use in the Professional Edition. We are only making it clearer that this feature is not officially supported, and must be used at own risk. I believe that it’s not a good idea to code directly MSIL instructions unless you can leverage the effort to thousands of customers (as we do), but you’re free to try. It’s just that you’re on your own.
I’m aware this decision will be unpopular, but I’m convinced it’s a necessary one to continue provide good support to the community.
Happy PostSharping !