Nancy 0.12 released!

I am really happy to announce that we’ve released Nancy 0.12 into the “public”. To be fair all of our work is always in the public, but now we’ve actually slapped a new version on it and put it up on Nuget for easy access!

It took a bit longer than I would have liked, but it’s amazing with a little bit of summer and a month off from work will make time pass incredibly fast! There is an old Swedish proverb that says “"He who waits for something good never waits too long." which basically means “something good is worth waiting for” and I’d like to think it very much applies to this release.

It’s a massive release with 20 authors squeezing in 237 commits and helping with closing of 64 work items. Thank you, so much, to all that have contributed! You can find the full commit log here and the work items here. There is no way I can walk you through all 64 work items, that makes up this release, so I’ll give you a short highlight reel.

Content Negotiation – the star of the release

Getting support for Content Negotiation, into Nancy for this release, was the big thing for me and @Grumpydev http://twitter.com/grumpydev and we really went into this with a clean slate and quite a lot of questions, mostly on how to preserve the Nancy syntax and make it really Super-Duper-Happy-Path.

I am happy to say that the syntax stayed exactly the same, it just got more powerful! The key difference is that you are no longer restricted to returning a Response object (or any of the types that are implicitly cast to one), but you can return what-ever-you-want. Booya!

If you return anything else than a Response object, the response will be subject to take part in content negotiation with the client that sent in the request. We provide a syntex to help you control the behavior, on a per-route level (should you need to) and application wide conventions.

Content Negotiation is built around the new IResponseProcessor interface, which is what you implement to add support for a new media range or model type, and Nancy will automatically detect it and wire it up for you!

Keep an eye on our Wiki for more detailed information, on Contente Negotiation, that should be coming up very soon. If you want to jump right in, you can either have a look at the Nancy.Demo.Hosting.Aspnet project, in our solution, and more specifically the /negotiated route.

You can also watch the aspConf talk, by Christian Horsdal on “The Lightweight Approach to Building Web Based APIs with .Net” where he shows of the content negotiation bits. The source code for his sample can be found at https://github.com/horsdal/Restbucks-on-Nancy

Stateless authentication

A new, out-of-the-box, authentication method has been added by Byron Sommardahl and can be installed with the Nancy.Authentication.Stateless Nuget. For a demo, have a look at the Nancy.Demo.Authentication.Stateless project, in our main solution.

Json.net serializer

Emil Cardell also contributed ISerializer and IBodyDeserializer implementations for JSON.NET, which can be installed using the Nancy.Serialization.JsonNet nuget package. Once installed it will automatically be picked up by Nancy.

No more NDjango out of the box

In 0.11 we removed it from the Mono Build Configurations and still had it build for Windows configurations. In 0.12 we made the decision to no longer support NDjango for a couple of reasons.

The development on the NDjango engine has been stale for quite a while now. Because of the fact that it’s built on F# has also always been a bit of a pain for our Mono support and with the release of .NET 4.5 and Windows 8 it’s added even more headaches that Grumpydev blogged about. If you wish to use NDjango then you can still do that.

It’s just an implementation of our IViewEngine interface (which is really light) so you can dig out the source code from our repository and just stick it in your project. You can even create and maintain your own Nuget for it, all we’re saying is that we won’t be the ones maintaining an NDjango engine anymore.

Lots of love for Nancy.Testing

For this release we gave the Nancy.Testing package some needed love. The whole list of changes that were introduced can be found here but I wanted to give highlight a couple of things

Convention based loading – Because of the way that .NET loads (or rather not loads) assemblies, that aren’t explicitly used, into the AppDomain, Nancy.Testing sometimes could not find these types. For instance if you test assembly A, referenced application assembly B, which in turn referenced helper assembly C then C will not be loaded into the application domain of the tests, unless one or more types from C where explicitly referenced from test assembly A. This is not a Nancy thing, but a .NET thing.

