OldSquirrelForWindows
OldSquirrelForWindows copied to clipboard
Squirrel
Move Squirrel to .NET 4.5
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.
Awesome sauce that you have found new motivation for moving the project forward. I must say i agree with your reasoning about >= .NET 4.5 support . I'm using Squirrel in 4 different applications right now and it works perfectly for our use cases (though with many workarounds see outstanding issues). So it would be great if you could fix some of the trivial issues before you move to .NET 4.5 so that we can still use it on XP. Then you could maintain a seperate branch for .NET 4.0 and only accept bug / security fixes. So if people want shiny new features, well then too bad! :dancer: One last thing, if you choose todo this, please rename the nuget package to Squirrel.Legacy ;)))))
Keep up the good work dude! ;)
Glad to see that this project hasn't been abandoned!
I'm all for switching to .NET 4.5, but I hope that there are plans that Squirrel can download .NET 4.5 if it's missing on the user's machine and install it automatically (if this is even working without an UAC prompt).
:+1: for moving to .NET 4.5, it's better to do it now than in a few months.
:+1:
There are other solutions around for installers and handling updates so I think it's worth it to leave the 4.0 baggage behind, but definitely do hope as well that installing 4.5 on systems that don't have it isn't too much of a hassle
@peters I'll keep that in mind
@flagbug that's definitely something I intend to support. Will check the UAC situation.
@flagbug
I hope that there are plans that Squirrel can download .NET 4.5 if it's missing on the user's machine and install it automatically (if this is even working without an UAC prompt).
All the .NET Frameworks require elevation to install, but the UAC prompt in a vanilla Win7 install is rather plain:
EDIT: it'll be a prerequisite anyway
:+1: for moving to .NET 4.5. We did this for our app (that's not using Squirrel) when we realised that due to .NET 4.5 being an in-place upgrade, we'd have no way of knowing whether we were inadvertently triggering a .NET 4.0 bug (e.g., see here) without dedicated .NET 4 test machines.
Simplify the XP/4, Vista/4, Vista/4.5, 7/4, 7/4.5, 8/4.5 test matrix by dropping .NET 4.
Yes, please upgrade to .net 4.5 ASAP! I am working on a product that requires.net 4.5 and I wish to use squirrel but the customers are going to get awfully confused when they find it won't run because .net 4.5 isn't installed.
It's great that you are able to put a bit more time into this project it has been a massive timesaver for me on my current project. So thanks so much.
@paulcbetts @shiftkey Could anyone of you pleeeeeease publish a new release of 0.7.4 with updated nuget dependencies? Seriously i'm begging you guys.. i have a ton of updates pending because of old targeting :) :dancers: :dancers: :dancers: :dancers: :dancers:
@peters I'll get caremad and just :fire: all the things down tomorrow when I'm on decent internets.
Apologies for the delays, I'm finally cast-free and no longer a grumpy, one-handed developer...
