Rob Reynolds - The Fervent Coder : NuGet

this.Log– Source, NuGet Package & Performance

Rob Reynolds — Thu, 20 Dec 2012 05:24:08 GMT

Recently I mentioned this.Log. Given the amount of folks that were interested in this.Log, I decided to pull this source out and make a NuGet package (well, several packages).

Source

The source is now located at https://github.com/ferventcoder/this.log. Please feel free to send pull requests (with tests of course). When you clone it, if you open visual studio prior to running build.bat, you will notice build errors. Don’t send me a pull request fixing this, I want it to work the way it does now. Use build.bat appropriately.

To try to cut down on the version number being listed everywhere, I created a SharedAssembly.cs (and a SharedAssembly.vb for the VB.NET samples). That helped, but it didn’t solve the problem where it was in the nuspecs as dependencies. So I took it a step further and created a file named VERSION. When you run the build, it updates all the files that contain version information. Having one place to handle the version is nice.

NuGet

When moving this.Log to a NuGet package (or in this case 9 NuGet packages), I was able to play with some features of NuGet I had not previously, symbol servers and packing a csproj. With packing a csproj, I was able to quickly (well mostly) set up the build to package up every project with NuGet packages.

All packages can be found by searching for this.log on NuGet.org.

this.Log Logging Extension – does nothing by itself except brings the LogExtensions and this.Log.dll. You need to install one of the plugins to get this.
this.Log Logging Extension (log4net Plugin) – the log4net plugin to this.Log
this.Log Logging Extension (log4net Plugin) SAMPLE – this is a sample showing how this.Log-log4net works in action. Add it to a console application.
this.Log Logging Extension (log4net Plugin) SAMPLE for VB.NET – same as the previous sample, except for VB.NET
this.Log Logging Extension (NLog Plugin) – the NLog plugin to this.Log
this.Log Logging Extension (NLog Plugin) SAMPLE – this is a sample showing how this.Log-NLog works in action. Add it to a console application.
this.Log Logging Extension (NLog Plugin) SAMPLE for VB.NET – same as the previous sample, except for VB.NET
this.Log Logging Extension (Rhino Mocks Plugin) – MockLogger for Rhino Mocks
this.Log Logging Extension (Moq Plugin) – MockLogger for Moq

NOTE: If you’ve installed any of these prior to this post, you will want to uninstall and reinstall them (there was an particular issue with the version on the Rhino Mocks version). I’ve fixed and updated quite a bit on them from version 0.0.1.0 to 0.0.2.0.

Performance

Performance testing with log4net showed this only has an overhead of 42 ticks tested over 100,000 iterations. That’s a pretty good start given that it has a reflection hit on every call.

Introducing this.Log

Rob Reynolds — Sat, 15 Dec 2012 15:29:09 GMT

One of my favorite creations over the past year has been this.Log(). It works everywhere including static methods and in razor views. Everything about how to create it and set it up is in this gist.

How it looks

public class SomeClass {
 
  public void SomeMethod() {
    this.Log().Info(() => "Here is a log message with params which can be in Razor Views as well: '{0}'".FormatWith(typeof(SomeClass).Name));

    this.Log().Debug("I don't have to be delayed execution or have parameters either");
  }

  public static void StaticMethod() {
    "SomeClass".Log().Error("This is crazy, right?!");
  }
 
}

Why It’s Awesome