What we did was to have the ConfigurableBootstrapper help you get around this, but taking the name of the test assembly, attempting to remove “test”, “tests”, “specifications”, “specs”, “unittests” from the end of the name and make sure it, and all assemblies it references are loaded into the application domain.

This is not going to cover all scenarios, but it should cover the majority of them. As always, the naming conventions can be modified by setting the static TestAssemblySuffixes on the ConfigurableBootstrapper

Removed XUnit dependency – Before, some of our assertions were using xunit assertions internally, forcing a dependency on XUnit no matter if your tests were written in a different test framework or not. We’ve now removed this completely by adding our own assertions.

Now using CsQuery instead of HtmlAgilityPack – Our assertion helpers, that lets you assert on the HTML that is returned by a view, was previously using HtmlAgilityPack under the hood. We decided to swap over to CsQuery, which is a C# implementation of the jQuery selector syntax. Mostly because of some issues we were having, plus CsQuery has a cooler syntax. This should not have an impact on your test.

Auto-registration is now disabled by default – If you were using the ConfigurableBootstrapper, before 0.12, then it would use auto-registration, by default, to scan and register types into the container. You had the option to disable it to give you a (potentially huge) performance boots and make the tests more explicit. Starting with this release we flipped the behavior so that auto-registration is always turned of and you have to explicitly enable it with the EnableAutoRegistration option. We hope that it will help make the intent of the tests even clearer and at the same time make sure they are executed as fast as possible.

IStartup gets a new identity

You might have used the IStartup interface to perform a code action when the application started, for the first time, or to register some dependencies in the container. Looking at it, we thought it was a violation of the Single Responsibility Principle and decided to split the two actions into separate interfaces.

There ended up being IApplicationStartup for startup actions and IApplicationRegistrations for dependency registrations. You could always implement your own IStartup interface that simply inherited from IApplicationStartup and IApplicationRegistrations and the rest of your code could be left unchanged.

Razor error page

If you’ve ever encountered the Razor error page, that you get when there is an error in your view, then you know it does not offer much assistance to resolving the problem. We pimped the page so it’s now damn useful and should help you pinpoint your issue in seconds. Have a look your self!

nancy-razor-error-view

Now that’s what I call awesometastic!

Breaking changes

Yep, unfortunately, there are some of those too. As always we try to keep them as few as possible and hopefully most of them won’t have an impact on your application. For a full list of the breaking changes, take a look at the list
https://github.com/NancyFx/Nancy/issues?labels=Breaking+Change&milestone=10&page=2&state=closed

Things to come

Looks like there are a huge list of cool things coming down the pipe. For the next release (which should happen within the month) we will be going over the 30+ open pull requests and pull in the ones we find awesome and suitable.

Looking a bit further down the pipe we have async routes, improved session and cache support which will let you hook up any provider you want (how about memcache, redis or a database?) very easily?!

Nancy : 0.11, more than the sum of its parts

With out eleventh release just our the door, I was struggling to come up with a descriptive post title that captured the essence of the new version. Looking back at the 190 commits by 25 authors that make up the release,  "more than the sum of its parts" is an appropriate description.
A total of 78 contributors, with more lining up with pending pull requests for future versions, have helped make Nancy the awesome framework we have the pleasure to put to your disposal.

A glimps of what’s new

It would take up far too much space to write about the 62 work items that’s gone in to this release, so instead I will just cherry-pick some of them and present them here. You should visit the milestone at github and check out everything that’s gone into 0.11.

  1. Favicon override by just dropping a favicon.ico/png anywhere in your application path. Can still override the FavIcon property in the bootstrapper if you wan’t custom logic or use an embedded icon
  2. Updated the FluentValidation nuget dependency to 3.3.1.0. Turns out the FluentValidation nuget contains a strong-named assembly
  3. Added AddFile to StaticContentConventionBuilder, enables you to map individual files
  4. Allow Nancy to run on machines with FIPS Compliance enabled
  5. Added our own ViewBag concept and exposed it on several of the view engines
  6. @helper functions are now supported by the Razor view engine
  7. HtmlHelpers/UrlHelpers gained a face lift and now expose a rich set of properties, such access to the model, the render context (thus the actual NancyContext itself) and the engine itself. This opens up the door to write pretty much any kind of helper extension you can envision

