After we upgraded to Azure SDK 1.5, one of our developers (Mike) had a problem. When he would try to run his Azure web role in the development fabric, it would sit there packaging up the deployment for an extraordinarily long time, and then give a popup message saying “Unable to connect to dfService”.
After some googling, and then bugging Neil McKenzie (Microsoft MVP in Azure, whose book you should definitely check out), it turned out that it was because the username he used to log onto his computer had a space in it.
At this point, Mike had two choices. He could create a new profile without a space in the username and try to move everything over to it — you can do this by copying the old profile to the new. But he didn’t want to change his username. So he took the second option and followed the instructions in this MSDN article to set up an environment variable called _CSRUN_STATE_DIRECTORY to a path that didn’t have any spaces.
I know a lot of people have hit this problem, so I was wondering if they fixed this bug with the new SDK/Tools 1.6 that came out recently. I have a VHD that I use for maintaining our Office Add-ins – it has Windows 7, Visual Studio 2010, and Office 2007 installed in it. It hasn’t been updated for about three months, but I figured I could install Windows Updates and upgrade it to SDK 1.5/Tools 1.4 and see if I could reproduce the error.
It turns out the dang VHD didn’t have Azure tools installed at all. This means it also didn’t have SQLServer or IIS or the MVC tools upgrade, let alone about 50 Windows Updates.
After spending the morning (seriously, it took about 4 hours) updating and installing, I finally got to the point where I had Azure Tools 1.4 and Azure SDK 1.5 installed. I set up a new user profile with a space in it, and reproduced the problem. I also added the Environment variable and verified that it fixed the problem, and removed it and verified that the problem occurred again. I wanted to make sure all of the possibilities were covered, this was actually the exact problem we had seen, and that the problem was occurring again after removing the eivnronment variable so I could verify for sure that installing SDK 1.6 fixed it (or not).
Next I went out and tracked down the 1.6 tools. The main install page is here. You can use the Web Platform Installer, but I wanted to install the components manually. There is a link to the manual instructions on that page, and they are here.
I downloaded the 64-bit versions of everything. Since I’d already been through this, IIS and MVC, etc., were already installed and up-to-date; I only had to install the Azure components.
Interestingly enough, they have now split this into four bits, installable in this order:
- Windows Azure Authoring Tools – November 2011 (this is the SDK)
- Windows Azure Emulator – November 2011
- Windows Azure Libs for .NET – November 2011
- Windows Azure Tools – November 2011.
So I installed them, one by one, in the recommended order. (Do you think they split them up into separate bits so they can release just the changes to each bit in the future? I would think this also allows them to release changes to one bit at a time, which could allow them more flexiblity in their releases, because they can release fixes or updates to one instead of having to wait until they have enough to make a full release. I don’t work for Microsoft, so I don’t know for sure, that that’s my theory.)
On the original information page for the SDK, it said I should read about Known Issues in Windows Azure before installing. Like most developers, I chose to read that AFTER installing everything instead of before. (Come on, admit it, you do that too.)
That’s a very nice web page, with documentation of problems found in each version of the SDK/Tools, such as the problem with the IIS logs in 1.3 and 1.4, and the problem with the Dev Fabric starting up in 1.5. And yes, there’s one entry for 1.6. Turns out there’s a problem with one of the dll’s getting installed correctly in the GAC. The instructions say to do this:
- Open the Control Panel.
- Right-click Windows Azure Emulators – November 2011.
- Click Change.
- Follow the steps in the wizard to reinstall the compute emulator.
Well, this didn’t work for me. It asked for the location of an msi under my profile that I didn’t have. This might be because I didn’t use the Web Installer, I don’t know. But I re-ran the msi for the Windows Azure Emulator and did a Repair, and then ran the gacutil command listed in the article, and the dll is there.
I didn’t run the gacutil command beforehand, so I don’t know if the dll was there before and this upgraded it, or if it added the dll, or if it was there before and it didn’t upgrade it and I have a false sense of security, but I’m going with it until I have a problem.
It took me so long to get everything installed, I almost forgot what the point was. In case you’ve forgotten, the point was to see if having spaces in your profile still prevented the compute emulator from starting up. So I started up Visual Studio and tried running my WCF service in the development fabric on the account with spaces in it. And it worked. So the answer is yes, they fixed it.
Also, they corrected the spelling of “remaping” to “remapping” – this shows up in the output window in Visual Studio when you run your Azure application and it remaps ports. Sure, this doesn’t keep anything from working, but it’s nice to see they fixed that too.