First of all, my sincerest apologies for being lax in reviewing issues with Squirrel. I hit a super-hard issue which sapped all my motivation for this project. I'm now back at the point where I can look at this again (I have kept those emails as unread to nag me).

The more I've thought about Squirrel, the more I want to address this issue so I can get back to it. After exhausting all other options, I'm at the point now where I need to bite the bullet and make a significant change.

This might not be a popular change, so let me give some details about the behind-the-scenes work that lead to this.

Move Squirrel to .NET 4.5

We had .NET 4 support in mind as a baseline but there's been a number of specific things in doing this which makes it painful. I want to now set the baseline to .NET 4.5 as it gives us a significant number of benefits:

• installation does not require a restart
• lots of TPL performance improvements
• async/await in the box (more on this later)
• a bunch of WPF improvements too

Async/await is not guaranteed, and I think people want it

To use async/await currently in Squirrel (or any part of your installer or application), you need a specific KB to be installed. KB 2468871 is part of the .NET 4.5 rollup, but they backported it to .NET 4 so you could use async/await with your .NET 4 apps.

Unfortunately not everyone has this update, so your app can behave in subtle ways (ways which are also wrong). We wanted to avoid these issue, so we pulled all the async/await usage from the Squirrel library. This gave us a bunch of messy, unmaintainable code - which made us sad.

Let's imagine you want to build a custom UI in WPF and you use async/await. Your installer will likely fail in magical and weird ways for some users (WinXP in particular). I don't want to say "no async/await for you", but there's a bunch of weirdness in there that makes supporting async/await in the wild really hard.

Bootstrapper is no longer straight-forward

So, let's say we want to ship this KB nonetheless as part of the installer. ClickOnce has support for this as a part of Windows SDK v8.0A, so there's obviously a use case here.

The thing I really don't like about this approach is that the KB installation requires a restart before you can continue with the rest of the installer. It's unavoidable and disrupts the user experience.

XP support is ending, for the Nth time

My interest in supporting this OS is trending towards zero right now (it's coming up on 13 years in existence). If we switch to .NET 4.5 as a baseline, XP cannot be supported - as .NET 4.5 just cannot be installed on XP.

I suspect this is the toughest part of the issue, but given April 8 is fast approaching I'm more interested in supporting the same platforms that Microsoft are actually supporting (beyond security fixes) because that's where everyone is focused on currently (or should be?).

GitHub for Windows is moving to .NET 4.5

I had a big push a few months ago to get our app using Squirrel. I made a decent amount of progress, but was pulled onto other projects and so this fell by the wayside.

Now I'm dusting this off, we're at the stage where we're ready to upgrade our application to .NET 4.5. So I'll need to target both .NET 4 (which I won't be using) and .NET 4.5 - potentially duplicating the work required to get to a v1 feature set.

Feedback

I want to hear from you guys - whether you are for or against this change. I'm also thinking on ways to be able to support a subset of the Squirel features in .NET 4 - for example installation, updating and a simple UI ala ClickOnce - for those who are unable to transition.

Nothing is set in stone, but this is the big mental roadblock I need to get over before I can start thinking about reviving Squirrel.