This is just a small selection of all the new features and improvements that have been added for this release, make sure to read the full change log.

Breaking changes

We really do try out best to limit the number of breaking changes that we introduce with each release. Some APIs are still being explored and as feedback comes in from users, we sometime feel the need to make some breaking changes in order to make the path forward easier on everyone, contributor or consumer. In this release we have 2 breaking changes (the milestone says 3, but 2 of them relate to the same change, just different areas in the code base).

  1. Removed Nancy-Version header. In hindsight this was nothing more than a framework vanity place, put in by yours truly. I do agree to the idea of the less information you expose, the smaller the attack vector will be on your application and with this in mind we decided to pull the version out starting with this release. You can add it back in with an application pipeline hook if you have a need for it. If you don’t know how to, just drop us a line at the user group and we’ll get you sorted in no time.
  2. Added NancyContext everywhere. This is probably only going to affect you if you have been extending any of Nancy’s sub-systems (error handling, authentication, model binding and so on). There were a couple of sub-systems where the context was not available, which made it difficult, if not impossible, to sometimes get the full potential out of your code. Hopefully this change will improve the experience by quite a lot. If you spot a place where the context would do good, let us know.

What’s up next

There are quite a lot of pending pull requests, with all sorts of interesting new features and improvements, that are waiting to be included in the next release. The main focus for me and Steven are going to be to add support for async routes and content negotiation. We have created a post, with the title Planning 0.12 : Content Negotiation to capture your ideas for how it should look and work in Nancy. We will be creating a similar post, soon, for async discussions.

We also have a goal of making more frequent releases, there is no point in holding back a release just because we want to get certain features into it, they can always come in the next iteration. We feel that it would be far more productive if we had a shorter (maybe every 3-4 weeks) release cycle so we get all the awesome stuff, that’s contributed by the community, into your hands faster.

That’s all for this release!

Nancy : Now with Mono builds on every commit

We’ve always tried to make sure that Nancy being able to run on Mono for every new release we put out. Since neither me or @Grumpydev use Mono or MonoDevelop as our primary development environment, nor does a lot of our contributors, we’ve always found ourselves having to play “mono-catch-up” at the end of each milestone.

Having that extra step in the release process is a bit of an impediment when all we want to do is ship the new bits, as fast as possible, so we can put them in the hands of our community. Obviously we needed a change in our process and it was obvious that we needed to incorporate a Mono build into our CI process.

This is actually not a new idea we’ve had. For probably the better part of a year I have been trying to figure out how to make this happen. We are proud users of the CodeBetter TeamCity server and it’s always worked well for us, with great support. So my goal has always been to get a Mono build agents wired into that.

For one reason or another, it’s always fallen short, that is, until now. About a month ago I decided to take another swing at this so I contacted the people at CodeBetter to check on the likelihood of having a Mono agent added. I’d also talked to the awesome Dale Ragan (of Moncai, Monkey Square and Monospace) if he’d be willing to share a bit of his time and knowledge around the subject, which is was more than willing to.

A couple of e-mails later, the plans had been made and Dale also informed us that Monkey Square would like to sponsor the build agent and cover the cost of the EC2 instance that it would be running on. How cool isn’t that of them!?!

Today we ran the first successful, automated, Nancy Mono build using the new build agent! This is going to make it so easier for us to make sure that everything is strawberries when it comes to Mono at the time we are ready to push out a new official version. We’ll get near instant feedback on each of our commits and every time we accept a pull request. This means we can act immediately to sort it out instead of risking to put them all on a pile (usually a very small pile.. more like a bump really, but still a list of things that needs to be sorted).

Nancy builds for .NET and Mono running on the Mono agent at the CodeBetter TeamCity server

(Yes, fewer tests on the Mono build because things like our WCF host is obviously not supported on Mono)

