An improved NuGet experience

The idea is simple enough: I wanted to leverage some new extensibility hooks in VS2012 to show installed nuget packages right inside a packages.config file, like so:

And once you have the nodes in there, wouldn’t it be cool to be able to update and uninstall right from there?

And why not allow me to see key information about the package on the properties window?

Cool enough

Monetizing your creations

Now, after the extension was “done” (there’s a TON more that can be added to it! This is just the start), I realized I had put quite a few hours (more like days by now!) into it. So even if I do want my work to be open source so that eventually it can make it into NuGet’s core tooling, I could certainly use a few bucks to pay for the coffee and beer I put into it .

In the past, attempting to monetize small extensions was either a matter of placing a Donate button somewhere and hope that users would notice, or investing serious time in some sort of payment method (i.e. PayPal) and issuing product keys and implementing some activation mechanism.

I believe the Donate button doesn’t work because you have mainly two choices on how to expose it:

• At installation time
• Sporadic nagging dialogs afterwards

At installation time, I usually don’t know yet if what I’m installing is any good and if I will be willing to donate and how much. And everybody hates nagging dialogs. So there you have it: it won’t work.

And the alternative is simply not worth it most of the time (like for this cool extension I just built). I’m done with the fun part of building it, I just want to move on to the next fun thing. I’m hardly looking forward to building the payment and product activation stuff, much less maintain that up and running and the like. It’s just too much work.

This is the reason we (Clarius Consulting) built the DevStore: it allows me to quickly and effortlessly publish my extension for sale and be done in minutes. So let’s do that right now!

Publishing to the DevStore

So let’s go to http://devstore.com and click on the prominent Upload button:

I get to sign in with either a Google or Windows Live account, and after that quick permissions acceptance dialog, I get to fill in basic information about myself and accept the DevStore terms of service.

That will send an email to our inbox for verification purposes, after which we can log in with our credentials by clicking the Login button at the top. Of course this is only required the first time .

After we’re logged in, if we now click again the Upload button, we get to accept the Seller terms of service (which is different than for users, just like every other app store), and with that out of the way, we can just go ahead and upload our VSIX!

Here I have already chosen my extension file. Note that the file I’m uploading is the output of a regular VSIX project in Visual Studio. I haven’t modified the manifest in any way for now. Upon submitting the file, we get some data extracted from the manifest, which we can now tweak as needed:

For one thing, I know I want to change the Full Price value! So let’s click Edit. You can edit quite a bit of information about how you want to sell your extension, including full price (for first-time purchases), upgrade price (for v1 users when I come out with v2), what countries I want to sell it on, screenshots, and so on. I just happen to love Stella Artois beer which is about $2 on Amazon Fresh, so I’ll just round it up to $2.99 and you can buy me a beer for this extension .

After I’ve saved the information, I can click Submit/Publish, at which point it’s live on the site on the Recently Added section:

Buying from the DevStore

Now you can all go buy me a beer for this extension by either going to the website and downloading the VSIX from there, or, much more conveniently, do it from within Visual Studio!

All you need to do is first get the DevStore extension via the Extension Manager (remember, my extension only works on VS2012):

After a quick VS restart, you will get a new node in the extension manager window, the DevStore:

You cannot buy your own extensions, so here I’m buying it from another account I have, just to show you how it looks. The user will first have to register/sign in (right after clicking the Buy button), at which point they will get the Checkout dialog:

The next step takes you to your default browser, to the PayPal website. We had this step baked into Visual Studio at some point, but the overwhelming feedback from early beta testers was that they felt more confident and secure if we just took them to the regular browser window. In there, you get to log in and pay as usual:

Right after confirming the payment, I can go back to Visual Studio, and notice that the button changed from Buy to Download (as well as a new little world icon that tells me I own this extension in the cloud). And sure enough , after a quick download, I get the regular VSIX install dialog plus optional EULA if any, and I get to finish the install:

What about Open Source, Freedom and Love?

Well, I’m a complete fan of open source. I always ask myself “why NOT make this open source?”, rather than the opposite (and more common) question. I believe a very low-friction way to contribute with a few bucks with an open source project or developer is a great way to encourage more open source, independent developers and innovation.

The DevStore provides a great way to encourage developers to automate more of their daily programming activities, boosting productivity. I believe bite sized extensions in the range of $2-10 are a much better option that monster-sized tools that completely take over most of your IDE or pollute it unnecessarily with myriad (and totally unrelated) commands all over the place.

In order to prove the point that both open source and paid convenience delivery of binaries can actually be a commercially viable option, I’m also publishing the entire source for this extension in GitHub.

And that’s it! I just bought myself a beer with that demo above, so it’s time for me to go enjoy it. I hope you like the extension and gift me a beer too

The example at the bottom of the MSDN page on MSBuild Inline Tasks already provides pretty much all you need for that with a TokenReplace task that receives a file path, a token and a replacement and uses string.Replace with that. Similar in spirit but way more useful in its implementation is the RegexTransform in NuGet’s Build.tasks. It’s much better not only because it supports full regular expressions, but also because it receives items, which makes it very amenable to batching (applying the transforms to multiple items). You can read about how to use it for updating assemblies with a version number, for example.

I recently had a need to also supply RegexOptions to the task so I extended the metadata and a little bit of the inline task so that it can parse the optional flags. So when using the task, I can pass the flags as item metadata as follows:

<Target Name="ReplaceReleaseNotes">
    <ItemGroup>
        <RegexTransform Include="$(BuildRoot)**\*.nuspec"
                        Condition="'$(ReleaseNotes)' != ''">
            <Find><![CDATA[<releaseNotes />|<releaseNotes/>|<releaseNotes>.*</releaseNotes>]]></Find>
            <ReplaceWith><![CDATA[<releaseNotes>$(ReleaseNotes)</releaseNotes>]]></ReplaceWith>
            <Options>Singleline</Options>
        </RegexTransform>
    </ItemGroup>

    <RegexTransform Items="@(RegexTransform)" />
</Target>

It also supports specifying multiple options, like “Singleline | IgnorePatternWhitespace”  and the like.

The code changes to the task are minimal:

<!--
============================================================
            RegexTransform

Transforms the input Items parameter by evaluating the
regular expression in their Find metadata and
replacing with their ReplaceWith metadata. Optional, the
options for the regular expression evaluation can be specified.

Example input item:
        <RegexTransform Include="$(BuildRoot)Src\GlobalAssemblyInfo.cs">
            <Find>AssemblyFileVersion\(".*?"\)</Find>
            <ReplaceWith>AssemblyFileVersion("$(FileVersion)")</ReplaceWith>
            <Options>Multiline | IgnorePatternWhitespace</Options>
        </RegexTransform>

Invoking the target:
    <RegexTransform Items="@(RegexTransform)" />
============================================================
-->
<UsingTask TaskName="RegexTransform"
           TaskFactory="CodeTaskFactory"
           AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll">
    <ParameterGroup>
        <Items ParameterType="Microsoft.Build.Framework.ITaskItem[]" />
    </ParameterGroup>
    <Task>
        <Using Namespace="System.IO" />
        <Using Namespace="System.Text.RegularExpressions" />
        <Using Namespace="Microsoft.Build.Framework" />
        <Code Type="Fragment"
              Language="cs">
            <![CDATA[
       foreach(var item in Items)
       {
         string fileName = item.GetMetadata("FullPath");
         string find = item.GetMetadata("Find");
         string replaceWith = item.GetMetadata("ReplaceWith");
         string optionsValue = item.GetMetadata("Options") ?? "";

         var options = string.IsNullOrWhiteSpace(optionsValue) ?
             RegexOptions.None : (RegexOptions)Enum.Parse(typeof(RegexOptions), optionsValue.Replace('|', ','));

         if(!File.Exists(fileName))
         {
           Log.LogError("Could not find file: {0}", fileName);
           return false;
         }
         string content = File.ReadAllText(fileName);
         File.WriteAllText(
           fileName,
           Regex.Replace(
             content,
             find,
             replaceWith,
             options
           )
         );
       }
     ]]>
        </Code>
    </Task>
