In the build up to Christmas we have been busily preparing for our next release of VSPAT NuPattern. This release will not only support VS2012, (as well as VS2010 of course), but we are rebranding the name and targeting a new audience in the hope of encouraging more supporters and contributors to find value in, and follow the project. We need more contributors!!!
The big part of this upcoming release has been creating a version that works in VS2012. As well as dealing with the gray scale look and feel, new themed styles, and binary incompatibilities between VS2010 and VS2012, it has been a huge technical challenge figuring out how to maintain a single code base that can be targeted for building our VSIX toolset for both VS2010 and VS2012. You may be surprised to know that it is almost impossible (unless you have a very simple VSIX extension) to create one that works in both VS2010 and VS2012. At the time of writing, there is not a whole lot of practical help nor guidance out there for VSIX builders to help them deal to these compatibility issues. And the only viable and workable solution is to create two versions of your extension, each targeted to a specific version of VS. That usually means splitting the codebase (proliferating the problem), multiple solutions, awkward and tough workarounds in the code, multiple VSIX deliverables and lots of complexity! Not good news for an open source project wishing to attract new contributors! The root cause of all this drama? the VS teams decided a while back on a very poor (and what seems to be a partial) versioning strategy that includes naming some assemblies with the version number in their name (e.g. Microsoft.VisualStudio.Shell.10.0.dll) which has now led to having a deep impact on VSIX extension builders. The issue may not be apparent at first look. But for example, if your wizzy extension is built against a VS assembly like the one mentioned, which is a core extensibility assembly for VSIXes, your extension simply won’t run against the newer version of the assembly in the next of VS, because that assembly will be named Microsoft.VisualStudio.Shell.11.0.dll. Different name, different assembly, binary incompatibility issues. Even redirecting the assembly bindings won’t work.
Naturally, no software project every desires to maintain separate source code branches/forks/whatever for the same product just because you have to deal with different versions of your platform (in our case VS). We chose not to accept this disappointing outcome, so I have been putting in the hard cycles figuring out all the workable strategies and mechanics of dealing with both versions of VS (and potentially others down the track) so that we can maintain a single codebase with one set of unified shared features (at least at this stage). Of course, its pretty disappointing that Microsoft has not made this easier for VSIX builders like ourselves with the new release of VS2012. Not only have we had to deal with the assembly naming conflicts, but we also have to deal with breaking changes in API’s, and changes (bug fixes) in static artifacts (i.e. *.targets files, text templates, and changes in project types) shipped in the VSSDK, DSLTools and testing frameworks. Which has made life even harder for our project. You see our particular project specializes in creating VSIX toolkits, which themselves will face these compat issues a well. But enough of that, if you are interested in how we resolved these compat issues and kept a single codebase on the project, take a look around the 188.8.131.52 branch (and pending pull requests) of the source code on the project. I am happy to provide more in depth info about this later if asked. See the developer notes for more details if you want to take those steps.
So at this stage, the current development iteration for the VS2012 edition is just about at a close. We are still waiting to resolve the long outstanding dependency we have on Feature Builder Power Tool, and hoping that sorts itself out early in the new year. Once we have a resolution to that issue, we will have a new release shortly after, and we can start to focus on building a larger community around the project and pattern toolkits.
As part of this upcoming release, the big news is that we have a new name for the project. We are now called ‘NuPattern’. Which replaces the name ‘VSPAT’ from here on out. You can check out the discussion thread on how we converged on that particular name, it has been something we have been deliberating on for some time, and now with the new major release, and change in project ownership, it seems like the right time to make the change. We never really liked the VS association in the VSPAT acronym, and based on feedback, it was too much of a mouthful. Besides, no one ever remembered the acronym correctly anyways! We needed a proper and cool project name that people will remember, and vaguely associate with the delivered technology.
We are hoping that the new name appeals to (at least attracts) many of the same engineering audiences that may use NuGet today, and for the same kinds of reasons that those folks use and build NuGet packages (automation, consistency, reliability, relevancy, trust, etc.) , we hope they see the value in using and building Pattern Toolkits too. NuGet –> NuPattern. maybe?
Of course, NuGet consumers are not he only kinds of software professionals NuPattern should appeal to. See below. But, we are proud to show solidarity for the ‘Nu’ prefix in our name, as we are incidentally very closely related projects (e.g. in origin, platform, audience, etc.), and perhaps that may even encourage a new wave of other OSS projects to using this prefix to grow a family of new and exciting technologies around automated software development and deployment. Besides, I am not embarrassed to say that if the NuPattern project attracted even a small fraction of the audience that NuGet has over the years, the investment that has been made in the NuPattern project will have been finally realized.
As part of the name change, we have of course had to change a bunch of project collateral, including the codebase, all the documentation, and our project sites. So, the good folks over at The Outercurve Foundation recently asked me to identify exactly the target audiences we are going after with the new brand, and how they can help target that audience better. A question I have been answering for several years, and I think I have had a crack at it about a thousand different times for just about every kind of audience. But for this particular request, I think I captured a pretty decent summary that I felt was worth sharing, and in doing so, I though it might be a good way to get some feedback on whether you think we have targeted the right audiences or not.
Thanks goes to Don Smith, who helped me frame this question and answer better than I have done in the past.
So the broader question really is, “What is NuPattern” and who does it apply to”?
The short answer: VSPAT is a set of Visual Studio extensions that help you build Visual Studio extensions, called ‘Pattern Toolkits'. The people that build the ‘Pattern Toolkits’ are called toolkit authors. The people who use the ‘Pattern Toolkits’ to develop/deploy software are called toolkit users.
The longer answer:
Let me know what you think?
Happy New Year!