I would also like to make a shout-out to the awesome people at CodeBetter, especially
James Kovacs and Kyle Baley for their help in making this happen. A special thanks also goes out to Hadi Hariri, of JetBrains, for always helping out with my TeamCity questions and for encouraging me to push hard enough to make this a reality.

Nancy v0.10.0 – The next step in awesome

TL;DR

A couple of days ago we (finally) managed to get v0.10.0 out of the door and it’s packed of goodies! Diagnostics, razor improvements, bug fixes, weighted request headers, model validation and lots of tweaks to existing features are only a couple of things that went into this release.

The community continue to bless us with their awesome work and this release had 22 authors totaling 250 commits, which is just jaw dropping! That puts us at 65 contributors to the Nancy source code. This release consisted of 23 updated (some new) Nugets and a total of 45 work items! For a complete list of things that’s part of this release (including breaking changes!), head over to check out the milestone at GitHub.

So let’s have a closer look at some of the stuff in v0.10.0!

Validating models just got easy

Craig Wilson contributed some absolutely beautify code to help us get model validation into Nancy. Like all other features in Nancy, the validation stuff is shipped as a set of Nugets with the added ability of hooking in your own validation methods. In this release we ship Nugets to use either DataAnnotations or Fluent Validation to validate your models. Combining this with our model binder and you are definitely on the super-duper-happy-path!

The contribution from Craig also contained the foundation to generate client-side validation based on your model rules, however this release does not contain the code to enable that but it’s definitely something we’ll be looking into in upcoming releases (maybe it will be your contribution that brings this to the community?!)

The Nancy.Demo.Validation project, in the main solution, shows you how to use this feature and uses both DataAnnotations and Fluent Validation. Remember, it’s quite easy to plug in other validation frameworks too!

Making sense of what the client sends you

We gave the RequestHeaders class some love, by adding methods to access all available header names and values through properties. We also made the class implement IEnumerable<> to make it easier to work with the incoming headers.

One of the biggest changes is the presence of weighted headers. The headers that can be weighted not returns IEnumerable<Tuple<string, decimal>>, instead of IEnumerable<string>, and will be sorted in descending order according to their weight. Not only will this enable you to manage weighted headers in a correct way, but it’s also an important piece of the puzzle for the planned content negotiation support, that we will ship in a later release.

Sharpening the Razor

The improvements, made to the Razor view engine, in this release really deserves a blog post of it’s own to make it justice. Despite that, I will give you a mile height overview of the changes and improvements that we’ve made.

One of the things that we (me and Grumpydev) really wanted to sort out for this release was adding in Intellisense for our razor views and I am very happy to say that we’ve managed to do that. It includes a couple of custom build providers that is installed, into the bin folder of your project, with the razor Nuget and adds a couple of post-build events to make sure they stay there. I would lie if I said that getting the build providers to play ball was easy. It’s one of those dark corners of Razor customization that nobody speaks of and it involves quite a bit of Visual Studio magic. So to enable Intellisense, all you have to do is build your project, after installing the Nuget, and the Nancy.ViewEngines.Razor.BuildProviders.dll assembly will be copied into your bin folder. The Nuget will also wire them up for you in the web.config, moar super-duper-happy-path for you!

While doing some refactoring work I also noticed how easy it would be to add support for .vbhtml files, so I did. This should be really handy to help you port that legacy MVC application over to Nancy 😉 The included build providers contains one for these views so you should be able to enjoy Intellisese support if you ever find yourself in the need to use the Visual Basic views with Razor.

Oh, speaking of dark corners of Razor, did you know that ASP.NET MVC installs a global handler for .cshtml and .vbhtml files? We didn’t. At least not until we got a bug report that Nancy wasn’t rendering views with the passed in model. Turns out that if you have a view, with the same name as one of the routes, the request would never be passed to Nancy. Instead the global handler would suck it in and render the view. How nice, right? WRONG! Well after speaking to the Razor team it turns out that you can disable this behavior with the, not so obvious, webPages:Enabled configuration key. We updated out Nuget to stick that into your config file when you install it.

