It was in 2011 at TechDays Belgium, after a talk by Scott Hanselman (NuGet in depth: empowering OSS on the .NET platform), when Maarten Balliauw and I got talking about an idea we had. We created a prototype and by the end of the month, we launched MyGet, a hosted NuGet server on Azure.

At first, we used it as a playground for ourselves and some friends. A few weeks later we had about a hundred people using the service and we had our first feature requests coming in: people told us they wanted secured feeds. We bootstrapped a business model to cover for the hosting costs, and executed as lean as we possibly could. Today, 3.5 years later, we serve thousands of feeds and provide a solution for many developers, OSS projects and companies worldwide. You can find us in the Azure Store, we became VSO Launch partners at TechEd, and we even host nightly builds for ASP.NET and many other Microsoft products!

Some time ago, I noticed a vacant position on the NuGet team (well, two, in fact). Today, I’m super-excited to share that I’m joining Microsoft and the NuGet team!

I’ll be working remotely on stuff I’m passionate about and feel I’m joining at an exciting time with many cool things to come: NuGet (and package management) is still building momentum! A few years ago, the average .NET developer didn’t know about packages. Then NuGet got introduced. Soon, we’ll be dealing with NuGet, NPM, Bower and many more tools integrated in our development on both .NET (vNext) and other languages.

What does this mean for MyGet? MyGet remains our private business and product. We’ll continue to provide the great service and support you’re used to! The only difference is that both Maarten and my agenda are now more aligned, and we’ll be in package management 24/7.

Looking very much forward for what’s next!

Unless you lived under a rock during the last few days, you should know by now that Microsoft shipped a Preview of VS2015 with support for ASP.NET vNext. Such announcements traditionally result in developers screaming "yeay, new bits!", late night coding and unlocking Untappd badges with each commit.

Working on a little side project, I wanted to explore ASP.NET vNext beta1 on Azure Websites. I quickly learned that Azure Websites currently only provides alpha-support. On top of that, the kvm command switches have changed (esp. kvm install), so there's no straightforward kvm upgrade that will do the trick. This post shows you how I got an ASP.NET MVC6 beta1 application working on Azure Websites using x64 CoreCLR (Note: my Azure Website is configured to run x64 on the Basic tier). Feel free to use whatever version you want, YMMV!

Instructing Kudu to run a custom deployment

First things first: for this to work, you'll need to take advantage of Kudu by connecting your Git repository to Azure Websites. Let me Google that for you with Bing! Kudu will generate deployment scripts under the hood and deploy your website when pushing changes to your source repository. However, deployment will fail for an ASP.NET vNext beta1 application. To fix this, you'll need to customize the deployment scripts. This is the easiest part: simply add a .deployment file and an empty deploy.cmd to your source repository (don't bother downloading the script that Kudu uses out-of-the-box, it's flawed at the moment). The .deployment file looks like this:

[config]
command = deploy.cmd

Before we take a look at the deploy.cmd, we'll first have to setup the K Version Manager (KVM).

Setting up KVM

As the interactions with the Azure Websites environment are constrained due to security, we can't just install kvm by following the Getting Started guide (not during deployment, and not from within site extensions). Installation will fail as the kvm.ps1 script being used under the hood contains lots of Write-Host statements that will cause exceptions. In fact, when you try this, the first Write-Host statement encountered is the one that should log an exception to the console, so it just doesn't work.

This leaves only one option: having a kvm.cmd in the repository root calling into a customized kvm.ps1, and call it from a custom deploy.cmd. Let's skip the download process and adapt the PowerShell script to our needs and check-it into source control. The following links point to their gists:

• kvm.cmd
• kvm.ps1

The kvm.cmd file is unmodified and matches the one from the ASP.NET GitHub repository. The kvm.ps1 file I created is also based on the v1.0.0-beta1 tag and has the following modifications:

• It uses a WriteLine function that simply echo's the text into the console host, and all calls to Write-Host are replaced by calls to this WriteLine function.
• The ZIP unpack logic in the script (which uses PowerShell's built-in unzip functionality) is replaced by calling into .NET's ZipFile::ExtractToDirectory method. The original extract logic didn't work and silently failed.

Customizing the deployment

Now we have almost everything in place except for the real deployment instructions. The deploy.cmd file is the one that our .deployment file points to so let's take a look at how we can leverage our custom KVM.

I didn't create this from scratch though. Remember, I started from the deployment scripts that got generated by Kudu. In a nutshell, here's what the script does:

1. Check pre-requisites and configure environment variables
2. Install KRE (by calling into the custom kvm.ps1 file)
3. Run KPM restore
4. Run KPM pack
5. Run KuduSync
6. First-hit of the web site (warm-up call)

The full deploy.cmd file can be found here: deploy.cmd. You can easily customize the script to your needs by changing the variables set in lines 82-85.

SET KRE VERSION=1.0.0-beta1
SET KRE_ARCH=amd64
SET KRE_CLR=CoreCLR
SET ProjectJsonFile=My.Awesome.DemoApp\project.json

Wrapping up

I'm sure built-in support is coming, but if you want to have a play with it on Azure Websites today, this might just do the trick for you. I'd like to thank David Ebbo for pointing me towards this tweet, referencing Louis DeJardin's GitHub repository: it helped me to get this working :)

Link to all gists used in this post: https://gist.github.com/xavierdecoster/c56561312891eb788b8d

What is OneGet?

OneGet a unified package management interface component with a set of managed and native APIs, a set of PowerShell cmdlets, and a WMI provider. The component accepts both Microsoft-provided and 3rd party-provided plugins which extend the functionality for a given package type.

The OneGet team also has a weekly community meeting of which you can see the first introductionary recording below.

As part of this Preview, OneGet is shipping with a prototype plugin compatible with Chocolatey, the so called ChocolateyProvider. This is a prototype implementation of a Chocolatey-compatible package manager that can install existing Chocolatey packages. This is a clear confirmation for the hard work done by the Chocolatey folks, and both systems will continue to evolve together, as Rob Reynolds explains in this post. If you want to follow-up on OneGet, then check out its GitHub repository and follow PSOneGet on Twitter.

Something about a forest and trees...

NuGet, MyGet, Chocolatey, OneGet... what?! People ask questions and occasionally can't see the forest for the trees. Here's a quick recap:

• NuGet: a solution-level package management tool, used to manage software dependencies within the scope of a solution. It is accompanied by the NuGet Gallery, the home of many if not all .NET open source components.
• Chocolatey: a system-level package management tool, used to manage software installations on a Windows system. It (currently) leverages PowerShell and NuGet, supports the Web Platform Installer (WebPI), MSI, RubyGems and many more, and is accompanied by the Chocolatey Gallery where you can find many popular software packages. Rob describes Chocolatey as somewhat like "apt-get", but with Windows in mind.
• MyGet: a hosted NuGet package server where you can create and secure your own feeds. In essence, MyGet is able to host vanilla NuGet feeds, as well as Chocolatey feeds.
• OneGet: a a unified interface to package management systems (see above)

So what does this mean? How do these package managers play along?

OneGet supports multiple package sources, and as stated earlier, OneGet comes with a ChocolateyProvider. As MyGet also supports Chocolatey feeds, this effectively means that you can register a MyGet feed as a Chocolatey package source in OneGet! The below diagram is an attempt to illustrate how they relate:

OneGet supports several commands at this stage:

How can I use a private OneGet package source?

So how can I register a private OneGet package source? Well, let's first see how you can register any package source using the Add-PackageSource cmdlet. Here's what the built-in help currently says:

Note that this is a Preview: help is incomplete and cmdlets might change name, but this should already give you a good idea of what you can do with this cmdlet!

Now, let's register a MyGet feed on which you can host Chocolatey packages:

Did you notice how OneGet asked you to install the NuGet package manager?

That went easy right? That's because that feed was public :) OneGet does not support basic-authentication at this point, nor does it leverage any nuget.config settings you might configure (tried it). However, MyGet just added the possibility to use a "private-by-obscurity" endpoint on private feeds, which should allow you to use private feeds as well. Note: we don't actively promote this, as it requires you to share one of your feed's access tokens. This is a work-around for clients that don't support the basic-auth flow, and we'd prefer to have proper basic-authentication support in OneGet, so fingers crossed!

You can verify the correct registration of your OneGet package source using the following commands:

Installing a software package from this MyGet feed is straightforward as well:

This flow allows you to control what packages get distributed through OneGet, avoids the need to publish your internal software to the general public, and still allows you to leverage the great new scenarios that OneGet offers!

As usual, happy packaging! :)

