Category Archives: tips

extend visual studio with simple scripts

There’s this neat feature in Visual Studio called External Tools that’s underrated. What it does is allow you to run any external tool and pass in stuff from Visual Studio and do something cool with that. For example the current file in your editor, or the currently selected text.

This means that you can write a PowerShell script that gets some input from the command line, and for example edit a file (the current file in VS), or search for a substring (selected text) in other files, or a database.

I’ve used this to do a complex number of find-replaces on the current file in a single run. I also use this to quickly find the source code of a stored procedure that’s used in code, by selecting the stored procedure’s name and running the script.

How do you set this up?
In Visual Studio, in the menu click Tools, then External Tools.
There you click Add and give the thing a title.
The command can be a bit tricky, but the easiest thing is to use a .cmd script, like test.cmd.

Then you create this cmd file, and make sure it’s in your path. You can also use the full path to the script for your command instead.
Now pick your arguments from the arrow at the right of the Arguments input box. I’m using ItemFileName here, but there’s plenty of options.

You’re all set.

As a test script you can use this gem:

@echo off
echo ** Command line parameters **
echo %*

If you want to wrap a more advanced PowerShell script, you can use this:

@powershell.exe -nologo -noprofile -file c:\tools\do-something-awesome.ps1 %*

If you run this from a file now, you’ll see the passed in parameters in the script’s output. Like this:

With this technique you can easily and quickly extend your Visual Studio setup to do some mundane tasks a lot faster, using PowerShell, Node.js, Python or whatever your favorite scripting language is.

wake up Windows automatically using a scheduled task

This seems easy at first, but it turns out to be a lot harder than expected, due to various OS and power settings that get in the way. The idea is simple: you want to have your Windows 10 machine start up at a specific time using a task set in the task scheduler.

When you create a new task in the Task Scheduler, there’s a setting for this, so it looks so easy. It’s on the conditions tab. You activate the option to wake the computer to execute your task, and you’re done. Right? Well, if you’re really lucky that might work straight out of the box.
In case it doesn’t work, here are some things you can fiddle with to try and get it going.

  1. Create a wake-up tasks that doesn’t really do anything. Just run a command like this:
    cmd /c echo %date%
    For a more detailed guide on how to set up a task and the wake timers check this excellent article.
  2. Create a second task that does what you want it to do in a batch script but 10 minutes later than the first. That gives your computer ample time to start up, install any potential updates, or do whatever it sometimes does that takes so damn long.
  3. Deactivate Fast Startup. It messes with your hibernation mode and causes it not to startup again afterwards.
  4. Always hibernate your machine. If you just do a plain shutdown it doesn’t seem to automatically start up again. You can do this with the command below. This is also handy if you want to shut your machine down again, after your task has finished:
    shutdown /h
  5. Enable wake timers in your Power Options advanced settings. See the link below for instructions.
  6. For laptops make sure your Power Options are configured correctly. Mind closing the lid in that case. A closed lid will prevent the laptop from starting up in my case for example. Laptops will also not startup when they are running on the battery by default.
  7. Reboot your machine after fiddling with these settings if it still doesn’t work. This makes sure your settings stick.
  8. If you tried everything and it still doesn’t work, check your BIOS settings and see if there might be a power option in there that might prevent it from starting up automatically.

Give your machine a few minutes if you’re testing this. Yes, it’s annoying to wait, but if you set it too fast, it might not be powered down fast enough to be able to start up again, and miss the timer. That way you won’t be able to tell if it’s actually working.

Hopefully you can now use your desktop or laptop to run some nightly scheduled jobs, without having to have a dedicated always-on machine around. Saves you time and money on power consumption, hardware and maintenance!

publish a static website to Azure using GitHub actions

Last post I talked about setting up a serverless website on Azure using BLOB storage. What I didn’t go into is how to publish files to that site automatically. Yes, you can use the BLOB explorer to manually upload your files but seriously, who wants to do that kind of boring task if you can let computers do that for you.

Instead, what I do to publish this excellent programming guidelines website is the following:

  • I make my changes locally and test it.
  • I commit & push my changes to the master branch of my git repository.
  • A GitHub action kicks in and published the site to the Azure BLOB container.

How sweet is that? Pretty sweet, I know. How do you set this up? Well let me take you through the steps my friend, and automated Git deployment will soon be yours to enjoy as well.

  • You need to create a Git repository on GitHub.
    Now that you can create unlimited private repositories, you don’t even have to expose it to the public, which is nice.
  • Clone the repo locally, and create a source/ directory in it. This is where the source code will go, and that’s what we’ll push to the Azure BLOB container. Any other files you don’t want published go in the root, or in other folders in the root of your repository.
  • Copy your source code into the source/ folder, or create a simple index.html file for testing the publishing action.
  • Go to your repository page on the GitHub site, and click the Actions tab at the top.
  • Click New Workflow, choose “set up a workflow yourself”.
  • It will now create a YAML file for you containing your workflow code.
  • Paste the content for your YAML file listed below. Notice the “source” folder in there? That indicates what folder will be copied to Azure.
    In case you run into trouble, you can dig in to the Azure Storage Action setup yourself, but it should do the trick.
on: [push]
    runs-on: ubuntu-latest
    - uses: actions/checkout@v1
    - uses: actions/setup-dotnet@v1
        dotnet-version: '3.0.100'
    - uses: lauchacarro/Azure-Storage-Action@v1.0
        enabled-static-website: 'true'
        folder: 'source'
        index-document: 'index.html'
        error-document: '404.html' 
        connection-string: ${{ secrets.CONNECTION_STRING }}
  • Last step is to set up that CONNECTION_STRING secret. This is the connection string to your Azure storage container. You can set the secret from your GitHub repository Settings tab, under Secrets.
    Click New Secret, then use the name CONNECTION_STRING and paste the access key value from your Azure storage account.

You’re all set up!
To test your publishing flow, all you need to do now is push a commit to your master branch, and see the GitHub action kick in and do its thing.
You should see your site appear in a few seconds. Sweet!

Update: recently I found out the workflow broke because of a bug in the latest version of the action. To bypass this I now fixed the version in my workflow YAML file to v1.0, which still works. It’s probably a good idea to avoid this kind of breaking changes by fixing the version of any action you use in your GitHub actions anyway. It will avoid those annoying issues where things work one day, and don’t the next.

programming guidelines, sort of

Years ago I ran into a website offering crude design advice. I thought it would be funny to make something similar for programming advice or guidelines. I started with a one-page website with a bunch of tips and then after a while forgot about it. Recently I ran into that project again and figured I might as well put it out here for the heck of it.

So here it is, some good fucking programming guidelines for you developers out there to have a laugh with, or perhaps even find a few useful tips and links in there. I swear, most of those tips are actually valid, even though they are presented in a tongue in cheek way.

So have fun with it. I know I did when I built the damn thing.