In the previous chapters, we’ve shown you how you can leverage NuGet in more-advanced scenarios and how NuGet can be the tool of preference for managing external dependencies in your software projects. We’ve even touched on some alternative scenarios, where NuGet can be used to distribute releases and deploy them onto your server infrastructure.

While all of this is great, there are some use cases we haven’t covered yet. The power of NuGet is its simplicity: it enables you to publish and consume packages. There are three major clients that work with NuGet. And all three of them can be extended to give you more power. For example, wouldn’t you like to know how you can make yourself or your development team more productive? Or how you can get a grasp on what external dependencies are being used in your projects?

This chapter will focus on these questions and will provide the required starting points to extend NuGet on your machine, or the machines of your team, to make software development more fun. We’ll start with a quick why before we dive into the more technical part, where we’ll be creating plug-ins and extensions for all three clients—simple, basic things that you can extend or build upon to achieve super powers.

Why Extend NuGet?

The enthusiast software developer in you may answer the question of why one should extend NuGet with an energetic “because I can!” While that is a valid reason (and also the reason why we started looking into extending NuGet), there are some better reasons to do so as well.

If you’ve heard about Git, a distributed version control system (DVCS) that gained enormous popularity in the open source world thanks to GitHub.com, you may be aware that Git offers various extensions. In fact, the Git source control system is fairly easy and does not contain a lot of commands at its core. The real value of Git as a source control system comes from its easy-to-create extensions, of which a lot are available.

A parallel can be drawn to NuGet. Out of the box, the NuGet command line knows the commands list, pack, push, setApiKey, install, restore, upgrade, and uninstall. Those commands give you a great base set of functionality; you can do everything you probably want to do with them. But what about copying a package from one feed to another? A nuget copy command would come in handy there. What about knowing about all packages and their dependencies without having to open every single project in Visual Studio? Wouldn’t nuget analyze be useful?

Similarly, for the NuGet Package Manager Console, it’s great to have some functionality out of the box. Knowing that the Package Manager Console is just a PowerShell console with some added variables (such as $dte, an object representing Visual Studio) makes it an incredibly powerful tool to extend your development process. What about creating Team Foundation Server (TFS) work items or YouTrack issues from the Package Manager Console? What about writing packages that add some to-do tasks to your list of work items? What about adding code generation or even a Bing search in there?

NuGet Package Explorer (NPE) is a great tool to work with NuGet packages and inspect what is going on in there. The lib folder in NuGet packages typically contains only an assembly and not source code. How about creating an NPE plug-in that allows you to decompile assemblies in a NuGet package and browse through the source code of the packages you download?

We’ve just scratched the surface in this section: all tools are there for you to use; all extension points are available. This chapter will give you some starters on how to extend the various tools, but we’ll leave the implementation of the cool stuff to you. And when you’re finished, why not publish your extensions on NuGet so everyone can use them?

Extending the NuGet Command Line

The NuGet command-line tool is built in a very extensible fashion. For starters, every command that the command-line tool exposes implements the same ICommand interface. In addition, the tool is using the Managed Extensibility Framework (MEF) to import (actually ImportMany) these commands within the scope of the application’s lifetime. It does this by scanning its own assemblies and a special extensions folder defined by the command-line tool. It is the exact same folder used when deploying a custom package analysis rule. This special extensions folder can be found in the following location on your system:

%LocalAppData%NuGetCommands

Because the NuGet command line is scanning this extension folder upon startup, it will automatically detect any assembly within that directory or any of its subdirectories that contains an export of a well-known type.

Some of the exports that will be scanned for are implementations of NuGet’s ICommand interface. The ICommand interface is decorated with MEF’s InheritedExport attribute, as shown in Listing 9-1, declaring that any implementing type will be exported as an implementation of type ICommand.

Listing 9-1.  The NuGet Command-Line ICommand Interface

[InheritedExport]
public interface ICommand
{
    CommandAttribute CommandAttribute { get; }
    IList<string> Arguments { get; }
    void Execute();
}

To be able to create your own custom ICommand implementation, you’ll have to add a reference in your project to the nuget.exe file—that’s right, to the NuGet command-line tool itself! All you need to do is implement the interface, compile your assembly that exports your custom commands, and deploy it into the NuGet extensions directory. The concept is very simple yet so powerful.

Creating a Custom NuGet Command

