Windows Azure project errors The CctSharedPackage did not load correctly - visual-studio-2012

I opened a solution file that was working fine and got this mysterious error
The 'CctSharedPackage' did not load correctly
This project was a Windows Azure 2.1 project that had no issues working last week, however between then and a reboot it would not successfully load in Visual Studio 2012 any longer. This occurred on a machine that does have Windows Azure SDK 2.1 installed (the project did work fine last week)
The error stated to check the c:\Users\{user}\AppData\Roaming\Microsoft\VisualStudio\11.0\ActivityLog.xml file for more information.
In this file it stated "Could not find assembly Microsoft.Azure.Diagnostics ver 2.1".

Seeing as Windows Azure SDK 2.1 was already installed, i redownloaded the installer and went to run it to ask it to reinstall or repair the installation. Seeing as the install is the Web Platform Installer, it provided none of those options. At this point I decided that I must uninstall the SDK to be able to reinstall it from Add/Remove Programs.
When I went to Add/Remove Programs I saw that there were installations there for Windows Azure Libraries for .NET - v1.8 and Windows Azure Authoring Tools - v1.8. I removed both of these installations and then the project was able to load successfully.

this seems to be a problem with the installer. Re-installing is an option, but you can fix it with a simple command line by registering your assemblies in the GAC.
C:\Program Files (x86)\Windows Azure Tools\Visual Studio 11.0>gacutil /i .\Microsoft.VisualStudio.WindowsAzure.Diagnostics.dll

I don't have the 1.8 SDK installed. I believe it was a windows update relating to .Net 3.5 which might have broken my installation. To Fix all I did was open up Explorer in Windows 8 and select the 'Uninstall or Change a program' option from the ribbon.
Search for Azure and when there was an option to 'repair' I repaired the program. FIXED

I ran into similar problem (The 'CctSharedPackage' did not load correctly). In my case starting Visual Studio with Run as administrator solved the issue.

I also encountered this prolem today, but for me luckily it was solved just by restarting Visual Studio 2012. Just try it at least once to be sure :-) !

