.NET Core And Why I Think it’s Huge!

Written by William Roush on April 18, 2016 at 10:20 pm

.NET Core is not just a large change for how you write code, but for the entire .NET ecosystem. I’m excited about this change from every front and I’m going to tell you why!

What is .NET Core?

.NET Core (previously known as .NET 5.0) is the new streamlined .NET platform by Microsoft. .NET Core takes a lot of lessons learned from pain points on the older .NET 1.0-4.6 platform and fixes a massive amount of it, giving .NET a new breath of life and hoping to make this platform beneficial for all. It appears to not only take lessons from what didn’t work on .NET’s platform, but what did work on other platforms.

What does that mean for developers?

Well here is the painful part: .NET Core is different, very different, for cross-platform support you’ll have to keep an eye out on what is .NET Core and what is .NET 4.5, thankfully Intellisense does a great job of letting you know that:

Watch out for missing implementations between frameworks.

Watch out for missing implementations between frameworks.

.NET Core is designed to rely on Nuget heavily though and have you pick and plug 3rd party libraries, designed around smaller assemblies to keep down on application size bloat and allowing you to pick and choose. This is seen with the new Entity Framework Core libraries and how they give you a small slice of functionality (data abstraction) and the individual engines are kept as separate libraries (which is common for ORMs on say, Node.js).

The shift into heavily using dependency injection as part of normal application process is wonderful for decoupling your code and having it easily testable, everything is right there ready to go from the start.

Configuration files being JSON is a huge step up, ASP.NET integrating Gulp as part of it’s build process for javascript libraries for both build and client side (they rely on Bower for client side scripts). The new project.json file allows for easy extension of your application’s behavior. If you’re used to .NET’s old way of doing things you’ll start with “This doesn’t work anymore? Ugh… how do you do that…. oh… that’s much better!”

What does that mean for platform support?

.Net Core Builds

It means that we’re seeing .NET on more platforms that we’re used to as a first class citizen from Microsoft, this means huge things (I’ll touch on those later) for the popularity of .NET. Microsoft has even been quoted saying this:

When used third-party tools such as Xamarin, .NET Core should be portable to IOS and Android devices.

And with Microsoft’s recent acquirement of Xamarin and pushing it as free, we’re probably going to see .NET Core as a solid mobile platform in the near future.

What does this mean for the .NET Community?

A new .NET developer said this to me recently:

Not much of a supportive community around .NET, at least nothing like other languages I have learned.

And I can’t help but agree, while I appreciate our local .NET Users Group here in Chattanooga (which has been pretty quiet for awhile), I find the subjects of our local Developers Group more interesting. While .NET generally gets paid decently and seems to be in a decent amount of demand here, it seems to be more of the slower older corporate companies that are hiring and less smaller agile companies.

I think getting .NET on Linux platforms and putting out solid community editions of Visual Studio may breathe new life into the community. Bringing fresh young blood, new ideas and more open source software, maybe we’ll go back to solving hard problems too. It’s a huge weak spot in .NET and really hurts adoption, which I think really hurts the available libraries and third party tools (while Microsoft provides some good tools, it still lacks heavily on 3rd party tooling that isn’t just babysitting people who can’t write basic menus… where is my Code Climate for .NET?!).

I’ve been wanting to write an article on the abysmal state of the .NET community, it’s developers, the skill sets of a lot of them and what kind of code they churn out, this is an excellent opportunity to do so.

What does this mean for businesses?

Well if you’re a startup, maybe in a few years .NET on Linux will be a hot thing. C# 6.0 is a wonderful language and with every iteration it gets more powerful (usually stealing from F#). Getting MSSQL on Linux seems to be the first in many steps for Microsoft to not just push it’s operating system by locking it’s solutions onto it, but push solutions that you’d be happy to pay for due to their ease of use or specific desired features (which sometimes for some companies may be completely worth it).

If you’ve been knee-deep in .NET for years it can mean a few things: .NET Core’s performance is insane, which can mean a reduction in required resources for your applications. The build process is a lot easier to keep consistent and extend so less work to automate it. Applications being shipped with their runtimes means less effort determine what runtimes are installed and handling them. It is however a large shift and I would suggest that a lot of .NET developers aren’t ready for all this change (more on the community later…).

Of course you can completely ignore it and mostly not deal with it for awhile, .NET 4.5 isn’t going away anytime soon.


I’m excited to no end about this, first was the fixing of all the problems we’ve had, but secondly because this may really help the .NET community flourish. Fun new times in the land of .NET.

Backing Up Snapshots For VMware

Written by William Roush on April 17, 2016 at 8:01 pm