Craig Wilson didn’t only chip in with awesome model validation code, he also added support for @model and @ModelType directives, as well as making the Razor engine smart enough to automatically reference the models assembly or as Craig described it in this pull request

The model’s assembly is now referenced automatically regardless of whether an assembly reference exists in configuration. This makes the "it just works" statement a little more complete. In addition, if specified in configuration, the namespace of the model is automatically included in the razor file.

That’s a very awesome little feature to have around!

We also dropped our dependency on System.Web in the engine which means it will run in client profile. It also means that if you took for granted that it was around in your views then you are going to have to reference the assembly and namespace in the Razor configuration. We thing it’s a small price to pay to get rid of that dependency!

All your Url are belong to us

Two small, but oh so useful, changes where made to the Url type. You can now call ToString() and it will give you a correct string representation of the url. The second thing is that the type will now implicitly cast to an Uri instance, how awesome is that!?

Not more White Screen of Death (WSOD)

Have you ever noticed that if you tried to render a view, that Nancy couldn’t find, you would end up with a blank page? Yeah, not really useful is it? To our defense that we never our intention but we somehow forgot to make it more awesome. That is, until now. As of this release, you will now get a view that tells you that it was unable to locate the requested view and it will also tell you which file extensions, based on the available view engines, that can be used. Also expect a future release to also contain information about the locations that were inspected for the view.

Doctor, what’s wrong with me?!

Do you remember the first time we talked about adding in Diagnostics for Nancy? To be honest I can’t say for sure, but I know it was somewhere around v0.3/0.4 and that wasn’t exactly yesterday. It’s been a long time coming, but I am very pleased to tell you that we’ve included diagnostics in this release! It is important to be aware that this release only contains a couple of diagnostics tools, but we’ve put a lot of work into the diagnostics foundation and it will be really easy for us (that that “us” definitely includes you too! We want your contributions!) to add more diagnostics tool for each new release we make.

The diagnostics contains both request tracing and interactive diagnostics. The interactive diagnostics is where things gets really interesting. It enables you to interactively (duh!) query Nancy, at runtime, to figure out what the heck is going in. Before you get too excited, this is not a query language like SQL where you can just fire of queries, even though it would probably be totally possible to implement (hmmm, any takers?). We are introducing the IDiagnosticsProvider interface and anything that implements this can hand our diagnostic capabilities.

These are, quite literally, normal methods that are exposed on our diagnostics dashboard. It enables you to pass in primitive values and have rich result sets be returned and presented automatically. Anything that implements the interface will automatically be discovered and wired up on the dashboard. Not only that, but you can take full advantage of the, 1st class, dependency injection support of Nancy and take in what ever dependencies you want into your providers, making it super easy to do some pretty advanced stuff. Of course you are not restricted to only take dependencies on Nancy types, there is nothing stopping you from exposing a nice interface over your logs etc.

The providers can, nicely, be dropped into a Nuget and reused across any Nancy project out there!

Wanna know something really neat? The entire diagnostics dashboard is build using Nancy and backbone.js and is embedded into Nancy itself (woah! A Nancy application running inside of Nancy?! Yep!)

It’s extremely fast and easy to use. So how do you get access to the diagnostics goodies? Glad you asked! All you have to do is to run in debug mode (although it’s possible to use it in release mode too, you just need to turn it on) and then browse /_Nancy/ in your application. It will give you some (very) easy instructions (really, it teaches you how to configure a password) to get started.

We’ve only scratched the surface of this!

Moar stuff!

Really, I can’t list em all here so head over to the milestone at GitHub.

So wuzz next?

Well, first of all you won’t have to wait as long for the next release. We are going to try to get this out in about 3 weeks time and plan on focusing on trimming down the pull request queue and fix the reported bugs. We have no major features planned for the next release, but that does not mean that we’re not working on any. Quite the opposite, we are working on getting in support for async routes, content negotiation and proper caching support. We just don’t want to keep other stuff away from you while we work on these things and want to keep doing more frequent releases.

