Are you using Git a lot from the command line? Isn’t it annoying that you have to open a browser and click your way to the GitHub, GitLab or Azure DevOps repo website to create a pull request or do something else that can’t be done in your shell? To solve that problem, I have a PowerShell function that opens the Git repository straight from your current folder in your shell, in your default browser. It checks the Git config for the origin URL, and opens it automatically. It’s super handy to quickly check the online repo, create pull requests etc.
Copy and paste the code below in a .ps1 script, and you’re set.
function Open-RepoInBrowser
{
$url = git config --get remote.origin.url
if ($url -like "*git@*")
{
# Get the URL from an SSH cloned repo.
$url = $url -replace 'git@', ''
$url = "https://" + ($url -replace ':', '/')
}
if ($url -eq $null)
{
Write-Warning "No URL found. Make sure you are in the root of the Git repository."
return
}
Write-Host "Opening URL $url"
start $url
}
# Execute the function
Open-RepoInBrowser
Now navigate into a Git repository folder, run your script, and see that website open up in whatever your default browser is. Note that PowerShell also runs on most Linux versions these days, so nothing is stopping you from using this easy shortcut.
Here’s a dumb problem I keep having on my work laptop. For some reason, Visual Studio 2022 shows me a notification that it can’t find the Cascadia fonts, and that a reboot will probably fix the problem.
That’s great and all, but I’m like in the middle of something and have a ton of other apps open and really don’t feel like rebooting right now (do we ever?). But being stuck looking at code in an ugly ass Courier font, isn’t what a self-respecting developer feels like doing either, right?
Last time I ran into this, I figured I might as well find the font and see if I couldn’t just reinstall it. VS should pick it up again after a restart. Turns out I was right. No reboot needed, here’s how you reinstall the Cascadia fonts on your machine:
Open the path C:\Windows\Fonts
Lookup the Cascadia fonts. There should be 2, CascadiaCode.ttf and CascadiaMono.ttf.
For each font file, double click it. A window will open, previewing the font. In the top toolbar, click Install.
Now restart Visual Studio. You’ll see your code represented in a pretty font once again.
Wouldn’t you like to be greeted with some random ASCII art when you open up a new PowerShell command window? I thought so!
Here’s a project just for you. Download the ASCII Art Message of the Day project, link the script in your PowerShell profile and bam!, random ASCII art awesomeness every time you open a shell.
Follow the installation instructions from the readme f ile, and you are set. You can even customize what color you want to use. I know, it’s fantastic. The random ASCII art comes from asciiart.eu, so check it out if you want to have an idea of what you’ll be getting.
WSL or Windows Subsystem for Linux allows you to run a fully functional Linux environment, inside your Windows 10 system, without having to set up a virtual machine. It’s a lot more lightweight too, and it integrates nicely with the Windows OS, so it’s a great way to explore Linux, or use the two systems side by side for cross-platform development. This also skips the need for setting up Cygwin and whatever hacky way to access those Linux command line tools on Windows.
I’ve been using it for a while, so I’ll list a short setup guide here, and some tips & tricks to help you along.
Installing WSL
Installing WSL is really easy now. Just open an administrator PowerShell or a Command window and type:
wsl --install
That will install WSL with the default Ubuntu distribution. If you prefer something else, like Debian, you can use this command:
wsl --install -d Debian
The username and password for your WSL system is specific to the Linux distribution. So make sure you don’t forget that password. :)
There are 2 versions of WSL. If you can, run on v2. It’s faster, better and euhm, harder? Anyway, it’s faster, so that’s what you want. But sometimes, you might want to run things on v1 anyway. For example, some VPN clients break with the WSL v2 networking. The easiest way is to set your WSL distro to v1, and see if that works. It did the trick in my case with the CheckPoint VPN on my work machine.
To check your WSL version, run:
wsl -l -v
It should show something like this, if you’re on Debian and v2
NAME STATE VERSION
* Debian Stopped 2
To switch the Debian distro to v1, you can run this:
wsl --set-version Debian 1
Makes sense right? But you just have to know. Switching versions can take a while as it’s being converted, so do this when you have the time for it.
Accessing your files in WSL
Ok, now let’s do some work in WSL, by typing wsl in a PowerShell window.
That’s it, you now have a shell in your local WSL system. You’ll see something like this on your prompt:
n3wjack@Mjolnir:/mnt/c/Users/n3wjack$
That’s a mount of your Windows C-drive into the Linux system. So you can access any file from your Windows system in your Linux shell. The other way around also works.
Open up an Explorer window and enter \\wsl$ in the address bar and hit return. You’ll see a folder pop up for each WSL distribution you have installed. So if you’ve installed Debian, you’ll see a Debian folder. From there you can access any file on your WSL system.
Keep in mind that this cross OS file access is pretty slow, certainly for lots of small files. So if you are planning on working on files, it’s better to choose your OS and stick with it. But it’s super handy that you can easily copy and access files from any system.
Installing software in WSL
Well, this is easy. If you’ve installed Debian or Ubuntu, so you probably know you can install more software using apt or apt-get. WSL pretty much behaves as it should, and you can just install whatever you like using known tools. The account you created when setting up your distro is an administrator account, so you can use sudo commands.
Moving your WSL distro to a new PC
So you have your Linux distro all set up the way you want to, and now you’ve got yourself a brand new shiny piece of hardware to work and play on. How do you move that WSL distro over to the new machine? Luckily, it’s as simple as backup and restore. Really. It’s actually easier than moving your Windows files over.
Creating a backup of WSL works like this:
wsl --export <distribution> <filename.tar>
So if you see that your distro is called Debian after running wsl -l -v, you do this:
wsl --export Debian debian.tar
This takes a while. After it’s done, you copy the tar file over to your new shiny machine and run the following command:
Since .NET 4.x isn’t quite dead yet, here’s a tip from the glory days of ASP.NET unit testing with NUnit (or whatever you like). What if you are working on this project with lots of IOC Autofac registration modules? When you refactor code, and add some new dependencies to a class, it’s easy to sometimes forget to add those new registrations to your module.
At the end your code is finished and unit tested, and you think you’re done, until you run the app and *bam*. A runtime error occurs because you’re missing an IOC registration. This gets even sillier when you have different projects with slightly different IOC registrations, so it might end up working on one project, but not on another.
So how do you go about testing such a thing? The trick is to create a unit test that registers the same IOC dependencies as you do in your project(s), and then instantiate your controllers (or other classes) using the IOC framework. This will start throwing exceptions if you’ve forgotten to register the new dependency, and you will catch it as soon as the tests run. Sweet test automation indeed.
The tricky bit is that your tests are not running inside a web request, which handles the lifetime scope of your IOC objects. So you’ll have to fake a request scope yourself in your test to be able to construct all necessary objects. Luckily, it’s quite easy to do this in your unit tests.
Here’s an example of what that could look like, using NUnit. See the comments for more details.
public class AutofacMvcControllerResolvingTest
{
// The Autofac lifetime scope, which keeps tracks of the created objects.
protected ILifetimeScope Scope { get; set; }
[SetUp]
public void Setup()
{
// Here we setup our IOC container, by adding
// all modules you normally use in your project.
Builder = new ContainerBuilder();
Builder.RegisterModule<YourAutofacModule>();
var container = Builder.Build();
// Now we create our scope.
Scope = container.BeginLifetimeScope("httpRequest");
}
[TearDown]
public void TearDown()
{
// Cleanup the scope at the end of the test run.
Scope.Dispose();
}
// The TestCase NUnit attribute is handy to list a
// number of values which will be passed into the test.
// That way you only need to write one test, instead of
// a test per class type.
[Test]
[TestCase(typeof(FooController))]
[TestCase(typeof(BarController))]
public void Test_If_Controller_Resolves(Type controllerType)
{
// We create the given type using the IOC scope.
var controller = Scope.Resolve(controllerType);
// Assert it isn't null, although if your registrations are wrong,
// the above line will thrown an exception.
Assert.IsNotNull(controller);
}
}