I was having this same problem. Reinstalling SDKs didn't seem to be helping and reinstalling Visual Studio sounded too painful so I decided to figure out what was causing the error.
I used another instance of Visual Studio and attached it to debug the offending Visual Studio instance. I couldn't see where the exact error was happening, but I was able to see what library the exception occured in and could see the source code using .NET Reflector to get an idea of what it does.
On startup the Microsoft.Cct.CctSharedPackage library iterates through all the Azure SDKs to figure out which ones are installed on your computer.
I ended up writing a console application to emulate what the startup does and see if I could find what was wrong. All the classes are internal so I had to use reflection to access them.
On my computer it turned out to be the Azure SDK 1.6 that was messed up. The SDK was installed, but the TargetAzureLibraries property was coming back as null. I uninstalled that SDK and it corrected the problem.
Console app below:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WindowWidth = 240;
// The Microsft.Cct.AssemblyResolver does this:
/*
private IEnumerable<IAzureToolsVersionInfo> GetInstalledSDKsByProductVersionDesc(IServiceProvider serviceProvider) =>
(from knownProduct in AzureToolsVersionInfoUtilities.GetAllProducts()
where knownProduct.TargetAzureSDK.IsSDKInstalled() && knownProduct.TargetAzureLibraries.IsLibrariesInstalled()
orderby knownProduct.ProductVersion descending
select knownProduct)
*/
// Duplicate this logic using reflection to find the SDK install that is broken.
var asm = System.Reflection.Assembly.LoadFile("C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\Extensions\\Microsoft\\Windows Azure Tools\\Microsoft.VisualStudio.WindowsAzure.Common.2.8.dll");
var typ = asm.GetType("Microsoft.Cct.ProductVersionInfo.AzureToolsVersionInfoConstants");
//Console.WriteLine(typ.ToString());
var allMethods = typ.GetFields(BindingFlags.Static | BindingFlags.Public).Select(it => it.Name).ToArray();
allMethods = allMethods.Where(it => it.StartsWith("WAT") && it.Length == 5).OrderBy(it => it).ToArray();
foreach (string version in allMethods)
{
var fld = typ.GetField(version, System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.Public);
dynamic val = fld.GetValue(null);
var azTypeInfo = asm.GetType("Microsoft.Cct.ProductVersionInfo.AzureToolsVersionInfo");
bool isSdkInstalled = false;
bool isLibrariesInstalled = false;
Dictionary<string, string> sdkProperties = new Dictionary<string, string>();
Dictionary<string, string> libProperties = new Dictionary<string, string>();
// Get the SDK reference
var targetAzureSDK = azTypeInfo.GetProperty("TargetAzureSDK").GetValue(val);
Type targetAzureSDKProp = targetAzureSDK.GetType();
var methodNames = targetAzureSDKProp.GetMethods().Select(it => it.Name).ToArray();
var sdkIsInstalledMethod = targetAzureSDKProp.GetMethods().FirstOrDefault(it => it.Name == "IsSDKInstalled");
isSdkInstalled = (bool)sdkIsInstalledMethod.Invoke(targetAzureSDK, null);
var sdkProps = targetAzureSDKProp.GetProperties().ToArray();
foreach (var prop in sdkProps)
{
try
{
sdkProperties[prop.Name] = string.Concat(prop.GetValue(targetAzureSDK));
}
catch (Exception ex)
{
sdkProperties[prop.Name] = "Error:" + ex.Message;
}
}
if (isSdkInstalled)
{
// Get the Azure libraries reference
var targetAzureLibraries = azTypeInfo.GetProperty("TargetAzureLibraries").GetValue(val);
Type targetAzureLibrariesProp = targetAzureLibraries.GetType();
var isInstalledMethod = targetAzureLibrariesProp.GetMethods().FirstOrDefault(it => it.Name == "IsLibrariesInstalled");
isLibrariesInstalled = (bool)isInstalledMethod.Invoke(targetAzureLibraries, null);
var props = targetAzureLibrariesProp.GetProperties().ToArray();
foreach (var prop in props)
{
try
{
libProperties[prop.Name] = string.Concat(prop.GetValue(targetAzureLibraries));
}
catch (Exception ex)
{
libProperties[prop.Name] = "Error:" + ex.Message;
}
}
}
// Output details of this SDK
Console.WriteLine("{0}, {1}, {2}", version, isSdkInstalled, isLibrariesInstalled);
Console.WriteLine("\tSDK");
foreach (var kp in sdkProperties)
{
Console.WriteLine("\t{0} {1}", kp.Key, kp.Value);
}
Console.WriteLine("\tLib");
foreach (var kp in libProperties)
{
Console.WriteLine("\t{0} {1}", kp.Key, kp.Value);
}
}
}
}
}

Uninstalled all Windows Azure entries ending with October 2012 via control panel. After reopening my solution I got a dialog to convert the project target (screenshot).

I second the turn it off then on again option. Got this error on loading a project after a week away. Rebooted and it went away. So try that at least once.

Related

Excel to DataSet using OLEDB working differently between .NET Core and .NET Framework

I have a worker service that references a .NET Framework class library. The class library contains a method to convert Excel to a dataset.
While debugging on Visual Studio, everything works as expected, but after publishing I get the error message:
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
To debug, I built the below two console apps with exactly the same codeā€”one in .NET Core, the other .NET Framework. I then run the projects on two computers.
Computer A: Microsoft Office Tools installed, but no AccessDatabaseEngine.exe
Computer B: No Microsoft Office Tools, AccessDatabaseEngine installed
using System;
using System.Data;
using System.Data.OleDb;
using System.Text;
namespace ToDataSheetCore
{
class Program
{
static void Main(string[] args)
{
DataSet dt2 = ExcelToDataSetCommon("C:\\pathToExcel\\excelFile - AUGUST 04 2021.xlsx");
StringBuilder sb2 = new StringBuilder();
foreach (DataTable table in dt2.Tables)
{
foreach (DataRow row in table.Rows)
{
sb2.Append(string.Join(" ", row.ItemArray));
sb2.AppendLine();
}
}
Console.WriteLine(sb2);
Console.ReadLine();
}
public static DataSet ExcelToDataSetCommon(string SourceFilename)
{
DataSet ds = new DataSet();
try
{
string connStr = string.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties=\"Excel 12.0;HDR=YES;\"", SourceFilename);
OleDbConnection conn = new OleDbConnection(connStr);
conn.Open();
DataTable schemaDT = conn.GetSchema("Tables", new string[] { null, null, null, "TABLE" });
conn.Close();
string tableName = schemaDT.Rows[0]["TABLE_NAME"].ToString();
OleDbCommand cmd = new OleDbCommand(string.Format("SELECT * FROM [{0}]", tableName), conn);
OleDbDataAdapter adapter = new OleDbDataAdapter(cmd);
adapter.Fill(ds);
}
catch (Exception ex)
{
Console.Error.WriteLine(ex.Message);
}
return ds;
}
}
}
Result
Computer A
.NET Core
Debug mode
Prints excel content to console
Publish mode - self-contained(win64, anypc)
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
.NET Framework
Debug mode
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
Publish mode - self-contained
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
Computer B
.NET Core
Debug mode
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
Publish mode - self-contained(win64, anypc)
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
.NET Framework
Debug mode
Prints excel content to console (Fails on uninstalling AccessDatabaseEngine)
Publish mode - self-contained
Prints excel content to console (Fails on uninstalling AccessDatabaseEngine)
I understand installing AccessDatabaseEngine provider has an effect, but I don't understand the different results from .NET Framework and .NET Core.
Though I have resorted to using ExcelDataReader since I want to avoid external dependencies.
I am confused by the difference in the results using OleDB API between .NET Core and .NET Framework. Is there a way the AccessDatabaseEngine provider can be published together with a .NET project?