Of course there is always the chance that we manage to finish one of them in time for the next release, or that someone contributes something really awesome that will be included!

Thank you for making v0.10.0 possible!

A year of the super-duper-happy-path!

”To sum up, I would just kindly advice Andreas to invest his time and enthusiasm into something better, cause this Nancy was definitely born dead."

368 days ago I first announced Nancy here on Elegant Code and that was a piece of advice that I received among the many comments that followed.

You know what? Back them he might have been right. Nancy was a personal project that I spiked out in a couple of nights and let loose into the wild with no real expectations.

However, taking a step back an looking at the year that has passed, the complete opposite has unfolded . Since the first commit was made by me, on the 20th of November 2010, quite a lot have changed for Nancy. More than I could have possibly have imagined to be honest.

They grow up so fast

In the announcement post I wrapped up with a list of things I knew I wanted to get into Nancy at that time. Some of them were pretty big tasks, some quite small.

  • A much richer request object
  • The ability to inject dependencies into Nancy modules
  • Conditions on actions
  • View engine integration
  • Ship with a nice bunch of response formatters
  • Self-composed framework
  • Request and Response interception
  • NuGet presence
  • Command line (powershell?) support for spawning up a Nancy application project
  • Provide self-hosting somehow
    Not only did we complete all of the above, but those are just the tip of the ice berg of things that’s happened during the last year. Today Nancy’s matured into an awesome framework for building web sites and services on both .net and Mono.

The list of features that are now supported is too long to list here, but a couple of highlights are support for all the major view engines, inversion of control containers, authentication, request pipelines (both on application and module level), model binding and so much more stuff that it blows my mind.

One thing that pleases me though, is that even with all the added features, Nancy is still a light weight framework because of the way it’s architecture. It’s built with a small core that has some nice extension points built into it. Extensions are built in the form of Nugets and to add a feature you simple grab the Nuget for it and of you go. Right now we have 20 official nugets and a couple of ones that’s been created by the community

Standing on a thousand shoulders

This is not the result of the labor of a single individual, quite the opposite.

Nancy a result of the amazing community that’s evolved around it and the incredible list of 57 people that have contributed over 100 pull requests and of course everybody that’s ever provided feedback, suggestion and that’s blogged, created screencast or talked about Nancy at a conference or other gatherings.

The project is a regular on the GitHub Languages page under the C# page, with 504 watchers and 132 forks at the time when I write this post. If you include the number of people that’s taken part in discussions on our user group and on Twitter.

Thank you so much!

A grumpy fella from the UK

Early one on guy from the UK took Nancy at heart and started contributing some pretty impressive stuff to the project. Right from the start he “got Nancy” and understood the vision I had for the project. It didn’t take long (too long if you ask him) before it was only fair to add him as a core developer and get his name on the mailbox.

I am of course talking about Steven Robbins, a.k.a @grumpydev. Not only has he put a lot of awesome stuff into the project, but he’s also become a good friend over the year that’s passed.

Thanks for all your work on Nancy buddy!

Are we there yet?

Not by a long shot! We’ve got so much stuff planned for the project and there are so many suggestions and contributions coming in every week. However it is important that we pace out self and make sure things does not grown in an uncontrolled rate or direction. Every thing that is added into Nancy is still measured on the same scale as before. Controlled chaos as it’s best!

So here’s hoping for another awesome year!

Nancy: v0.8.1 just out the door

Right after we released 0.8 about a week ago, we unfortunately found a couple of bugs. We decided that they were annoying enough to warrant an interim release, hence today we released 0.8.1. All repositories and nugets have been updated to the new version.

In total we fixed four bugs and introduced a breaking change in the JSON serializer while also adding support for TimeSpan in the serializer. For a complete list of changes, have a look at the 0.8.1 milestone at GitHub.

This release shall be known as the grumpy-release as he was the one that did all the heavy lifting. Kudos to his awesomeness!