Creating a custom NuGet command is as easy as implementing the ICommand interface or its easy-to-use companion, the Command class. This interface (and companion class) can be found in the nuget.exe assembly. Here are the steps required to get started in Visual Studio:

1. Create a new Visual Studio solution, and add a class library project by using the full .NET 4.0 Framework.
2. Add a NuGet reference to Nuget.CommandLine (Install-Package Nuget.CommandLine).
3. Manually add a reference to nuget.exe. You’ll find it in your solution’s packages folder, where you installed Nuget.CommandLine in the previous step. Adding a reference to nuget.exe gives you access to the ICommand interface, the Command class, and the CommandAttribute class.
4. Add a reference to System.ComponentModel.Composition (the Managed Extensibility Framework).

The ICommand interface is very straightforward to implement, as it contains only one method, Execute, and a read-only property, IList<string> Arguments. Obviously, the Execute method executes the command, and the Arguments property gives you access to any command-line arguments received by the console.

To make things even easier for you, you can also inherit from a base class implementing this ICommand interface and providing you with some common NuGet command behavior, such as integrated help from the command line. This integrated help gives your custom command support for the help (or ?) option, so you can output some help information to the user instead. This way, you can provide guidance to users requesting help by executing the command nuget help or nuget help myCustomCommand. The base class we refer to is called Command and can be found in the NuGet.Commands namespace of the nuget.exe assembly.

To get started, take a look at the NuGet.Analyze package , which provides some analysis functionality on top of source code repositories consuming NuGet packages. The package is a first attempt to automate the creation of a dependency grid for a given project, which is currently a manual and time-consuming task, often forgotten or allowed to become out-of-date. However, NuGet stores all your dependencies in a nice XML file (the packages.config file) relative to each Visual Studio project, as well as storing a reference to all these XML files in a central repositories.config file in the solution’s packages folder. This is very useful information stored in a well-known format, so analysis of these files should be pretty straightforward.

For any solution that is consuming NuGet packages, you can find out which module of the product (or project of the solution) has which dependencies, even without parsing the information inside the source code itself. Therefore, one should be able to point NuGet to a solution file and get a real-time view on its dependencies. The output could be used as a generated dependency matrix for the given target solution.

The NuGet.Analyze package has support for both Team Foundation Server source control and local (or remote) file system folders. This should cover most source control systems in a first attempt. Of course, as the entire thing is open source as well, feel free to contribute your own ideas and send a pull request. The source code can be found at https://github.com/xavierdecoster/NuGet.Analyze.

Let’s take a closer look at AnalyzeCommand, which you can find in the source code. You’ll notice the usage of a few attributes in that class, as shown in Listing 9-2.

Listing 9-2.  Implementing a Custom NuGet Command-Line Command

[Command(typeof(AnalyzeCommandResources), "analyze", "AnalyzeCommandDescription",
UsageSummaryResourceName = "AnalyzeCommandUsageSummary",
MinArgs = 0, MaxArgs = 1,AltName = "analyse")]
public class AnalyzeCommand : Command
{
    public override void ExecuteCommand()
   {
      ...
   }
}

To create a basic command, you simply inherit from Command and implement the abstract ExecuteCommand method. However, you still need to expose a little metadata for the NuGet command line to know how to deal with this command. That’s where CommandAttribute comes in, which you can see decorated on top of the class declaration. Nuget.exe will process this information and learn that the analyze command corresponds to the AnalyzeCommand type. An alternative name for the command has been provided as well: analyse.

Helpful information, such as a usage summary, can be found in the AnalyzeCommandResources file by using the key AnalyzeCommandUsageSummary. Figure 9-1 shows you what the AnalyzeCommandResources file looks like.

Using the CommandAttribute, the NuGet command line also knows that zero or one argument can be passed to this command. That’s a lot of information in a single attribute, but it gives you a lot of flexibility to implement your command as you want, without needing to take care of plumbing your command into the command-line tool to make it integrate nicely.

We already mentioned that you inherit support for the help option when deriving from Command, but you can create additional options or flags that can give an extra meaning or different behavior to your custom command. For example, Listing 9-3 implements an argument as a simple property, decorated with the OptionAttribute. Figure 9-1 contains the messages referred to by the OptionAttribute as well.

Listing 9-3.  Implementing an Optional Flag for a Custom Command

[Option(typeof(AnalyzeCommandResources), "AnalyzeCommandVerboseDescription")]
public bool Verbose { get; set; }

