Squirrel VS dotnet-script

I never had much luck with ClickOnce, so I was using Squirrel.Windows. I've recently switched to the Clowd.Squirrel fork, since I needed support for AzureSignTool in the build process.

As soon as Office 2007 didn't use MSI the format was doomed.

I assume the Here in NIH refers to an individual team, not MS as a whole.

Teams is entirely NIH https://github.com/Squirrel/Squirrel.Windows for updates to the Electron app.

I would use winget, but MS made it weirdly hard to run as a script on multiple computers, it installs per user, because... who knows.

So still using chocolatey

Back in the day, wasn't Discord installed using Squirrel?

Originally, we used to use Squirrel.Windows for our internal applications but we had a few issues with it before we finally dropped it.

The most viable option with the path of least resistance would be Squirrel.Windows as it is both and installer and updater but has some caveats (SemVer pattern must be followed).

Maybe someone has a better ide, but this is one of many reasons why I'm trying to get all our old ClickOnce installers migrated to something else (I've heard good things about Squirrel.

Electron does have auto-update built in (Squirrel), but it comes with severe non-price related caveats. Squirrel is only intermittently maintained and goes through long periods in which the different versions are abandoned (see for Windows, macOS). People have requested a switch to Sparkle on macOS, which is what Conveyor uses, but with no response. There's also the issue that their update solutions require interactive servers but the only free one is restricted to open source projects, and isn't itself open source. The Electron website points you towards a variety of projects if you want to run your own server but all of them are (again) abandoned for years.

We replaced clickonce with https://github.com/Squirrel/Squirrel.Windows and are generally happy with the choice

Discord in the Task Manager can sometimes show up as "Update", made by GitHub, because Discord uses a program, that GitHub / their devs were/are involved with making, to update the app, and some kind of bug happens that means it doesn't display as 'Discord'.

Especially because these languages are only one package/install away and not two. I don‘t really get for which audience is targeted here. Usage in JS projects maybe, but then why not write it as npm tasks. ..

I‘m playing around with dotnet-scripts [1] at the moment (C# shop mainly) and this has the same issue imho. The reason why I looked into it was because we have developers not accustomed to bash etc. I still find it silly and would rather use ruby so…

[1] https://github.com/dotnet-script/dotnet-script

>making powershell actually enjoyable to use

My solution was to stop using it and instead use dotnet-script

https://github.com/dotnet-script/dotnet-script

Scripting with the full power of modern C# has been a huge win for me. And same/similar scripts will work on Windows/Linux/Mac. As my work language is C#, I don't have to context switch to another language for scripting.

I usually create a container that has all database migrations and tool to execute those migrations. I name migrations as [yyyyMMdd-HHmm-migration-name.sql] but please feel free to use any naming scheme, keep in mind how the tool would order multiple files to run those migrations. I have also added a wait-for-db.csx file that I would use as the entry point for database migrations container. This is a dotnet-script file and would be run using dotnet-script. I have pinned the versions that are compatible with .net sdk 3.1 as this the version roundhouse is build against at the time of writing.

thanks, this is very good idea too, and with dotnet-script we can publish executable out of the script!

It sounds like this is feedback for the author of the dotnet script tool: https://github.com/dotnet-script/dotnet-script

Yes, you can have single-file scripts too. There might be more options to achieve this, but the one that I use is running *.csx files via the dotnet-script (https://github.com/dotnet-script/dotnet-script).

I do agree.

I think .Net has got it right. And dotnet-script [https://github.com/dotnet-script/dotnet-script] has been a game-changer for me with a REPL-like experience for unit testing and writing command-line utilities.