</UsingTask>

Update: As noted by Emperor, I simplified the code for parsing the enum from using Aggregate to a simple string replace of | with a comma, which is readily supported by Enum.Parse

After some minor trial/error, it turns out to be very predictable (as many things in github):

https://raw.github.com/wiki/[user]/[project]/[page].md

Just replace the square brackets’ stuff with your values and that’s it. I think I’ll be trying this out with a wiki page as a Release Notes landing page, which I just pull in raw format on a build script and replace the Nuget <releaseNotes> node with its content…

I’ve seen a trend in Google apps where they put an overlay on top of the app the first time it runs, to explain how the various pieces of UI work. I have seen this also on my Nexus phone, but don’t have a screenshot. I don’t recall a way to actually bring that help overlay back again, so that’s maybe some built-in gesture that’s missing. Here’s what it looks like in Gmail, the first time you use the new compose layout:

I like the approach very much, and I think it’s something that should become standard part of mobile OS, and Windows, including a standard way to bring that help up from within any app.

Update 11/22: here’s another example, now from Netflix Android app:

Update 11/25: looks like a tend to me now. This time from YouTube app

If, however, those dependencies are distributed by some other means (i.e. another extension, or are part of VS private assemblies, or whatever) and you want to avoid including them in your VSIX, you can add the following property to the project file:

<PropertyGroup>
  ...
  <IncludeCopyLocalReferencesInVSIXContainer>false</IncludeCopyLocalReferencesInVSIXContainer>

<PropertyGroup>
  ...
  <TargetVsixContainerName>MyCoolExtension.vsix</TargetVsixContainerName>

Happy extending

I recently came across littleBits while watching a TED video of their creator. I was immediately hooked. It seemed like the perfect blend of simplicity and self-learning that I was looking to get my kids into electronics. So I went ahead and purchased the kit from SparkFun and a bunch of standalone parts ("bits") from the site itself. There are also a bunch of videos and pictures on their site to get a better idea of what they are, as well as multitude YouTube videos.

This weekend I gave them to my kids, and coincidentally, we also travelled to my hometown and they got to share them too with their cousins.

Man, what a blast it was! I decided to approach this "toy" just like one of the iPod/iPad games I buy for them: "How it’s used? I’ve no idea! I just heard it was great, you go figure it out!". And figure it out they did.

They spent the entire weekend trying out different combinations, together on a table, 3 to 5 kids between 6 and 12 alternating, collaborating and sharing their discoveries of what pieces worked with others, speculating why, and so on. I provided some explanations when asked, but it was very much self-directed learning. I was mostly giving them names for the things that they already knew how they worked.

I strongly recommend watching the short TED presentation by littleBits creator. The basic idea was to come up with a Lego-style set of building blocks to learn how electronics work. The greatest thing about this approach is that it requires no soldering whatsoever: you just snap together the little blocks and magnets do the work of ensuring you don’t connect them in the wrong direction. This allows for immediately feedback on the functioning of the circuits and their combinations, unlike the soldering-based kits. It’s also much cleaner than the breakout board-based ones. No programming is required, although its creator hinted at a programmable module down the road, which seems to me like the logical next step once you master the basic hardware based logic gates.

You can buy the modules individually or in a kit. The kit is very small to be of use for such a large group, but it may be ok for a single kid. I decided to complement the kit with additional sensors and logic modules.

Since I knew I wanted a group of 3 or 4 kids to be able to play together (I’m planning on selling the idea to buy these toys to my kids’ school), the first thing was to decide on the power, to enable multiple ongoing experiments at a time. Initially I thought the rechargeable flat watch-style battery module would be the most useful.