Cannot find annotations System.ComponentModel.Annotations in Azure Function

I have a simple Azure function that just needs to deserialize some json into an object that has annotations
I get the error
'System.ComponentModel.Annotations, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
How can I fix this? This is .NET Core 3.1 using v3 of Azure Functions
I am using a new project template so this is Azure Functions
Im not sure how to implement fixes that involve hacking around with assembly binding redirects given that this is an Azure Function, which has appsettings.json file not support for .config
I have 3 ways for this.,
WAY -1
This is an issue with out of process functions with .NET 5. So, you can either upgrade your project from .NET Core 3.1 to .NET 5.0 or downgrade all dependent packages to 3.1.
you can find more on that here
WAY-2
If this doesn't work try running this in your azure functions . It will redirect any assembly to an existing version.
public class FunctionsAssemblyResolver
{
public static void RedirectAssembly()
{
var list = AppDomain.CurrentDomain.GetAssemblies().OrderByDescending(a => a.FullName).Select(a => a.FullName).ToList();
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
}
private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
var requestedAssembly = new AssemblyName(args.Name);
Assembly assembly = null;
AppDomain.CurrentDomain.AssemblyResolve -= CurrentDomain_AssemblyResolve;
try
{
assembly = Assembly.Load(requestedAssembly.Name);
}
catch (Exception ex)
{
}
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
return assembly;
}
}
WAY-3
Try adding the following code to the .csproj file of your project:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
This forces the build process to create a .dll.config file in the output directory with the needed binding redirects.
You can find more information in the SO Threads Thread1 , Thread2 which discusses on similar related issue.

Azure function: Could not load file or assembly Microsoft.IdentityModel.Tokens, Version=5.2.1.0

Im writing an azure function to generate a JWT token and return it to the client. The code is tested locally in a console app and all seems to work fine. This is the package reference included in the working console app, and in my functions app:
<PackageReference Include="System.IdentityModel.Tokens.Jwt" Version="5.2.1" />
When running the function host locally with func host start and executing the code it results in the error:
Could not load file or assembly 'Microsoft.IdentityModel.Tokens, Version=5.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'."
I don't understand why this is happening, the dll is laying in the output folder along with my application dll. The only other thing I can think of is that the function host has its own set of packages that it sources from and this one is not available yet, having been only released 12 days ago.
I'm not sure. Any help on why this is happening or how to get around it?
Details:
Azure Functions Core Tools (2.0.1-beta.22)
Function Runtime Version: 2.0.11415.0
I got this issue and it seems to be related to some kind of bug in the Azure function SDK. the fix was to add:
<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
to your csproj file. As documented here
I had installed this package Microsoft.AspNetCore.Authentication.JwtBearer
And for me, the issue was resolved.
You can uninstall System.IdentityModel.Tokens.Jwt
Because the Microsoft package depends on the system package, so it gets installed automatically.
I was able to solve this exact issue by using an older version of the nuget package. My starting point was that I had copied a class file from an old project to a new one. The class file referenced JwtSecurityToken. This did not compile in the new project, so I added Security.IdentityModel.Tokens.Jwt from nuget package manager. I just added latest version. This worked fine locally, but just like you, it failed when published to azure. I then looked at the old project and noticed that it was using 5.1.4 of that Security.IdentityModel.Tokens.Jwt. So, I downgraded to that version and it now works when published.
fwiw: this is the v2 preview runtime version at the time I did this.
https://<mysite>.azurewebsites.net/admin/host/status?code=<myadminkey>
{
"id": "<mysite>",
"state": "Running",
"version": "2.0.11587.0",
"versionDetails": "2.0.11587.0-beta1 Commit hash: 1e9e7a8dc8a68a3eff63ee8604926a8d3d1902d6"
}
tl;dr
None of the above worked for me and this would randomly happen from time to time until today it happened all the time. The only reason I could see was that Microsoft.IdentityModel.Tokens was not directly referenced in the executing project, but was on a referenced project. The library was sitting in the bin folder, it just wouldn't load.
Reference
Taking a clue from this solution to another problem I was able to resolve it like so:
Solution
Create a static constructor in the app's entry point class
static MainClass()
{
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
}
Add the handler
private static System.Reflection.Assembly? CurrentDomain_AssemblyResolve(object? sender, ResolveEventArgs args)
{
var domain = sender as AppDomain;
var assemblies = domain.GetAssemblies();
foreach(var assembly in assemblies)
{
if (assembly.FullName.IsEqualTo(args.Name))
{
return assembly;
}
}
var folder = AppDomain.CurrentDomain.BaseDirectory;
var name = args.GetLibraryName().Name.Split(Symbols.Comma).FirstOrDefault();
var library = $"{name}.dll";
var file = Path.Combine(folder, library);
if (File.Exists(file))
{
return Assembly.LoadFrom(file);
}
return null;
}

Deploying to a private IIS server from a build in Visual Studio Team Services

Having done what is suggested here: Deploy from Visual Studio Online build to private IIS server
... how do I setup automatic deploys as part of my build when I build a whole branch **/*.sln?
What I have tried ...
In VS I can get the latest version of the code, open a solution and then ...
right click > publish > pick publish profile > deploy
I have named my publish profiles things like "dev", "qa", "production", these refer to the environments into which the project will be deployed and the profiles contain all of the configuration information needed for VS to deploy (via webdeploy / msdeploy) using "one click deploy" that application.
I want to have Team Services on the build server do the exact same thing for projects that have publish profiles defined after it's built the code.
My understanding was that I could just add the msbuild args like this ...
this results in the deployment part of the build throwing the following exception in to the build log ...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4288,5):
Error ERROR_USER_NOT_ADMIN: Web deployment task failed.
(Connected to 'server' using the Web Deployment Agent Service, but could not authorize. Make sure you are an administrator on 'server'.
Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_NOT_ADMIN.)
What user is this using if not the user defined in the publish profile?
Related issues:
Publishing via TFS Build Service fails with "User not Admin"
TFS Builds: Running the builds as administrator
I added an account to the server in question (since the build and server to be deployed to are the same server it made things easier), I also added a group to the server called "MSDepSvcUsers" and added the new account in question to it and the admins group on the box.
I then told both the Web Deployment Agent service and the Team Services Agent service to run under this account (and restarted them).
Unfortunately the result is the same ... I now really want to know how I go about ensuring the account that is used for the msdeploy command is something I expect without relying on loads of scripting ... or maybe that's why Microsoft haven't set this up as a default deploy step option in Team Services already!
Ok so I had some long conversations with the VSTS team over at Microsoft about this and the long and short of it is ...
Microsoft:
We understand your frustration with this area and a big project is
about to spin up to resolve this issue
...
Me being me, came up with some "trick to make it happen".
I managed to figure out that the build box for some odd reason can't be the same server that you are deploying too (no idea why) but having figured that out I wrote a simple console app that with some additional feedback from Microsoft came out pretty good.
It even reports progress back to the process and can log exceptions in the deployment as exceptions in order to fail the build by calling up "internal commands" (neat how this works by the way kudos to the team for that).
There are some hacks in here and it's not perfect but hopefully it'll help someone else, I call this because it's part of the code that gets built in my repo so I am able to add a step in to the build process to call this from within the build output passing the environment name I want to deploy to.
This in tern grabs all the packages (as per the settings above) and uses their publish profiles to figure out where the packages need to go and sends them to the right servers to be deployed ...
using System;
using System.Diagnostics;
using System.IO;
using System.Reflection;
namespace Deploy
{
class Program
{
static string msDeployExe = #"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe";
static void Main(string[] args)
{
var env = args[0];
var buildRoot = Path.Combine(Assembly.GetExecutingAssembly().Location.Replace("Deploy.exe", ""), env);
//var commands = GetCommands(buildRoot);
var packages = new DirectoryInfo(buildRoot).GetFiles("*.zip", SearchOption.AllDirectories);
bool success = true;
for (int i = 0; i < packages.Length; i++)
{
if (!Deploy(packages[i], env)) success = false;
Console.WriteLine("##vso[task.setprogress]" + (int)(((decimal)i / (decimal)packages.Length) * 100m));
}
Console.WriteLine("##vso[task.setprogress]100");
if(success) Console.WriteLine("##vso[task.complete result=Succeeded]");
else Console.WriteLine("##vso[task.complete result=SucceededWithIssues]");
}
static bool Deploy(FileInfo package, string environment)
{
bool succeeded = true;
Console.WriteLine("Deploying " + package.FullName);
var procArgs = new ProcessStartInfo
{
FileName = msDeployExe,
UseShellExecute = false,
RedirectStandardOutput = true,
RedirectStandardError = true,
Arguments =
"-source:package='" + package.FullName + "' " +
"-dest:auto,ComputerName='" + environment + ".YourDomain.com',UserName='deployment user',Password='password',AuthType='ntlm',IncludeAcls='False' " +
"-verb:sync " +
"-disableLink:AppPoolExtension " +
"-disableLink:ContentExtension " +
"-disableLink:CertificateExtension " +
"-setParamFile:\"" + package.FullName.Replace("zip", "SetParameters.xml") + "\""
};
try
{
Console.WriteLine(msDeployExe + " " + procArgs.Arguments);
using (var process = Process.Start(procArgs))
{
var result = process.StandardOutput.ReadToEnd().Split('\n');
var error = process.StandardError.ReadToEnd();
process.WaitForExit();
if (!string.IsNullOrEmpty(error))
{
Console.WriteLine("##vso[task.logissue type=error]" + error);
succeeded = false;
}
foreach (var l in result)
if (l.ToLowerInvariant().StartsWith("error"))
{
Console.WriteLine("##vso[task.logissue type=error]" + l);
succeeded = false;
}
else
Console.WriteLine(l);
}
}
catch (Exception ex) {
succeeded = false;
Console.WriteLine("##vso[task.logissue type=error]" + ex.Message);
Console.WriteLine("##vso[task.logissue type=error]" + ex.StackTrace);
}
return succeeded;
}
}
}
No you don't need a ton of PS scripts to achieve this. MSDeploy.exe is an incredibly useful tool that can probably cover your needs. Add the /t:Package build argument to your VS build task to create a package. Then use a Commandline task to deploy the MSDeploy package to your IIS site. Here are more details about out WebDeploy/MSDeploy works:
http://www.dotnetcatch.com/2016/02/25/the-anatomy-of-a-webdeploy-package/
I do this all of the time. What I did was setup a Release in the Release tab and signed up to enable Deployment Groups. Once you have a the Deployment Group enabled on your account (needed contact MS to get this enabled). I could download PS script that I run on each of the machines that I want to deploy to. Then in the Release screen I can setup the steps to run in a Deployment Group and then the various publish tasks run on the local server allowing them to work.
Using the Deployment Groups is an excellent solution because if you have it load balanced it will deploy to only a portion of the load balanced servers at a time. Allowing the app to stay up the whole time.

Strange behavior of Windows Azure Compute Emulator (SDK 1.8) with multiple role instances on a clean machine with VS2012 but WITHOUT VS2010

Have you ever tried to run a hosted service in the windows azure emulator with full IIS and multiple role instances? Some days ago I noticed that only one of the multiple instances of a web role is startet in IIS at a time. The following screenshot illustrates the behavior and the message box in front of the screenshot shows the reason for this behavior. The message box appears on trying to start one of the stopped websites in the IIS Manager.
Screenshot: IIS with stopped Websites
The sample cloud application contains two web roles: MvcWebRole1 and WCFServiceWebRole1 each configured to use three instances. My first thought was: "Sure! No port collision will happen in the real azure world because every role instance is an own virtual machine. It cannot work in the emulator!" But after some research and analyzing many parts of the azure compute emulator I found out that the compute emulator creates a unique IP for each role instance (in my example from 127.255.0.0 up to 127.255.0.5). This MSDN blog article (http://blogs.msdn.com/b/avkashchauhan/archive/2011/09/16/whats-new-in-windows-azure-sdk-1-5-each-instance-in-any-role-gets-its-own-ip-address-to-match-compute-emulator-close-the-cloud-environment.aspx) of the microsoft employee Avkash Chauhan describes this behavior as well. After that conclusion I came to the following question: why the hell does the compute emulator (more precisely DevFC.exe) not add the IP of the appropriate role to the binding information of each Website???
I added the IP to each Website by hand and tadaaaaa: every Website can be started without any collisions. The next screenshot demonstrates it with the changed binding information highlighted.
Screenshot: IIS with started Websites
Once again: Why the hell does the emulator not do it for me? I wrote a small static helper method to do the binding extension thing for me on every role start. Maybe someone wants to use it:
public static class Emulator
{
public static void RepairBinding(string siteNameFromServiceModel, string endpointName)
{
// Use a mutex to mutually exclude the manipulation of the iis configuration.
// Otherwise server.CommitChanges() will throw an exeption!
using (var mutex = new System.Threading.Mutex(false, "AzureTools.Emulator.RepairBinding"))
{
mutex.WaitOne();
using (var server = new Microsoft.Web.Administration.ServerManager())
{
var siteName = string.Format("{0}_{1}", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id, siteNameFromServiceModel);
var site = server.Sites[siteName];
// Add the IP of the role to the binding information of the website
foreach (Binding binding in site.Bindings)
{
//"*:82:"
if (binding.BindingInformation[0] == '*')
{
var instanceEndpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints[endpointName];
string bindingInformation = instanceEndpoint.IPEndpoint.Address.ToString() + binding.BindingInformation.Substring(1);
binding.BindingInformation = bindingInformation;
server.CommitChanges();
}
else
{
throw new InvalidOperationException();
}
}
}
// Start all websites of the role if all bindings of all websites of the role are prepared.
using (var server = new Microsoft.Web.Administration.ServerManager())
{
var sitesOfRole = server.Sites.Where(site => site.Name.Contains(RoleEnvironment.CurrentRoleInstance.Role.Name));
if (sitesOfRole.All(site => site.Bindings.All(binding => binding.BindingInformation[0] != '*')))
{
foreach (Site site in sitesOfRole)
{
if (site.State == ObjectState.Stopped)
{
site.Start();
}
}
}
}
mutex.ReleaseMutex();
}
}
}
I call the helper method as follows
public class WebRole : RoleEntryPoint
{
public override bool OnStart()
{
if (RoleEnvironment.IsEmulated)
{
AzureTools.Emulator.RepairBinding("Web", "ServiceEndpoint");
}
return base.OnStart();
}
}
I got it!
I have this behavior on three different machines which are all formatted and served with fresh clean windows 8, Visual Studio 2012 and Azure SDK 1.8 and Azure Tools installations recently. So a reinstallation of the Azure SDK and Tools (as Anton suggests) should not change anything. But the cleanliness of my three machines is the crucial point! Anton, do you have Visual Studio 2010 on your machine with at least VS2010 SP 1 installed? I analyzed IISConfigurator.exe with ILSpy and found the code which sets the IP in the binding information of the websites to '*' (instead of 127.255.0.*). It depends on the static property Microsoft.WindowsAzure.Common.Workarounds.BindToAllIpsWorkaroundEnabled. This method internally uses Microsoft.WindowsAzure.Common.Workarounds.TryGetVS2010SPVersion and leads to setting the IP binding to '*' if the SP level of Visual Studio 2010 is smaller than 1. TryGetVS2010SPVersion checks four registry keys and I don't know why but one of the keys exists in my registry und returns the Visual Studio 2010 SP level 0 (I never installed VS2010 on no one of the three machines!!!). As I changed the value of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\10.0\SP from 0 to 10 (something greater 0 should do it) the Azure Emulator starts to set the 127.255.0.* IPs of the roles to the binding information on all of the websites in the IIS and all websites are started correctly.

Resources