It does no logging if you don’t have a logging engine set up.
It works everywhere in your code base (where you can write C#). This means in your razor views as well!
It uses deferred execution, which means you don’t have to mock it to use it with testing (your tests won’t fail on logging lines).
You can mock it easily and use that as a means of testing.
You have no references to your actual logging engine anywhere in your codebase, so swapping it out (or upgrading) becomes a localized event to one class where you provide the adapter.

Some Internals

This uses the awesome static logging gateway that JP Boodhoo showed me a long time ago at a developer bootcamp, except it takes the concept further. One thing that always bothered me about the static logging gateway is that it would construct an object EVERY time you called the logger if you were using anything but log4net or NLog. Internally it likely continued to reuse the same object, but at the codebase level it appeared as that was not so.

/// <summary>
/// Logger type initialization
/// </summary>
public static class Log
{
    private static Type _logType = typeof(NullLog);
    private static ILog _logger;
 
    /// <summary>
    /// Sets up logging to be with a certain type
    /// </summary>
    /// <typeparam name="T">The type of ILog for the application to use</typeparam>
    public static void InitializeWith<T>() where T : ILog, new()
    {
        _logType = typeof(T);
    }
 
    /// <summary>
    /// Sets up logging to be with a certain instance. The other method is preferred.
    /// </summary>
    /// <param name="loggerType">Type of the logger.</param>
    /// <remarks>This is mostly geared towards testing</remarks>
    public static void InitializeWith(ILog loggerType)
    {
        _logType = loggerType.GetType();
        _logger = loggerType;
    }
 
    /// <summary>
    /// Initializes a new instance of a logger for an object.
    /// This should be done only once per object name.
    /// </summary>
    /// <param name="objectName">Name of the object.</param>
    /// <returns>ILog instance for an object if log type has been intialized; otherwise null</returns>
    public static ILog GetLoggerFor(string objectName)
    {
        var logger = _logger;
 
        if (_logger == null)
        {
            logger = Activator.CreateInstance(_logType) as ILog;
            if (logger != null)
            {
                logger.InitializeFor(objectName);
            }
        }
 
        return logger;
    }
}

You see how when it calls InitializeFor, that’s when you get something like the following in the actual implemented method:

_logger = LogManager.GetLogger(loggerName);

So we take the idea a step further by implementing the following in the root namespace of our project:

/// <summary>
/// Extensions to help make logging awesome
/// </summary>
public static class LogExtensions
{
    /// <summary>
    /// Concurrent dictionary that ensures only one instance of a logger for a type.
    /// </summary>
    private static readonly Lazy<ConcurrentDictionary<string,ILog>> _dictionary = new Lazy<ConcurrentDictionary<string, ILog>>(()=>new ConcurrentDictionary<string, ILog>());
 
    /// <summary>
    /// Gets the logger for <see cref="T"/>.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="type">The type to get the logger for.</param>
    /// <returns>Instance of a logger for the object.</returns>
    public static ILog Log<T>(this T type)
    {
        string objectName = typeof(T).FullName;
        return Log(objectName);
   }
 
    /// <summary>
    /// Gets the logger for the specified object name.
    /// </summary>
    /// <param name="objectName">Either use the fully qualified object name or the short. If used with Log&lt;T&gt;() you must use the fully qualified object name"/></param>
    /// <returns>Instance of a logger for the object.</returns>
    public static ILog Log(this string objectName)
    {
        return _dictionary.Value.GetOrAdd(objectName, Infrastructure.Logging.Log.GetLoggerFor);
    }
}

You can see I’m using a concurrent dictionary which really speeds up the operation of going and getting a logger. I get the initial performance hit the first time I add the object, but from there it’s really fast. I do take a hit with a reflection call every time, but this is acceptable for me since I’ve been doing that with most logging engines for awhile.

Conclusion

If you are interested in the details, see this gist.

Extensions are awesome if used sparingly. Is this.Log perfect? Probably not, but it does have a lot of benefits in use. Feel free to take my work and make it better. Find a way to get me away from the reflection call every time. I’ve been using it for almost a year now and have improved it a little here and there.

If there is enough interest, I can create a NuGet package with this as well.

Chocolatey - Guidance on Packaging Apps with Both an Install and Executable/Zip Option

Rob Reynolds — Sat, 25 Feb 2012 17:35:00 GMT

One of the thoughts I've been considering recently with chocolatey is consistency with packages and naming conventions as chocolatey continues to grow. It's fine to name packages by the app/tool name, that's both intuitive and expected. What I am more interested in is when an application has multiple installation options (ie. an MSI and a ZIP). It can become confusing for people to install these when they don't know what they are getting if they call a package that has both. If you start with one that has a .zip and later they release an MSI (nodejs anyone?), what do you call the package that installs the MSI? Do you keep around the executable? Do you rename the original package in response to the other option? Is there a third option?

One Option

If there is only one option available, you are fine to make the package name the same as the application/tool. This makes it intuitive and reduces confusion.

Multiple Options

To start putting together guidance on this and alleviate confusion, I see that we would move forward in these cases with three packages. One with no suffix, one with ".app" suffix, and one with ".tool" suffix. This brings in chocolatey's idea of applications versus tools ( https://github.com/chocolatey/chocolatey/wiki/ChocolateyFAQs - apps are installed on the system, tools are not).

If you would take a quick look at Instant EyeDropper ( http://chocolatey.org/packages?q=instanteyedropper ), you will notice there are three packages here.

InstantEyeDropper is what will ultimately be a virtual package
InstantEyeDropper.app is the package name for a package that uses a native installer (i.e. MSI, exe)
InstantEyeDropper.tool is the package name for a package that has an executable / downloads & unpacks an archive / etc

InstantEyeDropper right now is taking a dependency on InstantEyeDropper.app (which makes it a meta package). When virtual packages (see Virtual Packages below) are ready, that dependency will be removed and the chocolateyinstall.ps1 file will look something like the following (this is not definitive of what it will look like though):

Install-VirtualPackage '7zip.tool' '7zip.app'

You will notice I put the ".tool" ahead of ".app". In the end, I think the behavior of a virtual package should default to a command line version. Why? There are folks that do not have administrative access to their machines. Chocolatey is really nice for them because they can install and use chocolatey without ever needing to assert administrative privileges. Marcel Hoyer (https://twitter.com/pixelplastic) first proposed the idea of being able to use chocolatey without administrative privileges. Him and I took pains to make chocolatey work for these scenarios. This did complicate chocolatey a little bit for the package maker, but in the end I think it is a really good thing. As a person inspecting a package to decide whether to install or not, they can see every point that the package maker mentioned they needed administrative privileges.

That said, the default will be the one on the leftmost side. You are beholden to the community in justifying why you didn't put the command line version first if you decide not to in the virtual package. But chocolatey won't constrain you on that because you may have a really good reason.

App Now has Multiple Options

When an application/tool moves to where it has multiple options, like an installer it didn't used to have, that's when it is time to break the package out to a virtual (meta for now until virtual is available) and create the other two packages with the correct suffixes as outlined in the guidance above.

Virtual Packages

For those confused about the idea of a virtual package, it allows folks to say I need to take a dependency on a PDFReader. PDFReader becomes a virtual package that does nothing other than point to all of the different pdf readers available. When someone installs the package that has a dependency on PDFReader, chocolatey looks at the virtual options and sees you have adobereader installed (one of the options in the list). So it moves on because you have met the virtual package requirements. If you have foxitreader installed, it moves on. Otherwise it picks the first item in the virtual tree and installs it as the default. More information? https://github.com/chocolatey/chocolatey/issues/7

Virtual Packages vs Meta Packages

A meta package is one that points to other packages. If you think of a package that does nothing more than take on dependencies to other packages, that is a meta package. A virtual package is like a meta package, except it has the concept of optional dependencies.

Ending Thoughts

This seems to be on the surface the best way to provide an intuitive user experience. There may be some things we learn along the way and adjust this as we go. If you are a package owner and you have packages that have both options, you may want to start getting them into this format. I myself have some work to do in this aspect.

Thoughts?

Original Discussion: http://groups.google.com/group/chocolatey/browse_thread/thread/a1d208b022dfc30f

Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version

Rob Reynolds — Wed, 25 Jan 2012 16:29:19 GMT

As software creators we don't get to decide what version of our tools / libraries that people use. If we try to force them, our users will go somewhere else.

Update: What Type of Software This Applies To

This post talks of tools, applications and libraries. Things that end up in the users hands. This does not apply to SaaS or websites. These do not end up in the hands of the users in the same sense.

For those of you who immediately think of Chrome or Firefox, which are applications that end up in the users hands, those apply to this post as well. They have nearly perfected a silent upgrade experience, but if they ever mess up that experience, users can choose to use something else. And I believe there is a way to opt out as well (not easily achieved but possible).

Software Release Management

I write software. Much of it is open source. I have multiple versions of my products out there. Even with newer versions available that fix bugs and bring about new features, I still find people using older versions. Even though I have a better newer version that fixes some of the bugs they are dealing with, they are still using an older version. Think about that for a second. There must be a good reason right? Let’s state this in an official sense.

As a software creator you release software. You put a release out there and people use that release. You delineate different releases by a concept of versioning. People use a particular version of your release. You release newer versions of your software that has fixes and enhancements. You hope users upgrade to the latest release when it is available.

I’ve stated five facts and finished with a hope. If you can accept those as facts, we can move on. If we can’t, then you might want to stop reading now because we are never going to agree. If you are a developer like me, you really want people to always use the latest version of your software, so you might be able to accept the last statement as a fact for you. I really want people to always use the latest release of my software as I have went through the trouble of testing it and making it better.

Now let me change some terms for you. Software release management is really a fancy way of saying package management. A software release could be better termed a package. So to restate, as a software creator, you release packages. You put a package out there and people use that package. You delineate different packages by a concept of versioning. People use a particular version of your package. You release newer versions of your package that has fixes and enhancements. You hope users upgrade to the latest package when it is available.

The Hope Versus The Force

I say “hope they upgrade” because you really can’t control that aspect. You can try. You can delete the older versions. You can refuse to have older versions available. You can tell users that they should and need to upgrade. But you put it out there once and it is now out there forever. People will find a way to get to the particular version they need. Or they will go elsewhere. Users speak with their feet.

I find attempting to force a user to do something is both an exercise in futility and a great way to guarantee that you have less users overall.

So people must want to use a particular version of a product. Let’s examine this a little more. Why on earth would someone use an older version of a product when a newer, better, less buggier version is available?

Why Do Users Use Older Versions?

Users use older versions of our packages and they have great fundamental reasons for doing so:

It reduces their risk.
It guarantees that users of their library (that has a dependency on your library) have a good experience.
It guarantees that the product that they have tested is the same product that gets into the hands of consumers.
It guarantee their product builds successfully and the same way each time.

In fixing a product and making it better and less buggier, you may actually be breaking someone’s ability to use a newer version. And you have no guarantee to the user that this version doesn’t have flaws of it’s own. Right? Otherwise there would only be one version that ever had fixes in it. We wouldn’t need to release newer versions with fixes, only enhancements. But we don’t. We fix things we thought worked and we fix things we tested but missed some crazy edge case. This is why we go down this path of release management. This is software development.

So people get a certain version and they use it. Users upgrade to the latest version of software when they are ready, not when the software creator is ready. People depend on certain versions or on a range of versions. In reality I can't force someone to use the latest version. If I try, they will find the version they need through the powers of the internet or find another way. Accepting that, I can give them a way to see it and help them fall into the pit of success.

From the User Perspective

Shifting to the perspective of the user, I might use your library in my own software. Being able to build my product, even if it means it is using an older version of your package that has bugs, is worlds more important to me and my users. We'll get to your latest version when we can test that it doesn't break our product. But don't try to force me to upgrade to your latest version or I will find another way. I'm not saying that with your package but in all packages the newer version may be buggier than the current buggy version we are using. We don't know and you can’t guarantee that it doesn’t, even with extensive testing. Testing doesn’t prove the absence of bugs, only the absence of errors that you know. I digress.

It’s an evil that we know versus and evil that we don’t. Or put another way, it's a buggy version we know versus a buggy version we don't.

If it’s a tool, we need to ensure that our usage of your product still meets our expectations. We need to test it even though you did and make sure it still works for our needs and scenarios. Where it doesn’t we need to decide if that means we can shift our expectations and upgrade. But we are not going to blindly upgrade and just use the latest version because the software creator believes that is best.

Can you cover the millions of dollars that we might lose by taking on a newer version of your product? If you can give me that guarantee, as a user I will gladly pass that risk on to you.

Final Thoughts

Whether you agree or not, as software creators we don't get to decide what version of our tools / libraries that people use. We just don’t have that luxury. If we try to our users will go somewhere else. So we make it easy for them to upgrade so they will want to. We make the upgrade experience painless so they will want to. We need to be good stewards.

Let’s Get Chocolatey! Kind of like apt-get for Windows

Rob Reynolds — Fri, 07 Oct 2011 12:32:28 GMT

“If only there was some way to quickly and silently install applications and tools on my windows machine.”

Chocolatey is kind of like an apt-get, but for Windows. It is a machine level package manager that is built on top of NuGet command line and the NuGet infrastructure. Jason Jarrett recently described it as the free/OSS windows app store. What that means for you is that you can install and update software (applications and tools) on your machine with a few keystrokes and chocolatey does the rest!

Just how easy is it to install an application? From the command line, PowerShell, or Package Manager Console in visual studio you can type something like:

cinst windirstat

and watch it download and silently install WinDirStat on your machine.

A picture is worth a thousand words in this case:

If you want to try a tool (something that doesn’t actually install on your machine), try baretail, nodejs, or ravendb.

Creating Packages is also very simple: https://github.com/chocolatey/chocolatey/wiki/CreatePackages

Below is all that is required to install WinDirStat on your machine.

Install-ChocolateyPackage 'windirstat' 'exe' '/S' 'http://windirstat.info/wds_current_setup.exe'

Include chocolatey in your development environment setup! https://github.com/chocolatey/chocolatey/wiki/DevelopmentEnvironmentSetup Check out a living example - https://github.com/davidalpert/nuserve#readme

FAQ

What can I do with chocolatey? Since it uses PowerShell, you can do nearly anything you can do with .NET. Install applications, download tools and put them on the path, set up contributors machines for hacking on your code, install powershell commands, etc. Your imagination is the limit!

What’s your best example of the power of chocolatey? One line Ruby DevKit install. Seriously. http://groups.google.com/group/rubyinstaller/browse_thread/thread/8245c53f990d1ea6

I’m convinced! How do I install chocolatey? We try to make that simple as well. Open powershell, make sure execution policy is unrestricted (Set-ExecutionPolicy Unrestricted), and paste

iex ((new-object net.webclient).DownloadString("http://bit.ly/psChocInstall"))

I have included tools (executables) in my nuget.org packages, like Statlight and Fubu. Can I use chocolatey to “install” them? Yes, just call install like normal, it will check chocolatey.org first and then nuget.org. If it finds an executable in the package, it will automatically put it on the path.

How is chocolatey different from other windows machine package managers? It has PowerShell instructions for how to download native installers from the distribution source and install applications on your machine. It uses PowerShell so you can give it any instruction you want for install and configuration. It automatically makes batch command file links for executables you have included in your package or have downloaded to the package directory with the PowerShell script.

Is chocolatey awesome? I’m biased, but YES!

Is chocolatey version 1? Not yet, we have a few things going into the roadmap and enhancements being logged: https://github.com/chocolatey/chocolatey/issues

I’m not convinced, where do I find more information? I’ve listed quite a few resources below. I am likely missing some.

References

http://chocolatey.org/

https://github.com/chocolatey/chocolatey/wiki

http://groups.google.com/group/chocolatey

http://twitter.com/chocolateynuget

Videos

Chocolatey In Action (11 apps/tools in less than 7 minutes!): http://www.youtube.com/watch?v=N-hWOUL8roU

Create a Chocolatey Package: http://www.youtube.com/watch?v=Wt_unjS_SUo

Blog Posts

This dates all the way back to March 2011. Chocolatey has been actively worked on for awhile…

http://nuget.codeplex.com/discussions/251435

http://nuget.codeplex.com/discussions/257341

http://chrisortman.wordpress.com/2011/04/01/getting-started-with-chocolatey/

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/chocolatey-apt-get-for-windows

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/getting-chocolatey-to-work-when

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/chocolatey-gui

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/making-a-chocolatey-package

http://www.counity.at/blog/archives/253

http://www.xavierdecoster.com/post/2011/09/30/An-overview-of-the-NuGet-ecosystem.aspx

http://blog.codiceplastico.com/melkio/index.php/2011/10/06/chocolatey-un-package-manager-per-windows/

http://elegantcode.com/2011/10/05/chocolatey-the-free-and-open-source-windows-app-store

Extend NuGet Command Line

Rob Reynolds — Fri, 15 Jul 2011 08:00:00 GMT

Yesterday I started a discussion about adding a new command to nuget.exe. It ended in creating an extension to the command line that behaves in the same way without having to dive into the nuget code base or add more complexity to it.

I haven’t seen any blog posts or documentation surrounding this new concept (new in nuget 1.4) of extending the command line except for Matt Hamilton’s posts on using NuGet for plug-ins and NuGet with MEF (which are not quite this concept).

Here is my experience. I found looking at the commands in nuget.exe (NuGet.Commands) to make it easy to create my own command and extend NuGet. Some of this information may not be exactly what you should do, but it worked for me.

The Code

Create a new Visual Studio Solution and add a Class Library (full .NET 4.0 framework).
Add A NuGet Reference to Nuget.CommandLine.
Now manually add a reference to nuget.exe. Yes, you can add references to .NET executables.
Adding a reference to nuget.exe gives you access to Command and the CommandAttribute. These are what I see as necessary to extending NuGet.
Add a reference to System.ComponentModel.Composition (MEF).
Now you provide a class and resource file per command.

The resource file contains the command descriptions:

The class is attributed with CommandAttribute and inherits from Command.

[Command(typeof (CopyResources), "copy", "Description", MinArgs = 1, MaxArgs = 5, UsageSummaryResourceName = "UsageSummary",UsageDescriptionResourceName = "UsageDescription")]
public class Copy : Command {}

The Command Attribute asks for a few things:

typeof (CopyResources) – ResourceClass - What is the resx file that the command will draw its help information from?
“copy” – CommandName - what is the name of the command?
“Description” – Description - resource name in the resource file that gives the description on the command line.
MinArgs=1 – Minimum Arguments - what are the minimum number of arguments that can be passed to this command and satisfy its needs?
MaxArgs = 5 – Maximum Arguments - what are the maximum number of arguments that can be passed to this command?
UsageSummaryResourceName = “UsageSummary” – UsageSummary - a very short amount of information that explains the usage of the command.
UsageDescription = “Usage Description” – UsageDescription - more detailed information about how to use the command.

Here is what the command looks like when run with help. Notice where from the CopyResources.resx these items match up to the screen.

Now that we have the command attribute finished, let’s work on the command itself.

private readonly IPackageRepositoryFactory _repositoryFactory;
private readonly IPackageSourceProvider _sourceProvider;

[ImportingConstructor]
public Copy(IPackageRepositoryFactory repositoryFactory, IPackageSourceProvider sourceProvider)
{
    _repositoryFactory = repositoryFactory;
    _sourceProvider = sourceProvider;
}

[Option(typeof (CopyResources), "SourceDescription", AltName = "src")]
public string Source { get; set; }

[Option(typeof (CopyResources), "DestinationDescription", AltName = "dest")]
public string Destination { get; set; }

[Option(typeof (CopyResources), "VersionDescription")]
public string Version { get; set; }

[Option(typeof (CopyResources), "ApiKeyDescription")]
public string ApiKey { get; set; }

public override void ExecuteCommand()
{
    string packageId = base.Arguments[0];

    Console.WriteLine("Copying {0} from {1} to {2}.", string.IsNullOrEmpty(Version) ? packageId : packageId + " " + Version,
                      string.IsNullOrEmpty(Source) ? "any source" : Source, Destination);

    //do work son
 
}

Important things to note:

[ImportingConstructor] is the constructor that will be called. Notice I am having it get passed an IPackageRepositoryFactory and an IPackageSourceProvider. Most of my work is already done for me setting these up in the command line application.
Each command line option has [Option(typeof (CopyResources), "DestinationDescription", AltName = "dest")] .
Notice again with the options we specify the Resource File with an Option Description (“DestinationDescription”) and an optional short parameter for the Option (AltName). Notice how that translates into options on the help command.
I am overriding ExecuteCommand and pulling the packageId as the first item from base.Arguments.

From here I can do all the work necessary for my custom command.

Get NuGet to Recognize It

Nuget looks for custom commands in %LocalAppData%\NuGet\Commands. Drop your DLL in there and then call nuget. See if it registers your command. This will allow you to continue to tweak your package prior to releasing it in the wild.

Use AddExtension to Add New Commands

NuGet Extend (AddConsoleExtension) makes installing new commands to the console from NuGet packages super easy. You install it by typing the following:

NuGet.exe Install /ExcludeVersion /OutputDir %LocalAppData%\NuGet\Commands AddConsoleExtension

From then on, adding a new extension is as easy as

nuget.exe addExtension packageName

Distribute Your Extension as a NuGet Package And Enjoy Your New Custom Command

When I created my package, I noted in the nuspec description that Nuget Extend should be installed first. I also added the tag ConsoleExtension since that is what NuGet Extend used. All I package up is the DLL. The nuspec has ZERO dependencies specified (I do not include that I have a dependency on NuGet.CommandLine). I don’t need to include the nuget dependency since that will be resolved when the extension is run with nuget.exe.

Now that you have your custom command, enjoy life a little easier. And tell others about it.

NuGet Copy Extension is the extension I wrote that pulls packages from one source and pushes them to another. If you are a company that wants to house packages in a company feed and perhaps shut off the official feed for the rest of your developers, then this command may come in very handy.

Have Fun!

Iowa Code Camp Presentations

Rob Reynolds — Fri, 06 May 2011 05:04:21 GMT

Last weekend I went up to Iowa Code Camp in Cedar Rapids and had the opportunity to do two presentations, one on NuGet and one known as the Automation Tools Roundup. ICC is one of my favorite conferences every year. It is twice a year and I try to make it to at least one of them. The people that attend this conference really make it worth the money you spend in travel expenses. Definitely recommended.

Automation Tools Roundup

This is my favorite session to give because it requires crowd participation and it is never the same presentation twice. We just start going through automation tools of any sort that can help people be more productive through their use. The crowd picks which ones we talk about (for the most part). If there is time at the end we find ourselves trying to learn new tools.

We talked about several tools and as part of the session people from the audience are invited to come up and talk about a tool they like. Keith Dahlby came up and talked about Posh-Git which has an awesome interface for showing me my git status right on the prompt.

Other tools covered:

Chocolatey – I am going to talk about this tool soon.
Launchy
Console2
ChuckNorrisFramework: UppercuT & WarmuP were demoed, RoundhousE & DropkicK were mentioned
StExBar & grepWin
Notepad++
PSake was mentioned
SysInternals was mentioned, ZoomIt was shown

I believe we talked about a few more tools. If you were there and you remember, please hit the comments! Because this presentation is so dynamic, there are no slides.

FREE as in BEER!! Manage Your Packages w/NuGet

I enjoy showing people what is possible out there, even with some of the things that are not perfect. NuGet has a few kinks, but the community is helping and the team is committed to continually making the product better. This presentation is dedicated to showing you how to get started to building your own packages to hosting your own feed. We look at the GUI, the powershell console, the command line and the package explorer. The last 10 minutes of the presentation are dedicated to a new tool that can help make you hyper productive! This presentation is a lot of fun and seeing people really understand what NuGet can do for them is awesome!

Here are the slides: http://dl.dropbox.com/u/9391884/NuGet.ppsx