You’ll remember that I recently experienced a snag while working on the same dotnet script script(!?!) on two different machines. During the project, I updated dotnet script on one machine but forgot to do it on the other. I wrote in my post that the solution was just to remember to upgrade on all machines, but Bernhard recommended a better solution.
Working with software integrations can be both interesting, fun and mind-boggling frustrating. Today I needed to parse a table in a website (first mistake), clean the text using regular expressions (second mistake?) and generate a corresponding table in Markdown using dotnet script (definitely not a mistake).
I really do love dotnet-script and its almost perfect integration with Visual Studio Code. But as it is a .Net Core global tool, and VSCode uses file-based task specifications which know nothing of this, things can sometimes break.
I’ve create a simple script for giving me a nice text to share whenever I post a new post to this site. Sure, this can be further automated, but you’ve got to start someplace.
For development I use two different Macs, an iMac at home and a MacBook Pro during my commute. I started coding this on my iMac, but on my ride to work I got this error while trying to debug from VSCode on my MacBook Pro:
The application to execute does not exist: '/Users/sankra/.dotnet/tools/.store/dotnet-script/0.25.0/dotnet-script/0.25.0/tools/netcoreapp2.1/any/dotnet-script.dll' The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core. The program ' dotnet' has exited with code 129 (0x81).
The script ran fine from the shell using
dotnet script main.csx . So what is the cause of this error?
This site is built with Jekyll, hosted on GitHub Pages, has DNS through Hover and is served by the Cloudflare CDN. The site is static, that is all pages are rendered ahead of time on the server. That means that even the simplest web server in the world could host hjerpbakk.com without issue. So why is Cloudflare a part of this stack?
I put it behind Cloudflare for three reasons:
- Real simple TLS
- Security, Cloudflare can protect you from DDoS attacks (not that this is an issue for me) and has a looong list of known bad players which are blocked from accessing your site.
- Performance, Cloudflare has a global CDN and an excellent cache. Thus, your own server is hit far less than without this outer layer.
Since Cloudflare has a cache, how do you make sure the right parts of the cache are invalidated when you create new content? With a simple dotnet script that’s how!
Comics Downloader is a dotnet script that will download comics from comics.io. It will start with a specified strip and continue until all strips are downloaded for the given comic. It can also optionally combine them into a .cbz-file, a comic archive.
View the source on GitHub.
We’ve lately rewritten our build systems at work using scriptcs. Scripts with C# as the language with full access to the rest of .Net. Aka PowerShell as it should have been. This rewrite has been awesome for several reasons:
- Ease of use: Since we’re a C# shop, writing the build system in scriptcs is both convenient and time saving. I still remember TFS 2012 XAML based builds with dread.
- Flexibility: The build system is build server agnostic, the same script can be used on Team City, TFS, locally or on any other server
- Ownership: The build system is now so trivial that every team can easily understand and extend the system when needed. The build system becomes part of the product, not something the other guys do.
- Server or local? Same, same: The same scripts are used locally and on the server. The previous XAML based builds were an opaque mess.