Sometimes backing up snapshots is useful, lots of applications don’t do it out of the box… so how are we going to accomplish this?

Why Backup Snapshots?

While everyone would jump on board the “snapshots aren’t backup” train (which I’m a proud member of) there are reasons you may want to backup snapshots. One of the biggest reasons I would is that certain tools like TeamCity can leverage snapshots as checkpoints to boot up your build agents from, and when you go to restore your virtual machines it would be nice to not have to recreate snapshots.

I’m sure there are many other perfectly valid reasons to need long-lived snapshots (especially on non-production development/testing machines), so why not support that recovery mode?

The Problem

As far as I’ve seen, all backup software squashes your snapshots, restoring a virtual machine results in you having a single state, all snapshots are erased. Ouch! We’ll need to get clever.

Doing It With Veeam

This isn’t the best way to do this, but so far it seems to be the easiest. File copy jobs. We want the entire state of the virtual machine, all of it’s files, it’s snapshot descriptor files, everything. Now there are a few downsides to this:

  • Your backups will be larger – Veeam only backs up the current state, we will be backing up all states. You need to store all the snapshot deltas and any memory snapshots.
  • File lock issues – We’ll need to resolve issues with backing up a powered-on virtual machine
  • Storage – We don’t get clean vbk files, we’ll have full copies of whatever exists on the datastore
  • Versioning – If we want to keep multiple copies over time, we’ll probably want to automate versioning our backup folders folders.
  • Tape – We lose some visibility pushing backup files to tape instead of the vbks (though this only applies to higher licensing tiers that can leverage that).

Doing it With Powered Off Virtual Machines

Easy enough, we want to pick the folder that the virtual machine is in on the datastore, and back it up. Everything should go smoothly and file locks shouldn’t bite us.

Doing it With Powered On Virtual Machines

This becomes extremely tricky, you need to back up only the unlocked files, this also means that the current state will be trashed (if this isn’t OK, we can automate a NEW snap prior to the job running and commit it on completion). Here are a list of what I’m backing up to test this:

  • [VM]-000001.vmdk – Our VMDK for our current state (this is bad due to locked file)
  • [VM]-aux.xml
  • [VM].vmx – Virtual machine configuration file
  • [VM]-ctk.vmdk
  • [VM]-Snapshot15.vmsn
  • [VM]-000001-ctk.vmdk
  • [VM].vmdk – Our base VMDK metadata, our snapshot
  • [VM].vmsd
  • [VM].nvram
  • [VM]-flat.vmdk – Our base VMDK with our data on it, our snapshot

These files were locked:

  • [VM]-000001-delta.vmdk – Our delta file for our current state (after our snap)
  • [VM]*.lck – Anything with a “lck” extension appeared locked.

When restoring the file we’ll create an invalid delta file to put things into a somewhat OK state, SSH into you hypervisor, navigate to your virtual machine’s directory and type this (replace “00001” with the number of the delta you’re missing):

touch  [VM]-000001-delta.vmdk

This will create an empty VMDK delta file, it’s invalid and your machine will not boot, but from this stage you can revert back to the last snapshot, setting everything in a correct state.

The easiest way to do this would be just to add all files to the file copy job, and let those that are locked fail, a script will handle this best being as Veeam’s UI will not let you multi-select files, and selecting the folder results in a failure of the entire backup on the first locked file.

You miss out on a lot of nice to haves, restoring this involves copying the files back to the datastore (can be done with a file copy job in the reverse direction) and adding the machine to your inventory manually, but you cannot restore to a newly named virtual machine, you’ll have to restore as-is and rename after it’s done. Be aware too: transfer speeds seemed to suffer a lot for this kind of backup setup.

Additionally this has worked under lab conditions, so please, as with any backup test it first! Let me know if it works for you.


If there is enough interest maybe I’ll write up some PowerShell scripts to automate some of the more tricky stuff and post it.

RhodeCode 3 Enterprise – Self-Hosted Source Code Repository Review

Written by William Roush on April 13, 2016 at 3:07 pm

Review from long-term end-user and administrator of multiple RhodeCode installs since version 1.x.

Disclaimer: I’ve been a long time fan of RhodeCode and have talked with Marcin Kuzminski (main developer) multiple times.

RhodeCode 3 Enterprise


First problem I ran into was not getting the validation e-mail, seemed to hard bounce off my anti-spam, ouch, a password reset link made it through though and I got my download. You’ll have to have Python installed first, additionally do NOT rename the file, the installer will get crabby (which wget gladly renames it due to redirects all over by the RhodeCode site):



