Visual Studio Code
Peter talked about how layout and typography can make code beautiful and improve code readability. After all, as Knuth pointed out:
Programs are meant to be read by humans, and only incidentally for computers to execute.
So how can one improve a monospaced programmer focused typeface?
By utilising ligatures of course!
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.
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?
One day Visual Studio Code (VS Code) did not start on my Mac.
Sometimes I question my sanity.
I’ve used Visual Studio Code (VS Code) since it was revealed at Build. One of its many useful features is the ability to format documents in a human readable form. This includes XML.
Or so I thought.
Visual Studio Code (VS Code) is a great code editor for any platform. And perfect for .Net scripting! I use it to edit my scripts written in dotNet Script. dotNet Script has a lively community with new features being added regularly. VS Code is a collection of different libraries and frameworks, all working together to give you that good experience. Thus, if your new favorite scripting language gets a new feature, it sometimes takes a little while for the tooling to catch up.
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.