Installing a Custom NuGet Command

You now have learned all there is to extending the NuGet command line with your own custom commands: inherit Command and distribute the compiled assembly to the NuGet extensions directory. The classical way of installing a command-line extension is shown in Listing 9-4.

Listing 9-4.  Installing a NuGet Command-Line Extension the Classical Way

nuget.exe install /excludeversion /outputdir "%LocalAppData%NuGetCommands" MyCustomExtension

How do you feel about distributing those assemblies? What if we could make NuGet extend itself and distribute NuGet command-line extensions by using NuGet packages?

Luckily for you, there is a package for that! It’s called NuGet.InstallCommandLineExtension and is available at NuGet.org. Figure 9-2 shows NuGet.InstallCommandLineExtension in action.

Installing the NuGet.InstallCommandLineExtension package performs two actions: it will install a first NuGet command-line extension, called AddConsoleExtension, and it will install a custom PowerShell cmdlet into the Package Manager Console, called Install-CommandLineExtension. This gives you two different ways of extending the NuGet command line in a way you already know and love—by using NuGet itself.

Now let’s install the NuGet.Analyze extension containing the nuget analyze command. From the Visual Studio Package Manager Console, we can execute the following command:

Install-CommandLineExtension NuGet.Analyze

Once our NuGet command-line extension is installed, we are able to run it. We even get help information, by running the nuget help analyze command. Figure 9-3 shows the help command in action.

Go on and create your own extensions! Maybe an extension to clean the NuGet cache would be nice. Or one that copies NuGet packages from one feed to another. Or one that downloads all packages from a given feed to create a backup.

Creating Custom Package Analysis Rules

When creating NuGet packages by using the NuGet command line, you may have encountered warnings. For example, when you are working with a generated .nuspec file and don’t make any changes, chances are you might be seeing a lot of these warnings. Figure 9-4 shows what we mean by them.

What is interesting is that these warnings can be extended. For example, imagine you are building NuGet packages inside your team. What would happen if, say, a certificate file would be shipped inside a NuGet package? Perhaps you require a .cer or .pfx file to be present in your local working folder, but if this file happens to get packed into a NuGet package, that may turn into a disaster: all team members would suddenly have this certificate. Or even worse, the entire world would be able to use it when publishing it to NuGet.org. Let’s build a custom package analysis rule that prevents us from adding certain file extensions to our packages.

Just as when creating custom NuGet commands, you have to create a new class library project targeting the .NET 4.0 Framework, reference the System.ComponentModel.Composition namespace in which MEF resides, install NuGet.CommandLine into the project, and add an assembly reference to the nuget.exe file it installed.

Once all that is done, we can start creating our custom validation rule. First of all, you’ll have to implement the IPackageRule interface, which is located in the nuget.exe file that is referenced. Also add ExportAttribute to the class, which will hold the custom package analysis rule, so nuget.exe will be able to pick it up and run it when creating a NuGet package.

[Export(typeof(IPackageRule))]
public sealed class CertificateRule : IPackageRule
{
    public IEnumerable<PackageIssue> Validate(IPackage package)
    {
        // code will go here
    }
}

The actual package validation logic will go in the Validate method. This method will be called by nuget.exe when creating a NuGet package and receives all package data: metadata such as package ID and version, as well as the files included in the package, their names, and data. If you don’t want .cer or .pfx files included in a NuGet package, simply scan for any file that matches these extensions and yield a PackageIssue instance, which can return either a warning or an error. The full code for the CertificateRule class that holds our custom validation can be seen in Listing 9-5.

Listing 9-5.  A Custom Package Analysis Rule for NuGet That Scans the Package for Forbidden File Extensions

[Export(typeof(IPackageRule))]
public sealed class CertificateRule : IPackageRule
{
    private readonly string[] _forbiddenExtensions = { ".cer", ".pfx" };