Nancy takes another step forward

The say time flies when you are having fun and nothing could be more true when working on Nancy. Two months have already passed since we started work on 0.8.0, a release that was suppose to roughly take around 4-5 weeks to complete and consist mostly of diagnostics related changes. Boy were we wrong.

A community release

What did happen was that the awesome community around Nancy kept providing use with feedback, requests and, most of all, code! The 0.8.0 release was not created by me and Steven, but by the community at large.

A quick look at the comparison of 0.7.1 and 0.8.0 shows that a total of 19 authors and 186 different commits contributed code to this release and made the 44 work items happen. If you add all the people that provided feedback on the user group and on twitter then the number is, a lot, greater.

So thank you to everyone that helped make this release possible!

How much awesome can you stuff in a release?

Apparently quite a lot! The list of changes are too great to list in this one single blog post, but fortunately we make good use of the GitHub milestone systems and you can view the full change log at our repository.

However, here are some of the highlights of this release

  • Static content conventions – Yes! We finally have a good user story for static content so you no longer need to jump though hoops to serve static contents. These conventions are, of course, configurable and comes with a default one that looks for stuff in /content.
  • Cross-site request forgery protection – Make sure you can trust the data that is sent to your application.
  • Testing improvements – Added a new configurable bootstrapper in the Nancy.Testing project that helps you control the fine grain of your test environment with the help of a nice API. We also added a bunch of new extension methods and updates.
  • Forms authentication improvements – You can now login/logout without having to performe a redirect, this is really useful in ajax scenarios.
  • Error handling hook and error pages – A pipeline where you can handle errors in your application and also support for rendering custom error pages.
  • Access to captured parameters on the context – Enables you to gain access to captured values from inside filters.
  • ProtoBuf support – A new Nuget that enables you to support ProtoBuf (de)serialization in your routes and model binding.
  • And sooooo much more – Go check it out!
  • All of this and we’re still on the super-duper-happy-path!

Sporting new swag!

With this release we also introduced the new Nancy logo and website! The awesome Nicolas Garfinkiel stepped up to the plate and awed us with his logo suggestion. He has been great to work with and managed to cope with the swarm of tweaks me and Steven threw at him! Not only that but he’s been working blazing fast and it only took us a week-ish to iron out the rough spots in the draft and get a polished version done!

We are really pleased with it and soon you will be able to get your hands on all the logo goodness, you’ve been wanting to (right?!), at our new Nancy.Portfolio repository. The repository will contain the logo in various formats and resolutions and well as a usage guideline. We just need a bit more time to put the finishing touches on it.

In case you’ve not seen it yet, this is one of the compositions of the logo

nancy-blog-logo

Beautiful, isn’t it?!

I plan on dedicating an entire blog post about the logo in the next day or so, so keep an eye out for more information!

Onwards!

Don’t worry, we’re not running out of things to do, in fact we’ve already staked out part of 0.9.0 (there’s even some planning on 0.10.0 up on GitHub). We’re going to try really hard on making the release cycle shorter this time because we really want to get the new, awesome, stuff into your hands as quickly as possible!

By the community, for the community

I would like to thank everybody that supports Nancy, no matter how you do it. People are building commercial produces, going to conferences and talk about Nancy, blog about it, contribute ideas, code and feedback. Nancy is truly a product by the community, for the community and for that we thank you all!

Nancy view cache, now disabled in debug-mode

A quick heads up. In Nancy 0.6.0 we introduced a change that made the application scan, for all available views, and cache them upfront. While this is good for performance, because it reduces view loading time and limits I/O operations, it does pose a slight nuance then you are creating you view.

Because of the cache, each time you made changes to the view template you had to restart the webserver so that the Nancy startup code ran again. A bit of a pain in the sitting area, I agree.

This update is not in the 0.6.0 release it self, not in the NuGet packages. So in order to get a hold of a copy that uses this you will have to either download the latest source code and built it yourself, or grab the latest artifacts from our TeamCity server.