Share via

Season’s Greetings

  • Article

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!!!

Compatibility Issues

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 1.3.20.0 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.

A New Name

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.

A Question

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.

Question:

So the broader question really is, “What is NuPattern” and who does it apply to”?

Answer:

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:

  • Users: these are ordinary (software/infrastructure engineers) developers/deployers from any organization/community/project, who are chartered to design and develop a solution.
    • They are entrusted to comply with any practices/standards/principles for the project, and generate and apply elegant and efficient solutions to problems they face on the project. They take accountability for their personal input into the project.
    • They architect, design, craft code/scripts, and deploy software, they experiment, they seek knowledge and mastery of their technologies as they encounter them on their project.
    • They define themselves by their mastery of their technologies, tools, architectures, solutions etc.
    • They are looking for great flexible tooling that helps them complete their work, the way they work to an acceptable standard, and rapidly. They seek guidance and best practices, and tooling which understands their specific technical needs on the project, using agreed-to technologies and architectures defined for the project.
    • They expect to be provided tooling that does the heavy lifting and tedious tasks for them, but at the same time, allows them the freedom to create and manipulate the outcome.
  • These folks are the ultimate end users of the custom toolkits that the Authors (below) will build for them, using NuPattern.
  • Authors: these are the seasoned and skilled (software/infrastructure engineers) developers/deployers from any organization/community/project, who are entrusted by organizations/communities/projects to ensure high-quality, correctness and completeness of solutions the organization/community/project embraces.
    • They are entrusted to define and enforce that best practices are followed on their development/deployment projects, so that maintainability and supportability of the project long term is assured. They take personal accountability for the success and the future of the projects they work on.
    • They architect, design, craft code/script, and deploy software, they experiment, they seek new knowledge and maintain mastery of patterns, proven technologies and tools, as they evolve.
    • They define themselves by their ability to identify, reason about, select and adapt patterns of implementation across similar solutions.
    • They architect new processes, practices and solutions to make other developers more efficient, and to maintain high levels of quality, reliability, maintainability and supportability of the software.
    • They organize, guide and refine processes to help other developers/deployers in complying with those architectures and processes.
    • They are looking for great flexible tooling that they can manipulate, to adapt and apply automation to solve general problems across their projects. They will have already developed their own tooling/scripts/automation etc. to help apply best practices they have proven to be successful across multiple projects.
    • They expect to have to harvest commonality and define variability in patterns across multiple solutions, and generalize the requirements of the project for reuse in another.
  • These folks are the authors of the custom toolkits, that are used by the Users (above) to bring higher productivity and consistency to their projects.

 

Let me know what you think?

Happy New Year!