1
votes

I've been trying for days to migrate our backend solution running on Azure 2.6 and Azure Cloud Services to Azure 2.7 in VS2015 on Windows 10 workstation, but without any luck.

I've tried on multiple computers using a clean install of Windows 10 Pro x64 with Visual Studio 2015 Enterprise (all features installed). All updates available in both Windows Update and Vs2015 are installed. I create a new Cloud Service solution, with one Empty web role. I've set VS2015 to break on "Common Language Runtime Exceptions" (Debug -> Windows -> Exception Settings). I've run into the same errors on a separate machine running Win 8.1, VS2015, Azure 2.7.

The solution compiles fine but when I try to run/debug the Cloud Service project it throws the following error:

Exception thrown: 'System.Security.SecurityException' in mscorlib.dll

Additional information: Requested registry access is not allowed.

Starting only the WebRole without using the CloudService works.

When I try to run the CloudService through VS2015 with administrator priviliges the following exception is thrown:

'System.Threading.WaitHandleCannotBeOpenedException' in mscorlib.dll

Additional information: No handle of the given name exists.

Publishing the compiled solution to Azure yeilds the same exception when inspecting the intellisense logs ("Requested registry access is not allowed").

I've tried to add the install.cmd script from this blog post to install 4.5.2 or 4.6 on Azure Cloud Service when deploying but without any change in result: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-install-dotnet/

  • Are Cloud Services compatible with Azure 2.7? -- UPDATE: Yes. Make sure you use .Net framework v4.5.1

  • Is the install.cmd script really needed when running in local debug mode? Both 4.5.2 and 4.6 should already be installed, right?

  • Anyone else experiencing problems with this?

Any help or hints on how to get Cloud Services to work with Windows10, Vs2015 and Azure 2.7 are greatly appriciated!

Here is a repo with a sample project: https://www.dropbox.com/s/ie7jcn932nsddio/CloudServiceRepo.zip?dl=0

1
In the interest of narrowing down the cause of the problem, I have two virtually identical machines, except one has Windows 10 and the other has Windows 8.1. They both exhibit this problem. So, we can narrow this down to Azure SDK 2.7 / VS 2015 Enterprise.Whatever Man
I've tried on multiple machines now: Win10/VS2015/Azure2.7 / Win8.1/VS2015/Azure2.7 / Win8.1/VS2013/Azure2.7. They all experience the same problem.gussk
To clarify, the one machine I have that is working is Win8.1/VS2013/Azure2.6. So clearly the new SDK is the problem, regardless of OS or VS version. Right now, I am keeping a VM snapshot of my 2.6 machine around for when I need to make changes to the cloud service. It's a nightmare!Whatever Man

1 Answers

0
votes

If your underlying cause is the same as mine, I have a workaround (if not an actual cause and solution)

Add this under the runtime -> assemblyBinding section of the app.config for your worker role:

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.WindowsAzure.Diagnostics" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.7.0.0" newVersion="2.7.0.0" />
  </dependentAssembly>

Here's how I arrived at this. In VS2015 with SDK 2.7, I created a brand-new, empty cloud service. I pulled in my existing worker role, which was created with SDK 2.6 and upgraded to 2.7. This time, I got a new error complaining that it could not find Microsoft.WindowsAzure.Diagnostics version 2.6. In my worker role, my assembly reference is for version 2.7, not 2.6. So, something in the worker role (which I cannot find or understand) still wants version 2.6 of this assembly. Bad upgrade by the SDK? Dunno. Anyway, by adding this entry in the app.config, I force it to use version 2.7 instead.

I don't know why I get a different (and more accurate) error message when I create a new cloud service, versus using the old one. I also don't know what this has to do with the original "WaitHandle" error, but perhaps that was a red-herring, and the original problem has always been a version mismatch? I'd like to know what caused this problem and what the proper long-term solution is, but I'll settle for this workaround for now.

Good luck, I hope this works for you as it did for me.