After that you just follow the quick start docs.

Installer enforces that you run it as a non-privileged user (good) doesn’t check for dependencies (bad), so on a clean net install of Debian 8 will crash if it’s missing: sudo and lbzip2, only way you can tell this is if you read the error logs, you’ll also get a totally unhelpful “file not found” when the service user’s home directory is missing/or not writable (Marcin says they’re fixing this though).

After that you’ll install your RhodeCode VCSServer and Enterprise components, these went pretty painlessly with additional packages downloaded from RhodeCode’s servers.


RhodeCode has free licensing for up to 25 users (prior this was 20), after that you need to pay up. Currently the price for <100 users seems to fluctuate around $5/seat/person, which isn’t too bad (better than Github, worse than Bitbucket).

I’ve been keeping an eye on their pricing model for awhile, they’ve had anything from $13/user/platform (svg, hg, git) which was pretty rough, to the ability to not pay for support (only updates) which was like $2/user/mo, but they dropped that option sadly. I think the ~$5/user/mo is a good compromise even if it’s more expensive than some cloud providers.

For less than 25 users they also offer support for pretty low per seat pricing currently, a cool option, though I’m kind of always of the opinion if you need lots of support and can’t be self-sufficient outside of reporting bugs: go cloud.



RhodeCode pretty much covers all the bases and includes the following:

  • External authentication (LDAP, Crowd, etc.)
  • Repository groups
  • Gists (public, private, expiration, all the good parts)
  • Code review (via pull requests)
  • Forking
  • Server-managed merging (like GitHub’s auto-merge)
  • Repository statistics

User Experience

A clean look for 3.0

A clean look for 3.0

The whole user interface has been cleaned up with a much sharper look, though a lot of the options are still in the same place they’ve always been (good for old RhodeCode users/admins, though some workflows had pain points).

Everybody gets lots of white space

Everybody gets lots of white space

A lot of white space seems to have been added though, feels like a lot of screen real estate is wasted. This is really obvious between various sections of the site.

The old statistics we're used to

The old statistics we’re used to

Nothing really new from the statistics features from the older versions, they’re nice to have but nothing much that is useful.

A bunch of commits

A bunch of commits

Commits are easy to read.

A terribly formatted readme file

A terribly formatted readme file

White space issues plague the ReadMe file, taking most of the screen with text much smaller than how it looks on GitHub.

RhodeCode - Unified Diff

RhodeCode - Side by Side

RhodeCode has support for inline and side-by-side diffs when reviewing code, pretty slick layouts that I enjoy.

This... is a journal page.

This… is a journal page.

Journal layout leaves a lot to be desired — but at least they have RSS feeds.

RhodeCode - Review Comment

RhodeCode still kind of suffers (in my opinion) from code reviews being nothing more than pull requests, which without and workflow management leaves a lot for anyone that needs more than the absolute basics for code review.


Everything is much faster than it was, however I’m only able to test it at a somewhat smaller scale than the deployments I’m having trouble scaling on.

As I understand it one of the largest changes for 3.0 was to break everything out and improve the speed of everything, that seems to have done the trick.

However things like statistics still seemed to take an awfully long time to run, not sure if it’s low-effort or

Repository Management

The tools for managing repositories haven’t changed really outside of just somewhat cleaner layouts. You still struggle from the fact that forks will likely clutter up your system, though the addition of “personal groups” somewhat helps, with this you can attempt to mimic a GitHub-like structure.


The system runs better and is visually more appealing than it was before, and I’m glad licensing has seemed to mellow out at a much more reasonable rate than it was earlier in the RhodeCode 3.0 releases. As much as I loved Gogs, I really need Mercurial support and RhodeCode really hits that sweet spot well.

The only downside is that it’s really hard to compete with the likes of super-cheap cloud providers like BitBucket, though it beats the pants off of Github’s Enterprise pricing (and under some conditions, their cloud… if you can’t fit everything under a smaller organization setup).

Exchange IMAP Over SSL Not Working

Written by William Roush on April 13, 2016 at 2:52 pm

Getting any of the following messages?

openssl s_client -connect [server]:993 -crlf
62604:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/ssl/s23_lib.c:185:

openssl s_client -connect [server:993 -crlf

While attempting to fix IMAP login issues for JIRA’s service desk e-mail to ticket integration, I came across this on my Exchange server:

Get-ServerComponentState -Identity [servername]

Server Component State
------ --------- -----
[Servername].domain.local ImapProxy Inactive

Solution was simple: enable the ImapProxy:

Set-ServerComponentState -Identity [servername] -Component ImapProxy -Requester HealthApi -State Active