    public IEnumerable<PackageIssue> Validate(IPackage package)
    {
        // Loop through all files and match them with _forbiddenExtensions
        foreach (var packageFile in package.GetFiles())
        {
            if (_forbiddenExtensions.Any(
                extension => extension == Path.GetExtension(                                                packageFile.Path).ToLowerInvariant()))
            {
                yield return new PackageIssue(
                    "Forbidden file extension found",
                    string.Format("The file {0} is of a forbidden file extension and may not be
                                   included in a NuGet package.", packageFile.Path),
                    "Remove it from the package folder.",
                    PackageIssueLevel.Error);
            }
        }
    }
}

If you compile the project and copy its assemblies into the %LocalAppData%NuGetCommands folder on your system, the NuGet command line will pick up the package validation rule. This folder can hold NuGet command-line extensions as well as custom package analysis rules. If you now try to create a NuGet package that holds a .cer or .pfx file, a package issue will be shown, as can be seen in Figure 9-5.

Creating and Distributing a Package Manager Console Extension

Let’s start the creation of a NuGet Package Manager Console extension by defining what we want to achieve. Visual Studio exposes a lot of functionality hidden in menus and keyboard shortcuts. Some developers are very keyboard-oriented in their day-to-day jobs, and to support them, we want to provide two PowerShell cmdlets for use in the Package Manager Console.

The first cmdlet, Remove-Usings, will enable any developers who have installed the extension we’re creating to sort and remove using directives in their source code for the entire project. The second cmdlet, Find-Symbol, will enable those developers to find symbols, such as a class or interface, using the Package Manager Console. Don’t worry: we’ll cover the source code for these two commands later on. Let’s first see how they work and how we can create a so-called tools package.

Figure 9-6 shows you the NuGet Package Manager Console, where the cmdlet Find-Symbol DeckController has been invoked. This cmdlet is not available out of the box but has been defined in a PowerShell module added to the Package Manager Console.

<?xml version="1.0"?>
<package>
  <metadata>
    <id>VsCommands</id>
    <version>1.0.0</version>
    <authors>Maarten Balliauw</authors>
    <owners>Maarten Balliauw</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Adds cmd-lets NuGet PowerShell Console.</description>
    <releaseNotes>Adds cmd-lets to the NuGet PowerShell Console.</releaseNotes>
    <copyright>Copyright Maarten Balliauw 2011</copyright>
    <tags>nuget powershell pronuget apress</tags>
  </metadata>
</package>

param($installPath, $toolsPath, $package)
Import-Module (Join-Path $toolsPath VsCommands.psm1)

function Remove-Usings {
    $dte.ExecuteCommand("ProjectandSolutionContextMenus.Project.RemoveandSortUsings")
}

function Find-Symbol {
    param(
        [parameter(ValueFromPipelineByPropertyName = $true)]
        [string]$Name
    )

    $dte.ExecuteCommand("Edit.FindSymbol", $Name)
}

function Remove-Usings {
    $dte.ExecuteCommand("ProjectandSolutionContextMenus.Project.RemoveandSortUsings")
}

function Find-Symbol {
    param(
        [parameter(ValueFromPipelineByPropertyName = $true)]
        [string]$Name
    )

    $dte.ExecuteCommand("Edit.FindSymbol", $Name)
}

Export-ModuleMember -Function *

Adding Tab Expansions to Package Manager Console Extensions

The VsCommand commands we created in the previous section were simple to create and use. There was no need for a lot of documentation or samples because both cmdlets were straightforward. Things are different if you create more-complex cmdlets.

One of the things you may have noticed when using the NuGet Package Manager Console is the support for tab expansions, an idea similar to the IntelliSense you know and love when editing code in Visual Studio. Figure 9-8 shows you an example of tab expansion. When working with the Get-Package cmdlet, every option available features a menu of possible values when pressing the Tab key.

For this section, find the source code related to this book on the Apress website at www.apress.com/9781430260011 or in our GitHub repository at www.github.com/myget/pronuget. We won’t dive into creating a Package Manager Console extension from scratch again; instead, we’ll have a quick look at the TfsCommands.psm1 PowerShell module, which you can download from the Apress web site. If you just want to test the TfsCommands commands, find them on the www.myget.org/F/pronuget NuGet feed for this book.

The TfsCommands extension features several PowerShell cmdlets that can be used when your project is added to a Team Foundation Server (TFS)server and a connection to that server has been established in Visual Studio. It features the following cmdlets:

• Get-CurrentTfsCollectionUri: Returns the URL for the TFS server to which you are currently connected
• Get-CurrentTfsProjectName: Returns the TFS project name to which you are currently connected
• Get-TfsProjectNames: Returns all projects for the TFS server to which you are currently connected
• Get-WorkItemTypes: Returns the work item types available in the TFS project to which you are currently connected
• Add-WorkItem: Creates a TFS work item in a specified project

The Add-WorkItem cmdlet is hard to use in the Package Manager Console. It requires you to specify a number of parameters (-Title, -Description, -WorkItemType, -TfsCollectionUri, and -Project). Wouldn’t it be great to have tab expansions for these cmdlets? Figure 9-9 shows you what we are aiming for.

The Add-WorkItem cmdlet has been implemented just as we’ve implemented the cmdlets in the previous section. To achieve tab expansions, we’ve added some code at the bottom of the TfsCommands.psm1 file. Using the Register-TabExpansion PowerShell cmdlet, which is provided by the NuGet Package Manager Console, we can instruct the Package Manager Console to enable tab expansions for a given cmdlet. Listing 9-8 shows you how to do this.

Tab expansions can be static, based on an array of possible values, or dynamic, querying for data through other PowerShell cmdlets or remote servers. In Listing 9-9, note the Title and Description tab expansions will simply return a list of strings containing some sample data of what the user may pass into these cmdlet parameters. The WorkItemType, TfsCollectionUri, and Project tab expansions are slightly more complicated: these call into another PowerShell cmdlet to retrieve their data.

Listing 9-9.  The Tab Expansion Registration

Register-TabExpansion 'Add-WorkItem' @{
    'Title' = {
        "Implement feature X",
        "Verify bug Y"
    }
    'Description' = {
        "Please implement feature X",
        "Bug Y has not been verified yet. Please take care of it."
    }
    'WorkItemType' = { Get-WorkItemTypes | Select -ExpandProperty Name }
    'TfsCollectionUri' = { Get-CurrentTfsCollectionUri }
    'Project' = { Get-TfsProjectNames | Select -ExpandProperty Name }
}

Creating a Custom Content Viewer

The main purpose of the NuGet Package Explorer content viewer plug-in is to attach custom visualizers to certain file types. By default, NuGet Package Explorer does not handle every possible file extension, except for the most common NuGet package contents. Whenever a user triggers the View Content command on a certain file (by double-clicking it, for instance), NuGet Package Explorer scans the application for a command that can handle the requested file extension.

After installing the NuGetPackageExplorer.Types package, described in the previous section, the installer has injected your project with a class named MyCustomContentViewer, shown in Listing 9-10. This class is a sample content viewer that you can adjust to suit your needs. For starters, you might want to pick a proper file extension to tell the tool what kind of files your plug-in will target. Notice that your plug-in can register itself for more than one extension at the same time. The integer parameter of the PackageContentViewerMetadata attribute sets your plug-in’s priority. The lower the value, the higher its priority.

Listing 9-10.  Default Sample of a Custom Content Viewer for NuGet Package Explorer

// TODO: replace '.extension' with your custom extension
[PackageContentViewerMetadata(0, ".extension", ".anotherextension")]
internal class MyCustomContentViewer : IPackageContentViewer
{
    public object GetView(string extension, Stream stream)
    {
        throw new NotImplementedException();
    }
}

The content viewer has only one significant method—GetView. It returns an object, but please bear in mind that NuGet Package Explorer is a WPF application and will put the result of this method into a ContentPresenter control’s Content property. Therefore, you can return either a simple string or any deriving object of the Visual class. The GetView method has access to information regarding the file it will need to handle: its file extension and its content stream.

A simple sample is shown in Listing 9-11. This is an NPE content viewer plug-in that handles .txt files and simply returns their content stream as a string.

Listing 9-11.  A Simple .txt file Content Viewer Example

[PackageContentViewerMetadata(0, ".txt")]
internal class TextFileContentViewer : IPackageContentViewer
{
    public object GetView(string extension, Stream stream)
    {
        StreamReader reader = new StreamReader(stream);
        return reader.ReadToEnd();
    }
}

The ILSpy plug-in for NuGet Package Explorer goes a little further and works with a modal WPF dialog box showing a custom ConfigurationControl, as shown in Listing 9-12. Because it targets files with a .dll or .exe extension and has a priority of 0, it will be used as the default content viewer for assembly files inside a NuGet package.

Listing 9-12.  A Content Viewer Using a Custom WPF Control in a Modal Dialog Box

[PackageContentViewerMetadata(0, ".dll", ".exe")]
internal class ILSpyPackageContentViewer : IPackageContentViewer
{
    private ConfigurationControl configControl;
    private Window dialog;

    public object GetView(string extension, Stream stream)
    {
        try
        {
            configControl = new ConfigurationControl(extension, stream);
            dialog = new Window();
            dialog.Content = configControl;
            dialog.Topmost = true;
            dialog.Width = 300;
            dialog.Height = 120;
            dialog.ResizeMode = ResizeMode.NoResize;
            dialog.WindowStartupLocation = WindowStartupLocation.CenterOwner;
            dialog.ShowInTaskbar = false;
            dialog.ShowDialog();

            return configControl.Assembly.FullName;
        }
        catch (Exception exception)
        {
            return exception.ToString();
        }
    }
}

If you have the ILSpy plug-in installed in NuGet Package Explorer, double-clicking an assembly inside a NuGet package will prompt the user for the path to ILSpy, as shown in Figure 9-11.

After choosing the correct path to your ILSpy executable and clicking the OK button, you’ll see ILSpy opening up the requested file, as shown in Figure 9-12.

Creating a Custom Package Validation Rule

You’ll notice that after installing the NuGetPackageExplorer.Types package, two more classes were injected into your project, in addition to a custom content viewer. One of them, the MyCustomPackageRule class, is implementing IPackageRule, which allows you to add your own validation logic for NuGet packages—for example, to enforce that all packages produced in your company have correct copyright information and a proper logo in the manifest. Do not forget to export these package rules by marking them with the Export attribute, as shown in Listing 9-13.

Listing 9-13.  Default Sample of a Custom Package Rule for NuGet Package Explorer

[Export(typeof(IPackageRule))]
internal class MyCustomPackageRule : IPackageRule
{
    public IEnumerable<PackageIssue> Validate(IPackage package)
    {
        throw new NotImplementedException();
    }
}

Whenever a user triggers the Analyze Package command in NuGet Package Explorer for the first time, the application will import all available IPackageRule implementations and call their Validate method for the currently opened package.

A sample of a package validation rule can be found in Listing 9-14. The SamplePackageRule yields one PackageIssue of the PackageIssueLevel.Error. A title, description, and a possible solution are added to the PackageIssue object to provide the user running this validation rule with enough information to comply with the rule defined.

Listing 9-14.  A Sample Package Validation Rule

[Export(typeof(IPackageRule))]
internal class SamplePackageRule : IPackageRule
{
    public IEnumerable<PackageIssue> Validate(IPackage package, string packageFileName)
    {
        yield return new PackageIssue(
            PackageIssueLevel.Error, "Sample error",
            "The sample error is just being used for sample purposes.",
            "There's no solution to this.");
    }
}

The PackageIssue(s) being returned will be shown in the package analysis pane of NPE, as shown in Figure 9-13.

Creating a Custom Package Command

The third piece of code that has been added to your project after installing the NuGetPackageExplorer.Types package is a sample custom package command. A custom package command has access to the opened package and appears as a menu item in the Tools menu. A custom package command implements the IPackageCommand interface and exposes some metadata through the PackageCommandMetadata attribute, as shown in Listing 9-15.

Listing 9-15.  Default Sample of a Custom Package Command for NuGet Package Explorer

[PackageCommandMetadata("My custom command")]
internal class MyCustomPackageCommand : IPackageCommand
{
    public void Execute(IPackage package)
    {
        throw new NotImplementedException();
    }
}

By implementing your own custom package commands, you can plug your own useful commands into NuGet Package Explorer and reuse them for any NuGet package—for instance, a command that easily clones a package and saves a copy on disk. Or how about adding a menu item under the Tools menu that can open the current package in a different tool, such as JetBrains’ decompiler, dotPeek? Figure 9-14 shows what this menu entry could look like. The code for this menu entry would be a call to Process.Start with the correct parameters.

NuGet Package Explorer offers you a lot of extensibility in three different domains: file content viewers, package validation rules, and custom package commands. Each of them are useful on their own, and combined, they can possibly be a huge asset in your NuGet tool belt. Here are some ideas for extensions to NuGet Package Explorer we would like to see:

• A content viewer that shows decompiled assembly sources straight within NuGet Package Explorer.
• A custom validation rule that checks NuGet.org to see whether the package version you are creating already exists. (I hate it when I have to repackage because of this.)
• Maybe a tool menu that finds the GitHub project for a package and loads the readme file on demand?

There is more we can think of, and we are pretty sure that you might come up with some great plug-ins as well.