I'm quite a fan of Semantic Versioning (SemVer). It is the most pragmatic approach towards software versioning that I know of. If you don't know about SemVer, then you should go read the spec now. However, it is not perfect. Mostly because people are not perfect and some aspects of the specification can be interpreted differently. Actually, the spec itself is pointing this out – and I quote:

For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number.

Now, that's a big judgement call, isn't it? What is a public API? How do you define it in such way that it is clear to everyone without room for interpretation?

Recap: the semantic version format

I'm not going to explain the spec in detail here, but I want to quickly recap the most fundamental basics of it. SemVer has three version parts expressing semantics.

major.minor.patch

I'm ignoring the metadata that can be appended (such as build stamps etc). It's just metadata after all, so not important in this context. Instead, I'm going to focus on the semantics here, because that's really what this spec is all about: semantics and intent. These three version parts are indicators of the author's intentions:

• Major: incrementing this version part means that the author intends to indicate a breaking change in the public API (I'll try to define this public API later in this post)
• Minor: incrementing this version part means that the author intends not to break anything (and truly thinks he won't), but backwards compatible additions or changes to the public API have been introduced (at least, the intent here is that these things are backwards compatible)
• Patch: incrementing this version part means that the author intends not to break anything, and believes no changes to the public API happened. Furthermore, the author thinks you can safely upgrade to the latest patch release without any risks as changes are internal.

Defining the public API

As simple as the SemVer format may sound, the devil's in the details. How do you assess that your intentions match with the changes you may have introduced in your new release?

The first time you ever read the spec and start thinking about your public API, you'll likely limit your thinking to your code base and the public types and methods exposed in your libraries. Now that's obviously a good start, but reality is a little bit more complex. Let's assess the impact of the following, and these are real questions people ask themselves (rightfully!):

• What if I don't change anything in my code base and only upgrade one of my dependencies?
• What if the internal behavior of a public method on a public type changed, but did not affect its signature? (eg: public bool Type.IsSecure now returns false instead of true)
• What if a type moved to another assembly without changing namespace or any of its publicly visible members? (so only the "packaging" of this type changed)

You can already tell that a public API likely shouldn't be defined solely by signatures and type visibility.

First and foremost: this is just my personal perspective on things. This is what works for me and hopefully as well for anyone consuming the API's I create. If it doesn't work for you, then please don't hesitate to tell me why in the comments. If you have a better approach, then please share it with the world so I can learn from you.

SemVer is technology agnostic

SemVer is a set of pragmatic rules and tries to provide guidelines. However, it is also technology agnostic. On purpose! As much as I believe that the guidelines set forth in this spec are valuable, I also believe there's a need to define a standard definition of public API within the scope of a certain technology.

In .NET, we have a long history of looking at assemblies as the release vehicle. History shows us that versioning assemblies can quickly become problematic, and the words dependency hell may come to mind. That's mainly because a release vehicle also brings technical limitations to the way your API can and will be referenced.

• You apply strong naming? Why does that even exist? Oh, right, the Global Assembly Cache… Wait a minute, isn't that a Windows thing? Why should my public API care about that?
• You remember .NET Remoting? Then you're probably familiar with the breaking aspects of changing version numbers...
• Moving a type to another assembly requires consumers to recompile against your new assemblies, so again: breaking (even without any changes to the API of the type being moved)!

And then along came NuGet! Another release vehicle. Some packages contain a single assembly, some contain multiple assemblies, and some contain none at all! This is where many people lose faith in SemVer and start asking questions similar to the ones I mentioned earlier in this post. In fact, the SemVer FAQ and issue list on GitHub is full of those questions and related discussions.

My definition for .NET development

I'm trying to define a strict public API in an attempt that anyone consuming it has a clear understanding of what to expect. I'll restrict my definition to any .NET API that ships as an assembly (or set of assemblies) through NuGet. Why? Because I'm taking into account any changes to the release vehicles into the versioning strategy of my public API.

Hence, in my definition for .NET development, a public API is defined by:

• The public types, members and method signatures exposed in the consumable components
• The behavior of those types and members (if the semantics of an unchanged method signature change, that's breaking)
• The assembly qualified name of these types: did the type change assembly? (if so, that's breaking)
• The assembly signing: changing SNK is breaking! (and why the hell are you still signing assemblies? Can't we just stop doing that and move on?)
• The packaging of these assemblies: did the assembly change NuGet package? (if so, that's breaking)

I'm not sure whether I'm overlooking any other aspects of the public API, but using the above interpretation hasn't led me into discovering any. This definition also really helps me to clearly state my intentions when defining the semantic version vNext of any public API I own.

The sad part

The sad part about SemVer is that you can't interpret an author's intentions solely based on the version format. It's not because your versioning format happens to comply with the guidelines set forth by SemVer that you are using SemVer properly. If you're a log4net user, you might have been bitten by this before.

Or perhaps you jumped from v4.0 to v4.5? (Looking at you .NET Framework J) This is clearly an example of what I would call Marketing Driven Versioning. Technically, the .NET Framework doesn't apply SemVer (and no one ever claimed it does). In fact, most (if not all?) .NET 4.5 libraries have a version number of v4.0 (remember, it's an in-place upgrade). However, people get confused as the version format seems to be SemVer-compliant.

Moving forward

Moving forward, I really hope to see NuGet be fully SemVer compliant one day (I know it won't be trivial as there's quite a legacy of non-SemVer compliant packages on the Gallery). But even if all new packages would be enforced to be SemVer-compliant, I'd argue they're likely just SemVer-format compliant. And that's totally fine from a NuGet perspective as there's nothing more that can be done about that!

At the same time, that's why I'd love to see a standard definition of public API for anything that ships through NuGet. People need guidance and preferably this guidance is specific to their needs/scenario. The version format alone simply doesn't cut it: it doesn't say that it was the author's intention to be SemVer-compliant and as such, the version format alone doesn't clearly state the author's intentions with any new release.

If there is any metric I want to know about a package, then it is not the download count, but rather the number of times a package author has broken SemVer-compliance for a given package. Not sure how to solve that. Perhaps people should be able to report that a package upgrade from one version to another broke their stuff? Correlate the number of reports against the number of package-updates (not installs, not restores …)?

Anyway, I don't have control over any of this (and likely no one has), but I believe guidance is critical, and I hope someone finds value in this way of working. SemVer is awesome! I understand the reasoning behind it being agnostic on some levels. We should just state our intentions. I'd be happy even if just a single package author finds value in this post and improves his versioning strategy. Note that the goal is to propagate this happiness to all package consumers ;)

SemVer is not about code, it's about stating your intentions...

NuGet package restore used to be MSBuild-based. You had to explicitly enable it using the context menu on a Visual Studio solution: right-click the solution and select Enable NuGet Package Restore. In fact, if you go to the NuGet docs, you'll see that this scenario is still fully documented. A quick search for "package restore" will throw this old scenario "in your face", as it is the first hit in the search results.

To be fair, the page does highlight that there's a new way of doing this. But many people don't read. At best some look at the pictures. That's why I won't even include a screenshot of that page, as it is full of project setup details that no one should ever go through again. Instead, I'll give you a clear picture of what you should not do :)

You're doing it wrong!

I can't stress it enough. I'm a huge proponent of NuGet package restore! But if you follow this workflow, then please do it right! (and design for failure, obviously).

The MSBuild-based NuGet package restore has issues. For one: it's MSBuild-based. This means that anything that happens during package restore is run within the MSBuild process, which is particularly annoying for packages that want to modify project files and inject MSBuild targets (as these aren't picked up until the next run).

The moment you manually enable NuGet package restore through the context menu, you're actually installing a few NuGet packages: NuGet.Build, which depends on NuGet.Commandline. The nuget.exe along with a nuget.config and a nuget.targets file are created within a .nuget folder, and all projects that have NuGet package references will be modified to import the NuGet.targets file. The nuget.targets file ensures that nuget.exe is invoked during builds (as in: not before builds!).

The right way

All you need to do is to make sure that your Visual Studio options allow NuGet to download any missing packages in a pre-build phase (note: even before MSBuild compilation starts!). I'm not going to rephrase step-by-step what you should do as David Ebbo already has a great post explaining all of this!

If you're cloning a new project that did not commit any NuGet packages (and is not using the old MSBuild-based restore), then it just works!

Migrating from the old way

If you still have a .nuget folder in your repository, then please migrate away from it! Think about all those adorable kittens...

Did you know this has been documented on the NuGet Docs all along?! Follow this how-to and save yourself and everyone using your codebase some trouble and follow it step-by-step.

Even better: automate your migration using these awesome scripts!

For those not using Visual Studio or perhaps not even on the Windows platform: a simple call to nuget.exe restore *.sln before calling the compiler does the trick as well (add it to your build script, or perhaps you can configure your IDE to do this for you before each build...).

But... my precious (build server)

As long as you did not set the environment variable EnableNuGetPackageRestore=false then you're good to go. (default: EnableNuGetPackageRestore=true)

The following tools support the new automatic package restore out-of-the-box and Just Work™!

• Anything based on Project Kudu (Windows Azure Web Sites deployments, Windows Azure Mobile Services C# backend, ...)
• MyGet Build Services

The next list of tools requires some minor modifications to the build process:

• Visual Studio Online / Team Foundation Server (how-to)
• TeamCity (how-to)

Note that you don't need to worry about development machines! As long as you all have the latest NuGet Visual Studio extension installed (as of NuGet v2.7).

Upgrading your NuGet extension is generally a good idea anyway, as there are lots of improvements in the latest versions!

Going forward

Here's what I'd love to see happen going forward:

• The NuGet Docs should by default show the new non-MSBuild-based package restore instructions. There are close to none, but this should be thrown in your face when looking for it.
• Migration instructions should be clearly linked to.
• The old MSBuild-based instructions should be archived, perhaps even removed.
• Currently, when installing a NuGet package that injects MSBuild targets, you'll see the following piece of logic appear in your project files:
  

    <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
      <PropertyGroup>
        <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
      </PropertyGroup>
      <Error Condition="!Exists('..\packages\SomePackageId\Build\SomeMSBuild.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\SomePackageId\Build\SomeMSBuild.targets'))" />
    </Target>
  

  This is horrible as it is suggesting you to do the wrong thing: you should call nuget.exe restore instead!
• The context menu-item to manually enable NuGet package restore (MSBuild-based) should be completely removed from the extension. I don't see any reason to keep it. Do you? If you do, please comment on this CodePlex issue, if you agree, then vote for it :)
• Preferably, the next NuGet Visual Studio extension detects you are using the "old" restore option when you open a solution, and asks you to migrate/upgrade to the new way. Ideally, this removes the targets and import statements, and custom package sources and credentials are taken into account if they are in the nuget.config file. </ul> </p>

  I'm happy to take on an issue or send PR's for any of the above, but some of the bullet-points seem too big to me to be taken in as a PR.

I'm really honored to receive this award and find great satisfaction in the fact that Microsoft and the Community are appreciating my efforts to share experiences and insights in terms of NuGet, Visual Studio and ALM in general.

I hope to keep up to your expectations and deliver quality in everything I do, and I'm really looking forward to see what the next 12 months will bring. Challenge accepted! :-)

Thank you Microsoft for the MVP award. Thank you MEET for the awesome work you do! Thank you Community for a great collaboration and for giving me the opportunity to grow as a developer and as a person. Thanks to everyone who supported me in my efforts, including family and friends, colleagues, MVPs and many more!

If you hate manipulating the file system for a single project, imagine doing this for 50 projects. Let's automate this task and preferably without leaving our Visual Studio environment. There's the NuGet Package Manager Console after all.

Well, there you go: Install-Package NuSpec
Sources on GitHub

This package will install itself in the NuGet PowerShell profile, so you can immediately uninstall it, the new cmdlets will still be available. The following new cmdlets are available:

• Install-NuSpec <ProjectName> [-EnableIntelliSense] [-TemplatePath]
• Enable-NuSpecIntelliSense

Happy Packaging!

Although it is a situation I try to avoid, it is not uncommon to share project files between solutions. If you are using NuGet package restore on these solutions, and one or more of these shared projects is consuming NuGet packages, you'll likely hit issues. This StackOverflow question is an illustration of exactly this problem.

Symptoms

Developer A:

"I can't compile Solution2 anymore after pulling the latest version!"

Followed by:

"That's strange… it works on my machine." – Developer B

Instantly followed by handing out a Pink Sombrero™ to Developer B: (yes, you broke the build! Hopefully…)

Many teams have lost time debugging this issue, and although I already have quite an exhaustive checklist, this particular issue is not covered as I never really had to deal with this one. I prefer to consume the NuGet package instead of sharing the project…

Example

Behold the following sample folder structure containing 2 solutions. Solution2.sln also references the existing Library1.csproj file (note that it is not inside the solution's root directory):

Both solutions have package restore enabled. Solution1.sln has no issues at all.

Solution2.sln cannot build, because the referenced Library1.csproj project cannot reference its packages. This is tricky: package restore did work! But by convention, the packages consumed by Library1.csproj got installed into the solution's Packages folder, which in this case is Solution2\Packages. Package restore (behind the scenes nuget.exe install – horrible command name mismatch) does not install any packages: it downloads and extracts them. None of the package scripts are run, no content is injected, no references added.

If you locally have both solutions and you restored the packages consumed by Solution1.sln, then you'll be in the situation of Developer B where it works on your machine. However, Developer A who only opened Solution2 and never built Solution1 will get build failures (as will the build server).

Root Cause

1. NuGet Package Restore is MSBuild-based at the moment. It is being redesigned so I expect great improvements in the foreseeable future.
2. You're sharing projects and code between solutions. Why not package them instead? Wait, here comes the "debugging experience complex"… It is so convenient to just reference the damn code. I agree within the scope of a single solution.

Sharing between multiple solutions? Here's the deal: set up continuous (package) delivery and use symbols packages (or a symbols server as the one built-in to TFS). You can use SymbolSource.org or set up your own SymbolSource Server. If you need more in order to debug your solution, then frankly you might want to rethink what you're sharing here… This smells like tight coupling and a missed opportunity to share a package.

Patching up the open wound

Although I'd strongly recommend taking a closer look at these projects you're sharing, a short term solution to your problem is also MSBuild-based. You'll need to tweak the package restore command per project. The easiest way to do this is by introducing a new MSBuild property and only deviate from the default conventions when absolutely required. The projects that will require a deviation are those that are being shared obviously.

If you disregard the concerns I raised earlier in this post, then here's what I would do to fix this mess (quick-n-dirty style):

• In Solution1.nuget\nuget.targets, add the following MSBuild property before the <RestoreCommand> element:

<PackageRestoreDir Condition="$(PackageRestoreDir) == ''">$(SolutionDir)\Packages</PackageRestoreDir>

• Within the same file, update the <RestoreCommand> by appending the following:

<RestoreCommand>$(NuGetCommand) install … -o "$(PackageRestoreDir) "</RestoreCommand>

• In the Library1.csproj file, add the following MSBuild property (mind the order of precedence with <SolutionDir>):

<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == 'Undefined'">..\</SolutionDir>
<RestorePackages>true</RestorePackages>
<PackageRestoreDir>$(SolutionDir)..\Libraries\Packages</PackageRestoreDir>

Repeat the last step for each existing shared project you referenced in your second solution. The <PackageRestoreDir> should match the project reference and the default package restore directory of the main solution of that project.

You can download a sample solution here.

Happy packaging!

I've recently announced my ReSharper Razor plugin and published the EAP package to the brand new ReSharper Plugin feed. I've originally built it against the ReSharper 7 SDK and only recently added support for the ReSharper 8 EAP SDK. One of the questions I asked myself when I built the R# 7 version was: how do I ship it? I was quite thrilled to receive an email from Matt Ellis (@citizenmatt) inviting me to take a look at the latest SDK bits which included the new NuGet-based Extension Manager! In this post I want to show you how I'm using free tools to develop, build, package, test & publish a ReSharper plugin.

The missing link?

The plugin obviously is open source. The source repository for this plugin can be found on GitHub: https://github.com/xavierdecoster/ReSharper.RazorExtensions.

One of the first things I do when starting a new project is setting up Continuous Integration. Yes! Even for a little OSS pet project! In this case, the output of my build should be a NuGet package containing the plugin, so I need a repository to serve these CI packages for consumption to facilitate testing. Each GitHub repository has this great feature called Post-Receive Hooks which allows you to trigger another service whenever someone commits to the repository. Sounds useful, right?

Let's rephrase that: whenever GitHub triggers a service, it should build the sources, package the plugin and publish it on a NuGet feed for consumption. I know another free service for that: MyGet!

MyGet "Wonka" Build Services allows you to connect your GitHub repository to a MyGet feed. It is designed to take care of building, testing, packaging and publishing consumables. I like to think in terms of consumables and consumers: don't try to build and package your enterprise web sites on there. We're likely missing some fancy SDKs anyway and we refuse to install Visual Studio J For this scenario however it's perfect! But I'm biased J

Connecting the services

To develop a ReSharper plugin you need to reference the ReSharper SDK. It's not available on NuGet, so you'll need to download the MSI. It comes with some nice project and item templates for Visual Studio, and the SDK is quite large. My plugin only used a limited set of binaries from this SDK so I decided to commit them into Git (yeah, I know, bite me…). It's for the greater good, as the SDK won't be installed on the build agent and isn't available as a NuGet package to restore.

When you're a MyGet feed owner, you can add and configure a build source for your feed. Click on the Add from GitHub button and select the repository you want.

You'll need to authorize MyGet to get access to your GitHub repository, and you'll be prompted with a dialog to select the repository you want to connect to.

We'll select the master branch by default, but you can obviously change that if you want. You don't need to edit anything else on this build source for now as you're already presented with a HTTP POST hook URL.

Next up, connect your build source to GitHub. Browse your GitHub repository settings and look for the Service Hooks tab. There you're able to enter a WebHook URL as shown below. This URL will be hit with a POST request whenever someone pushes to your GitHub repository and passes some information about the push event.

This provides enough information to MyGet in order to clone this repository and run a build. MyGet Build Services uses a conventional approach and selects one of the following artifacts in order of precedence:

1. Build.bat (or build.cmd or build.ps1)
2. MyGet.sln
3. Any other .sln
4. All .csproj files (or other project types)
5. All .nuspec files

It is up to you to ensure your repository is in a suitable format for an automated build. If you like full control over the build process, then you'll be happy to find a build.bat file in my repository. That's it, whenever I push a commit to my GitHub repository, a MyGet build will be triggered: it will compile my sources, run any tests available, create a NuGet package for the plugin in the ReSharper plugin package format, and push the package on my MyGet feed for consumption.

Consuming the plugin from a MyGet feed

Open the ReSharper Extension Manager (of all places, it's available in ReSharper > Extension Manager), and click on Settings. Just as with the NuGet Visual Studio extension, the ReSharper Extension Manager allows you to configure any NuGet feed for consumption. Simply add your MyGet feed url into the list:

Save your settings and reopen the Extension Manager: you'll find your newly added feed in there. All CI packages you publish on that feed will be available for consumption.

Even better: ReSharper will notify you about available updates for your plugins!

Release some!

As soon as you're satisfied with your plugin, you can release it to the masses. Here I'm going to use MyGet's package sources feature: any MyGet feed can have one or more upstream NuGet feeds. This allows for various scenarios such as aggregating feeds, filtering, proxying & mirroring, but also package promotion.

In order release a CI package, you need to promote a package to the ReSharper Plugin feed (and optionally change the package version, e.g. strip the pre-release tag). To be able to do this, you first have to configure the ReSharper plugin feed as an upstream package source. We just announced the availability of a new preset for this on the MyGet blog.

Browse to your feed settings and select the Package Sources tab. Select Add Package Source and click on the Preset button in the top-left of the dialog. You'll find a new ReSharper extension gallery preset. Don't forget to configure your API key for the ReSharper Gallery or your package can't be pushed upstream as the request would be unauthorized.

Whenever you want to release a new version for consumption, simply promote your package to the release repository with a click of a button.

Conclusion

Matt and the ReSharper team have really done a great job by adopting NuGet as a protocol for distributing plugins. It makes these plugins more discoverable and it's a breeze to install them or keep them up to date. As a plugin author (actually, any OSS developer), you should really leverage all the (often free for OSS!) tooling available: many organizations can only dream of such a streamlined development workflow. Releasing a new version of my plugin is really just a commit (or a pull request) away! Commit, push & consume!

I must admit, every now and then I find myself typing yet another semicolon in one of my razor views. I usually also hit the backspace key immediately after. But sometimes, a lone wolf semicolon gets through and is rendered in the resulting HTML page. I HATE this! It's the most silly bug report you'll ever spend time on. The effort-value ratio of filing the bug and resolving it is far below zero, but as it is a UI issue it most likely will get prioritized over other more important stuff. It's still waste. ReSharper is great at reducing waste, so I figured it'd be a good idea to have a ReSharper code inspection to highlight these semicolons and generate warnings. To my surprise I found this wasn't built-in so the idea of a plug-in was born.

I've built a very simple XML-minification plug-in for ReSharper before, but didn't really plan the time for building another one. The ReSharper SDK is quite awesome, though it could use some more loose-coupling and perhaps be NuGetized? I popped the idea on Twitter to see if people would think it's useful or not, and in the hopes to find someone who had the time or was willing to assist. A huge thanks to Matt Ellis (@citizenmatt) and Igal Tabachnik (@hmemcpy) for your enthousiasm and sharing some very useful pointers on how this plug-in could be implemented! Your input made it look like a no-brainer so I figured it couldn't harm to spend half-an-hour on it.

The idea was to build a custom daemon to analyze HTML tokens within a Razor file. Razor files can contain HTML, JavaScript, Razor-syntax, C#, CSS… and hence are considered a multi-language PSI file. Bear with me, it's actually pretty straightforward and there's a great sample daemon implementation included in the SDK as well. It's a matter of understanding the concepts, reading the sample code, writing some similar code and hitting F5 a few times to debug your own implementation. This plug-in is only 5 classes!

The SDK comes with a set of project and item-templates, pre-configured to provide the necessary "devenv.exe /ReSharper.Internal" instructions to unlock some ReSharper internal utilities in the Visual Studio instance you'll be debugging. The PSI Browser is a kind of document explorer and provides a ton of information on each element, character and its context within the file.

That's how I found out I only needed to inspect the HTML tokens. It also showed me that a whitespace character is a separate token, thus splitting up HTML tokens containing text. Finding the suspicious semicolon (usually at the end of a Razor statement and at the beginning of meaningful HTML tokens) is as easy as finding the HTML token that only contains a single semicolon character. This covers about 95% of semicolon mistakes I believe, which is good enough for me at the moment. I also didn't want this plug-in to generate warnings for the semicolon character in code snippets, in HTML entities (such as &copy; for instance), or in smileys ;-).

This plug-in will provide warnings and highlighting when a suspicious semicolon has been detected in a Razor view, and a quick-fix to get rid of it ALT-ENTER-style.

Just file an issue on my GitHub repo if you find something fishy, and note that I accept pull requests (and will happily add your name to the Author's tag of the NuGet package that this plug-in will ship in).

JetBrains just announced the new ReSharper Extension Manager using a NuGet feed which is now also available as a package source preset on MyGet. For those interested: I've hooked up my GitHub repository with my MyGet feed's POST hook, so I can automatically package-n-publish the plug-in for testing and release it with a click of a button. I'll do a follow-up post on how I did this, but for those who can't wait, there's useful info in this blog post (I'm using a build.bat file to hook into the build process).

To install my ReSharper extension, you need ReSharper 8 EAP or higher. For those on an earlier version of ReSharper, check for a compatible download in my GitHub repository.

Installing ReSharper plug-ins shipped as NuGet packages and get notifications about available updates: killer feature if you ask me!