It turned out to have far too little power for a lengthy playing session. They were exhausted in about 30′ I’d say. They also cannot power the more energy-savvy motors and fans, so kids were quickly complaining about why they didn’t work. The 9v battery module turned out to be much better, but the battery was not rechargeable and the recharging cycle for one also wouldn’t be quick enough for them:

The best one was the micro-USB module, which I just plugged to the car power while traveling, and to a regular phone charger while at home.

I think it will be the most used form of energy for this, since they usually kept the modules running for a long time while trying other alternatives before plugging them in. To cut the cord when needed, it was also very useful to have the Sanyo recharging battery which was used also with the same micro-USB module:

In order to draw power from a single module to multiple paths (one for each kid or group), I used a fork combined with prolonging cable modules:

This battery did have enough juice for all 3-4 branches of circuits, each containing 3-5 LEDs and a one or two motors and fans, and it worked for hours.

They had lots of fun trying to figure out how the logic modules worked, and which combinations “worked”.

It was very collaborative as they built fragments of circuits, tested them separately and they tried to plug them all together and see if everything would still “light up”.

By far the most successful modules were:

• LED (green)
• RGB LED: you can vary the color component with a plastic screwdriver that comes with each of these modules
• Pulse: this was a favorite, not sure why
• Bargraph: an analog component that turns on more LEDs the more energy that passes through it
• Pressure sensor: used to drive the bar, but also as a switch
• Fans, motors and vibration motor modules
• Button or toggle switch
• Roller switch

We couldn’t find a good use for the Timeout, and we couldn’t figure out the difference between the Fork and the Branch (aside from their shape). From the logic gates, inverter and OR where most used, and you probably don’t need more than one of each kind, maybe 2 or 3 inverters. Fork was very useful to allow for more complicated designs spanning multiple modules, joined with OR or AND gates.

All in all, it was one of the best purchases I made for a toy. It’s still quite expensive, and I certainly hope to see its price come down to around $5 per module max, considering you need about 20 per kid to make it interesting. I believe they have a good chance of becoming the next Legos of electronics.

I was intrigued by the possibilities that a flexible and general-purpose hosting solution like Github could offer for a static blog engine: basically keeping plain markdown/HTML/razor/WLW/whatever files that through a publish/build time process generate static files that pass for a "blog engine". GitHub even supports custom domain names, so why not?

Such an "engine" would have a number of benefits:

• Plain CSS styling
• Arbitrary JavaScript
• Leverage the web infrastructure (caching, CDNs, etc.)
• Easy to restyle: just change templates, and rebuild
• Hosting anywhere, including plain Amazon S3

Comments and trackbacks are trickier, but the "app server-less" plus is just too compelling.

I even found a couple projects that actually do this, using Ruby or Phython for the build/transform on publish. Just search for "static blog engine".

But I found that they didn’t leverage GitHub’s native capabilities. What if comments on the blog were just GitHub comments on the entry source itself? That would mean that as the blog admin, I could get to moderate and reply using standard github interface, or even answer by email.

Anyone could also just branch my blog and send pull requests whenever my samples or content could use some improvement. It could even be the basis for some wiki-style collaborative editing of sorts, with the built in versioning and diff viewer that works so great for code.

Maybe this is a service a third party site could provide automatically: using a GitHub service hook it could automatically pull changes, build static site and check back in the updates. And when users want to comment, automatically ask in a nice UI for GitHub credentials (maybe even registering you automatically if you want to?). Maybe even allow "anonymous" comments by using a well-known GitHub account just for this purpose? And it could also take care of creating trackbacks as comments too…

The cool thing about such a service, is that it could evolve to support multiple input formats and template languages for the static site building phase, and maybe even provide migration tools if you want to switch formats.

What else does a "proper" blog engine buy you that would render this idea useless? Is it just stupid or actually makes sense?

