I’m a desktop minimalist myself and the trashcan is about all I want to see on my desktop. However if you like your desktop with lots of icons on it, arranged according to some non-alphabetical grouping system you might find out that Windows sometimes rearranges them nicely in alphabetical order, aligning them all nicely to the top left of your desktop without your prior consent.
This typically happens after reboots, switching between resolutions, plugging and unplugging a secondary screen or docking/un-docking the laptop.
It can drive people mad.
This seems to be an issue that has been plaguing Windows 8 and 10 for quite a while already, driving lot’s of people bonkers. Unfortunately when looking for a solution online in various fora you tend to find a lot of useless tips or the suggestion to install some third-party desktop icon position-saving software. Eew.
There is a simple solution in the Windows settings however, but I have to admit it’s not very obvious and I had to look for it quite a bit to find it.
It’s all in the settings as expected, but it’s spread out in two different spots, which makes it hard to get right.
Here’s how to fix it:
1. Right click on your desktop and disable the auto arrange feature by disabling the checkbox next in View > Auto arrange icons.
You’d think that should do the trick right? Well most people do. But there’s another option that interferes with your desktop icon zen garden staying the way you want it.
2. Right click again on your desktop, now click Personalize.
You’ll see the Settings screen appear.
There you select Themes. Now click Desktop icon settings.
Now look what we have there. A checkbox labeled “Allow themes to change desktop icons“.
Uncheck it and press OK.
You should now no longer experience the frustration of computer code messing with your desktop icons.
Build errors on build servers suck. If it builds locally, why the hell doesn’t it build on the build server? Well there’s plenty of reasons for that, but as a .NET developer is usually means that something you have on your machine that came with your Visual Studio install isn’t installed on the build server.
But you probably don’t want to install the full-blown VS on the build server, so the question now is: what bit do I need to install?
Recently I ran into the following build error on 1 specific build server (yep, not on another one, fun, fun, fun).
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(1111, 5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5.2" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
It clearly has something to do with a project which targets .NET framework v4.5.2.
The answer in fact is right there. You need to install a “targeting pack”.
But WTF is that thing and why do I need it?
Apparently having the .NET framework itself installed on your machine isn’t enough to be able to build a project if that project targets a specific version of the .NET framework. It makes sense as the .NET framework installation is actually the runtime, used to run .NET applications, not build them.
If you want to build apps against a specific version of the .NET framework, you need that targeting pack as well on your build machine. This is either your development box, which has VS on it, and thus the required targeting packs which come with the VS installation. Or this can be your build server, where you have to install the targeting packs as well.
You can check what targeting packs you already have on a machine by checking the sub-folders in “C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework”
For each supported framework version, there’s a v<version number> folder there. In my case there was no v4.5.2 folder on that one machine.
So where do you find those targeting packs for the various .NET framework versions? Microsoft luckily compiled a nice list where you can find all the download links and instructions.
For the versions listed as “included in VS 2017”, you can see them all listed in the VS 2017 installer if you go to the “Individual components” tab.
So a shortcut to install all the packs at once, is to grab the VS2017 installer and use that one. But you might want to disable all the IDE specific stuff you won’t need on the build server though.
Maybe you have some Azure credits lying from a Visual Studio subscription you have from work, waiting to be spent on cool and nifty experiments, but don’t end up actually using them.
How about spending some of those dollars on cancer research? Or help find a cure against Zika? Fighting AIDS maybe?
Enter the World Community Grid, a vast grid computing network running on the Open Source BOINC client software, started as a philanthropic initiative by IBM.
Sounds good right?
All you need to do is create a WCG account, spin up a Linux machine on Azure, install the BOINC headless client on it and link it to your account. In about half an hour you’ll be computing cancer markers, folding genes or fighting some horrible disease. Well, the software will be doing that really, which is even better.
Here we go, step by step.
1. Setup your Azure Linux machine, I chose an Ubuntu 16 LTS machine. I pick the classic VM because its way easier to setup.
Depending on the type of machine you’ll have more compute power and thus turning out more results. Try a few out and see how you can maximize your Azure credits.
2. Once provisioned, log in using PUTTY or your favorite SSH client. Now it’s time to update the Linux packages and then install the BOINC client:
3. Setup auto startup of the BOINC client, so if your machine reboots, you don’t have to go in and start it up yourself (automate all the things remember):
sudo /etc/init.d/boinc-client restart
4. Get your BOINC authentication key so you can hook up the client to your account:
Of course you want to check what’s going on, so you can check the BOINC client’s state like this:
boinccmd --get_state
This should give you a list of the tasks and their state. It might take a while before they start kicking in, but you’ll see results coming in after a day or so on the WGC website under your contribution history.
That’s about it. Your client is all set up. All you need to do is keep those VM’s running in the cloud, which normally takes non effort at all. Neat.
What’s next? Well, you can set up more than 1 machine if you like, or a heavier one and see what gives you more bang for your buck. You can also join my World Computing Grid team called “Team Azure” and see how many cloud bucks we can burn. It’ll be effortless fun, I promise! ;)
Vim plugins are written in viml or vimscript, an internal script language in the vim editor, and are plain .vim files containing scripting code which extend vim in all sorts of wonderful ways. There are tons of vim scripts out there so finding the right ones for your needs takes a bit of time. There are however some helpful guides out there and blog posts like this one to help you on your way. I’ll list some of those and links to more plugins at the end.
Installing those scripts and plugins can be tedious though. Download a zip, unpack, copy files, yada-yada-yada. Since we’re into package managers these days we want things to go automatically with a few keystrokes.
Enter Vundle.
You’ve probably guessed by now this is a vim plugin manager (and a plugin by itself). It allows you to install, update and search for available vim scripts among other things. I like this one in particular because it does this all from vim itself with a number of specific commands.
To get started you’ll have to install this one manually though, but it only takes a few command line statements and some .vimrc edits. Once you have this up and running, you’ll be able to install most plugins using it so it’s worth the hassle.
Alright. Now, what plugins should we get?
Well it depends on what you want to do of course, but here are some general purpose ones you might like.
vim-airline
A pretty looking status bar you’ll see in a lot of vim screenshots. It’s tweakable so you choose what kind of info you want it to show.
ervandew/supertab
Adds tab completion to vim using the tab-key. That might sound odd but the default use a bunch of control keys so this just comes more “natural”.
The-NERD-tree
This is a directory browsing plugin which is just better than Netrw which comes out of the box. Visually you can fold/unfold folders, search (use any vim command in the window), manipulate files etc. Very handy to keep track of a project when programming or just see what other files are in a folder without having to exit vim.
CtrlP
A fuzzy file search plugin. Press Ctrl-P and you’ll get list at the bottom of files in your current directory. Type in some characters of the filename you are looking for and it will filter the files matching those characters. So you don’t need to know the full name, and you can skip parts. Check out this video to get an idea of how it works.
One note on this. If you have a folder with a lot of files in the sub-folder tree (like a C# application with build files in the sub-folder) be sure to exclude any non relevant types like object & dll files. CtrlP has a maximum file limit and those irrelevant files can stop you from finding those you actually want to see.
In my _vimrc I use this to exclude the .NET build artifacts and some more irrelevant file types:
set wildignore+=*\\obj\\*,*\\bin\\*,*.swp,*.zip,*.exe,*.dll
vim-fontzoom
vim-fontzoom is a simple plugin that allows you to increase or decrease your vim font size using the plus or minus key when you are in command mode. Note that this doesn’t work with the +/- on your numeric pad, just with the regular keys on your keyboard. But you can remap the keys if you want to change this.
chriskempson/base16-vim themes
Not really a functional plugin but hey, you want your editor to look pretty right? I’ve tried a ton of themes already but lately I’m sticking with the chriskempson/base16-vim set. In this package you get a bunch of nicely crafted and balanced color themes which will definitely have something you like. Dark and light themes, monokai, solarized and other classics, it has it all. The last theme plugin you’ll ever need.
Moar!
Depending on you workload there are plenty of more specific plugins out there. Google is your friend, but here’s a few places to get started:
The easiest to use and most awesome Vim plugin directory is called VimAwesome. Great to find new plugins, or great to find old ones and how to install them. Each plugin lists how to install it with Vundle or another plugin manager, which is super handy.
Here’s another ReactJS.NET quirk I ran into lately. While working on an ASP.NET site using the ReactJS.NET Nuget package to render content using React.JS server side we got this error message on the web server after deployment:
Cannot load V8 interface assembly. Load failure information for ClearScriptV8-64.dll:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4e3fedda\f5d1e0ef\assembly\dl3\68f03368\00cf5237_117bd201\ClearScriptV8-64.dll: Could not load file or assembly 'file:///C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4e3fedda\f5d1e0ef\assembly\dl3\68f03368\00cf5237_117bd201\ClearScriptV8-64.dll' or one of its dependencies. The system cannot find the file specified.
The annoying bit here is that everything works fine locally, but not when it was deployed to the server using an Octopus package.
After debugging, searching online and going through the build log files I figured out that the problems could be caused by :
Missing DLL’s because of a missing Nuget package (quite obvious but not a problem in my case).
The VS 2013 C++ Redistributables are not installed on the server, which is a common cause for this error related to the ClearScript assemblies.
In my case the problem was a variation of the 1st problem. Once the web app was published, the DLL files where not in the expected bin\x64 & bin\x32 sub-folders, but in the root of the application’s bin folder. So the DLL’s where there, but not in the correct spot.
The cause of this problem is the _CopyWebApplicatonLegacy MS Build task which lives in the Microsoft.WebApplication.targets file.
This creates a _PublishedWebsites folder containing all the files you need to deploy to make your website run, yet it doesn’t trigger the build task used in the JavaScriptEngineSwitcher NuGet package which places those DLL’s in those x64 & x32 sub-folders. This special build task is included in the ReactJS.NET Nuget package, so you don’t have to do anything extra for this.
Because this task doesn’t get triggered in the step build to create the deployment package, the ClearScript-V8-64.dll, v8-x64.dll & ClearScript-V8-32.dll, v8-x32.dll don’t end up in their x64 & x32 sub-folders.
I fixed this by moving the files to their rightful location while creating the package for Octopus deploy with a PowerShell script. There’s probably a way to fix this with an extra build tasks too, but man, I spent so much time on finding this issue in the first place and I really didn’t feel like getting myself into that mess as well.
Getting a web page using PowerShell is pretty easy using Invoke-WebRequest. Getting a web page which is protected using basic authentication isn’t that much harder, but it took me a while to find out how to do that exactly as my initial searches didn’t turn up the right answers.
The trick is that you have to pass in a credential object when you make the call:
That $credential object is something you have to create. If you don’t pass in an object, you’ll get a prompt btw, which might also be handy.
Creating the object is done like this:
The PSCredential object is created and the username and a secure password string is passed into the constructor.
Putting the username and password in your script like this is a bad idea in a lot of cases, so you should really consider if this what you want to do. You can also use the Get-Credential cmdlet to ask the user for the username and password instead.
That way you keep this sensitive data out of your script and make it more resilient to change as well.
This is all it takes to ask for the credentials and set them into a variable you use later on:
