Archive

White Paper

Developers spend up to 20% of their time writing repetitive code that machines could generate more reliably. Download our new white paper 10 Reasons You MUST Consider Pattern-Aware Programming that explores the problem of duplicated source code that stems from manual implementation of patterns and reveals how to automate the boring side of programming and get a 19x ROI.

The document provides insight into:

  • why repetitive code is a major source of pain
  • what technologies for pattern automation exist today
  • why you should consider a pattern-aware compiler extension
  • what investment gains you should expect

 

The white paper was written for CTOs, software architects and senior developers in software-driven organizations—specifically in financial, insurance, healthcare, energy and IT industries that typically write a lot of repetitive code.

 

Webinar

Additionally, we hosted a webinar that covers the white paper topics. Watch the recording and learn about the consequences of boilerplate code and how to eradicate it with pattern-aware programming. You can also download the slides.

 

About the speaker, Gael Fraiteur

Gael started programming as a kid and never stopped - building and selling his first commercial software at age 12. He is the Founder and CEO at PostSharp Technologies, a widely recognized expert in aspect-oriented programming and pattern-aware programming, and speaks at developer events in Europe and the United States.

 

We at PostSharp have always been in tension between being innovative and serving big development teams with a more conservative mindset. When we decided to fully embrace NuGet in May 2013 and deprecate our other deployment methods, we truly belonged to the believers. You know, this optimism whispering to you ear that the clouds will move away just before the party starts. Today, we acknowledge that we didn’t serve our enterprise customers well by trying to force them into NuGet, and want to provide an alternative. We’re bringing back our folder-based (zip) distribution, and are integrating it better with our Visual Studio tooling.

What’s still wrong with NuGet?

Clearly, the first version of NuGet was designed to make it easier to get started with new projects on the .NET platform. Get people create a prototype with the less possible friction, so they get addicted to the platform, and are then more likely to accept its limitations. There used to be a lot of criticism in the first years regarding the use of NuGet in the long term. Many limitations have been addressed in NuGet 3. But there are still a lot of good reasons why large teams are right to reject NuGet.

1. NuGet Versioning Hell

One of the main problems of NuGet is that packages are versioned at project-level. If you have several projects, each one can reference a different version of the same package, and it can be difficult to reconcile the conflicts. The problem was exacerbated by the fact that NuGet would select the latest version of a package by default when installed into a project, regardless of the version installed in other projects in the same solution.

Fortunately, the problem was partially solved with NuGet 3. You can now select versioning policies, and it became easier to consolidate versions in the same solution. That seems very reasonable, but this is still insufficient.

A large customer of us has more than 200 developers on the team, more than 100 projects spread over a dozen of solutions. How can you maintain versioning in this setup? Can you imagine the pain of the build manager? For sure, he does not like NuGet. And he probably didn’t like us neither, because we forced him to use NuGet. No longer.

2. Lack of Trust in NuGet Gallery

Another frequent criticism of NuGet in large teams is that it makes it too easy for anyone to pull a dependency. Taking a dependency on a third-party component is a serious decision. Somehow, NuGet makes it too easy to do the wrong thing.

It’s not really NuGet’s fault, it’s rather because of the public NuGet Gallery, which contains unverified packages. Some companies may want to block access to nuget.org for good reasons. For these customers, we propose the curated package source https://www.postsharp.net/nuget/packages.

Using PostSharp without NuGet

As an alternative to NuGet, we’re re-introducing the folder-based distribution starting from PostSharp 4.3. The feature is hidden by default because we believe this is a minority use case.

To install PostSharp in a solution without using NuGet:

  1. In Visual Studio, go to PostSharp / Options / General / NuGet and check the option Always ask before using NuGet Package Manager.
  2. In the Solution Explorer, right-click on the project and then on Add PostSharp to project.
  3. In the wizard, select Install PostSharp into a new folder then select the installation folder of PostSharp.

As a result:

  • PostSharp compiler tools and libraries will be copied to the folder you specified.
  • A MySolution.pssln file will be created to store the location of the PostSharp folder, so that we don’t need to ask the next time you add PostSharp to a project of the same solution.
  • The project file (csproj) is modified to reference the copy of PostSharp installed in the specified folder.

Updating PostSharp without NuGet

Once you are using PostSharp in a solution (or set of solutions) without NuGet, it is very easy to update it. You just have to download the zip distribution from our web site (a file named PostSharp-4.3.x.zip) and extract it to the installation folder. That’s all. Because the folder name does not include the version number, there is no need to go through all projects and change references. What a relief!

Summary

One size does not fit all. NuGet does not work for everybody. Now you can hate NuGet and still love PostSharp. There is no conflict. Starting from PostSharp 4.3, we give you an option to simply extract the product to a folder and reference it. No more versioning hell, no more update headache.

Happy PostSharping!

-gael

P.S. This post is the second in a series dedicated to the new features of PostSharp 4.3:

  1. Command-Line Interface;
  2. Improved Debugging Experience;
  3. Alternative to NuGet deployment.

Where do development patterns fit into your world? Carl Franklin and Richard Campbell talk to Gael Fraiteur about the evolution of PostSharp into a library for implementing patterns. The combination of aspect-oriented programming and patterns is powerful - providing a means to implement a pattern while keeping it separate from your business code. Gael explores one particular family of patterns: multi-threading. PostSharp implements half a dozen different multi-threading strategies, so that you can apply the pattern as an aspect to your objects and make multi-threaded coding simpler and safer.

Listen to .NET Rocks Show 1269 and if you haven’t done it already, subscribe to the podcast and register to the fan club.

Happy listening!

-gael