You can just download the vs2012cmdhere.inf, righ-click the downloaded .inf and select Install. This will add the following context menu:

And the command can even be uninstalled from Add/Remove programs.

Enjoy!

There’s a challenge though: we’d all have to agree on using a certain logging framework up-front. Or we could all agree on a common API (much like Common Service Locator did for picking DI containers) and provide specific adapters. The former is impossible, so it’s got to be the latter

There are some efforts in the area, most notably Common.Logging which has quite a following according to the nuget download numbers. So I set to investigate how thin the abstraction was: 28 public types, yuck. Doesn’t look much like a thin wrapper over specific frameworks . One problem I noticed right away is that it already provides a bunch of abstractions to write logger implementations, reading configuration, etc., which I believe should be totally out of scope of such an abstraction.

The abstraction should be about the consuming side, not the bootstrapping/authoring side. Just like common service locator doesn’t dictate how you configure a container, how to initialize or extend it in any way, neither should a logging abstraction: just the API for consumers, nothing more.

I looked across log4net, NLog and EntLib logging, and at the core, they are about just two operations: log a message (with a formatted overload), or log an exception alongside a message (also with a formatted overload). Then they all provide a gazillion overloads in their main logger interface/class for all the permutations of those four by each of the supported severity (or log type): Critical, Error, Warning, Information and Verbose (also called Debug).

That’s IT. There’s nothing more an abstraction for consuming code needs. Here’s all we need:

interface ITracer
{
    void Trace(TraceEventType type, object message);
    void Trace(TraceEventType type, string format, params object[] args);
    void Trace(TraceEventType type, Exception exception, object message);
    void Trace(TraceEventType type, Exception exception, string format, params object[] args);
}

The BCL already has TraceEventType which can be used to determine the type of entry to create, although some logging library might not support all of the values in the enumeration (although I would love it if they do, because the activity tracing ones are really really useful if leveraged properly, but that’s another post . Of course some usability overloads to do a direct tracer.Warn(….) are nice, but those can be easily placed in a static class as extension methods, allowing us to keep the main interface clean:

public static void Error(this ITracer tracer, object message)
{
    tracer.Trace(TraceEventType.Error, message);
}

Note that the message parameter is an object. This allows each implementation to support their own fancy formatting/rendering of arbitrary objects.

We’ll also need a way to retrieve tracers for use in our app, and that’s another very small piece we need for the abstraction to work:

static class Tracer
{
    public static ITracer Get(string name) { ... }    // Convenience...    public static ITracer Get<T>() { ... }
    public static ITracer Get(Type type) { ... } }

This static class would need a static Initialize method where you’d pass the implementation that retrieves the actual tracer implementations for each specific logging framework. The bridge there could be something like an ITracerManager, with the same API as the static facade:

interface ITracerManager
{
    ITracer Get(string name);
}

That’s all. A general-purpose logging abstraction does not need anything more than this.

Now, given that this is SUCH a small abstraction, does it justify being a full-blown assembly? I don’t think so, and in the spirit of NETFx, I’ve made it a source-only nuget package. So you can, right now, go and add this package to your own “Common” project, or “Core.Interfaces” that is shared by all of your app components:

Install-Package Tracer

Next, just start using it by retrieving (ideally statically) a tracer for use in your components:

public class MyComponent
{
    private static readonly ITracer tracer = Tracer.Get<MyComponent>();

    public void DoSomething()
    {
        tracer.Info("Doing something...");
        ...
    }
}

Then your bootstrapper/application startup code, can take a dependency on a specific implementation of the tracer, and initialize it appropriately. Choose your option of log4net, NLog or Enterprise Library:

Install-Package Tracer.log4net
Install-Package Tracer.NLog
Install-Package Tracer.EntLib

and perform  the one-liner initialization:

Tracer.Initialize(new TracerManager());

Done!

The source is BSD-licensed, so you can do whatever you want with it.

Happy tracing/logging!