Solving the dreaded MQ_ERROR_CORRUPTED_SECURITY_DATA (0xC00E0030) MSMQ error

I recently started getting a the error MQ_ERROR_CORRUPTED_SECURITY_DATA (0xC00E0030) when trying to execute tests on my development box while publishing to MSMQ queues. As indicated by the error, the cause was corrupted security data. I had recently changed my development machine from one directory over to another. Going into the MSMQ Server properties in compmgmt.msc (Computer Management) and clearing out all the certifticates for my user, renewing them and reregistering the certificates with Active Directory fixed the issue.

Switching environments, data sources, and other dynamically changeable settings in TFS Lab (on-premise) for 2013

Thanks to a post on this blog, we can access the settings inject into Lab-managed builds in TFS 2012 and 2013. Even though this is 2016 and many people are moving to the cloud with VSTS, there are still a good number of companies out there with considerable infrastructure "on-premise", and TFS can help with executing automated tests in those environments. I'm going to be building a library for helping others out with retrieving settings dynamically from TFS and I'll update my blog when it's available.

DevExpress and their licensing model suck for professional developers

If you're using a build machine, delete all of your *.licx files out of source control. Otherwise you're just asking for trouble.

Data-driven testing with MSTest via configuration-defined data sources and XML as a data source

I've done data driven testing with MSTest before. Prior to now, it's been solely with XML file data sources that have been defined inline in the [DataSource] attribute on my test.

I wanted to try using the app.config to define my data sources so that I could make them dynamic and configure them at test execution time so that I could point my tests at different environments.

I started following this tutorial on MSDN. It shows how to define data sources in the app.config for the tests. Then I followed the guidance in this post on the MSDN forums for how configure XML data sources in the app.config. Once I did that, I set up my XML data file similarly to the following:

<?xml version="1.0" encoding="utf-8" ?>
<Rows>
<dev>
<ShouldExist>True</ShouldExist>
<ProjectNumber>1721202</ProjectNumber>
</dev>
<dev>
<ShouldExist>False</ShouldExist>
<ProjectNumber>00000</ProjectNumber>
</dev>
</Rows>

The second-level "dev" elements are the "data table" in the connection parameters for the data source. By naming these appropriately, I can now select the environment in which to run my tests as part of my automated builds (yay ALM).

Solving "System.Net.WebException: The remote server returned an error: (417) Expectation Failed" with a WCF service

I recently started getting the following error message when trying to connect to a web service we had put on an Azure VM running behind an Azure load balancer:

System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (417) Expectation Failed. ---> System.Net.WebException: The remote server returned an error: (417) Expectation Failed.

It turns out the fix was to put the following element in my <configuration> :

<system.net>
<settings>
<!-- This is required when running in Azure VMs behind an Azure load balancer -->
<servicePointManager expect100Continue="true" />
</settings>
</system.net>

Solving "System.Net.WebException: The remote server returned an error: (417) Expectation Failed" with a WCF service

I recently started getting the following error message when trying to connect to a web service we had put on an Azure VM running behind an Azure load balancer:

System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (417) Expectation Failed. ---> System.Net.WebException: The remote server returned an error: (417) Expectation Failed.

It turns out the fix was to put the following element in my <configuration> :

<system.net>
<settings>
<!-- This is required when running in Azure VMs behind an Azure load balancer -->
<servicePointManager expect100Continue="true" />
</settings>
</system.net>

Solving the error "We could not add the account: network_not_available: The network is down so authentication cannot proceed" when trying to sign into Visual Studio

This has been driving me nuts for years. The solution, as it turns out, is ridiculously simple: at the top right of Visual Studio, go to your signed in account => Account Settings ...

On the dialog that pops up, sign out of all accounts and close the window.

While signed out, close and restart Visual Studio.

Sign in again with your accounts. You should be good to go.

Apparently signing out and closing Visual Studio is the only way to truly clear its credential caches. Fuck.

Solving the error "We could not add the account: network_not_available: The network is down so authentication cannot proceed" when trying to sign into Visual Studio

This has been driving me nuts for years. The solution, as it turns out, is ridiculously simple: at the top right of Visual Studio, go to your signed in account => Account Settings ...

On the dialog that pops up, sign out of all accounts and close the window.

While signed out, close and restart Visual Studio.

Sign in again with your accounts. You should be good to go.

Apparently signing out and closing Visual Studio is the only way to truly clear its credential caches. Fuck.

Solving the error "We could not add the account: network_not_available: The network is down so authentication cannot proceed" when trying to sign into Visual Studio

This has been driving me nuts for years. The solution, as it turns out, is ridiculously simple: at the top right of Visual Studio, go to your signed in account => Account Settings ...

On the dialog that pops up, sign out of all accounts and close the window.

While signed out, close and restart Visual Studio.

Sign in again with your accounts. You should be good to go.

Apparently signing out and closing Visual Studio is the only way to truly clear its credential caches. Fuck.