Project count and name length limitations of the Service Fabric tooling in Visual Studio

It would seem that I've just stumbled across the practical technical limit to how many services a Service Fabric application can have and still be debugged with Visual Studio: ~ 37. My problem would seem to be confirmed by this Github issue.

Solving "The storage account named XXXXX already exists under the subscription" when deploying Azure Resource Group templates

I've recently run into a problem where I've been unable to deploy multiple resource groups for my applications that contain Storage Accounts. When executing the Resource Group template deployment, I get the following error:

"The storage account named XXXXX already exists under the subscription"

The underlaying cause seems to be that Microsoft fucked up backward compatibility on their API in resource group templates. Thanks to this blog post, I was able to get back up and running. The gist of the article, repeated here for posterity, is that you have to update to the latest (as of this writing) API version of 2016-01-01. For example:

{

    “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,

    “contentVersion”: “1.0.0.0”,

    “resources”: [

      {

        “name”: “dnntest20160705”,

        “type”: “Microsoft.Storage/storageAccounts”,

        “location”: “[resourceGroup().location]”,

        “apiVersion”: “2016-01-01”,

        “dependsOn”: [ ],

        “tags”: {

          “displayName”: “MyStorageAccount”

        },

        “sku”: {

          “name”: “Standard_LRS”

        },

        “kind”: “Storage”

      }

    ]

}

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.

WADK Deployment Tools on Windows Server 2008 giving error "The program can't start because api-ms-win-downlevel-advapi32-l4-1-0.dll is missing from your system"

Got this error at an extremely inconvenient time when trying to write some automation scripts for Windows Optional Features using the DISM module as part of the Windows Assessment and Deployment Kit running on Windows Server 2008 R2: "The program can't start because api-ms-win-downlevel-advapi32-l4-1-0.dll is missing from your system"

It turns out that the installer for this particular product isn't reliable when you uninstall and then reinstall the ADK. The problem turned out to be that the PATH variable hadn't been updated on the second install, so the PowerShell module that was invoking the DISM.exe executable wasn't able to find the required DLLs, even though they were in the same path as the executable. Go figure.

MSDeploy: The underlying connection was closed: An unexpected error occurred on a send.

Our company has started deploying all of its numerous web applications via automated (or at least scripted) deployment with MSDeploy. This has worked fine, up until very recently where one machine in particular seemed to be cursed and simply didn't want to work. Even when we nuked the VM and completely recommissioned it from scratch from our VM web server template, we still kept getting the following error:

Error: Could not complete the request to remote agent URL 'https://myserver:10987/MSDeployAgentService'.
Error: The underlying connection was closed: An unexpected error occurred on a send.
Error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Error: An existing connection was forcibly closed by the remote host
Error count: 1.

The problem turned out to be caused by the fact that we hadn't correctly configured the Management Service for MSDeploy (even though we use a custom port for the MsDepSvc deployment service, the Web Management Service (WMSvc) wasn't correctly configured): 

1. Because we were behind a load balancer, we needed to specifically set the IP address of the server
2. We were attempting to use SSL, but we didn't have a certificate specified in the Management Service configuration.

Here's what our configuration looked like in the end, obfuscated to protect the guilty:

Step 1:

Step 2:

Resolving "The agent process was stopped while the test was running" on a TFS build agent

I'm currently working on a project that uses TFS for automated builds. Recently, our builds started failing with the error "The agent process was stopped while the test was running" while running unit tests. It wouldn't always happen during the same test, though it did frequently.

After inspecting the Event Viewer on the build machines, we found an error in the .NET Runtime that was taking down the build agent:

Application: QTAgent32_40.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: Moq.MockException

Stack:

   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__5(System.Object)

   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)

   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

The exception that was being thrown on a ThreadPoolThread (always extremely bad, never good) was a MockException: our unit testing framework was throwing an exception that was taking down the build agent.  But where?

How We Solved It

By some miracle, one of our developers decided to run our problematic tests with mstest on the command line on his local machine. As it turns out, this was great because it showed the stack traces for the loose threads on the command line. Turns out we had a lot more loose threads than just the one that was taking down our test agent on the build machine. The command the developer used was (similar to) the following:

mstest.exe /testcontainer:"C:\path\to\my\test.dll" /noisolation

After auditing all of the errors by rooting them out with command line runs of mstest, the solutions to our problems all boiled down to one thing:

*ALWAYS* wrap the contents of 'async void' methods with a try-catch block!

Resolving ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection refused

There are a number of reasons why an SSH server may fail to allow a client to connect. Many aren't readily apparent, even from tailing system log files or using ssh -v on the client. Here are some of the ones I've encountered:

1. Incorrect permissions / ownership on the key files in /etc/ssh/
2. Incorrect permissions / ownership on the ~/.ssh/id_rsa private key file of the user as which we're trying to connect. I'll add more to this list as I encounter them.
3. systemd just plain being a piece of shit. Running 'systemctl restart sshd.socket' has fixed the problem in the past.

Undefined reference to `log' when compiling on Ubuntu 13.10 with gcc

After I upgraded to Ubuntu 13.10, I inexplicably started getting errors in a build that had been perfect for a very long time. It turned out, there was a significant change in the linker and a bug introduced. The fix is described beautifully on this blog post, but for convenience sake:

Add '-Wl,--no-as-needed' to your LDFLAGS

Journey to robust windows services: Service could not be installed. Verify that you have sufficient privileges to install system services

This is an annoying and almost entirely useless error. It can be caused by any number of things. However, in my case today, it was caused by the fact that the EventLog Source hadn't been created when I tried to install my Windows Service using the WiX installer that I had developed (which it turned out wasn't quite complete). Fortunately, WiX (at least as of 3.5) has built-in support for creating Windows Event Log sources as part of the installation process. Fortunately, I was able to rely on this article on stackoverflow.com to guide me through the process. The gist of the article:

1. Add the "http://schemas.microsoft.com/wix/UtilExtension" namespace to your .wxs file root XML element
2. Add a util:EventSource Log="Application" Name="MyServiceLogSourceName" EventMessageFile="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll" element to each component which requires an Event Log source
3. Problem solved