我在管理控制台中有一个无法部署（在初始化和中止之间循环）的辅助角色。 它在模拟器中运行良好。
令人沮丧的是，部署失败了，它似乎几乎不可能找到原因。
我已经检查了所有连接字符串，启用了诊断程序，检查了我所有的程序集已部署，googled ALOT并丢失了一些头发。
我现在的观点是，我一点一点地添加代码，并重新部署以找到失败的代码，这个过程非常缓慢。
worker本身连接到sql azure和azure存储。我让它连接到模拟器中的实时端点没有任何问题。
一旦配置StructureMap（IoC），它似乎就失败了。但是，我在我的网络角色中使用几乎相同的代码，这很好。
那我在哪里可以从这里（除了瓶子）？
我将首先重新调整你到目前为止收到的反馈。最大的杀手是WorkerRole中的Run（）过程。如果WorkerRole在启动时遇到问题，您可以使用try / catch将代码包装在此方法中并进行记录。
如果您选择使用内置诊断程序，我建议您阅读 瑞恩邓恩的 博客，以及， smarx的博客。他们都踩到了这个基础，并且在他们去的时候做了很好的记录/分享工作。 MSDN网站（对不起，首先回答所以只有两个链接:)）在这个主题上也有了很大的改进。
我将在此对话中添加的部分是您如何遵循建议。我不使用Intellitrace，因为我无法访问它，并且在使用远程桌面（可以在Visual Studio中完成）到我的角色时使用它。如果配置log4net或类似的东西（角色的本地），您将能够通过RDP登录并读取日志。
现在，我们经常发现的两件事情......
UseDevelopmentStorage = True - 这是默认设置，可能会在部署时产生问题。已经写了很多相关内容。
依赖关系 - 开发人员可以访问许多不在托管角色中的东西。最简单的例子是IMO，它是ASP.NET MVC。您既可以使用“稳定版本”理念进行管理，也可以使用Web平台安装程序命令行（dunnry博客上还有Azure Boostrapper）来启动角色。
对我来说，关键是RDP，因为你可以实际登录并看看发生了什么。
更新 - 无法相信我忘记了这一个，因为它一直杀死我，但是，如果使用SQL Azure，您可能还需要配置防火墙。在开发过程中，我们经常会破坏和重新部署我们的角色，而不是更新，并导致偶尔的IP地址更改。如果未在涉及SQL Azure的防火墙中配置这些，则可能会出现问题。
希望这有助于人类。
你会相信吗，它 是 工作者角色缺少程序集。我对任何面临类似问题的人的建议是对所有依赖项进行单次，双次和三次检查。
微软的回应是使用Intellitrace，但如果你不想为VS升级做好准备，你可以使用 AsmSpy （Mike Hadlow的一个很小的实用工具）。
这最终让我发现我的一个工作者角色依赖关系依赖于asp.net mvc！它不应该在那里，羞耻我花了这么长时间才找到。
除了Mike上面分享的优秀提示之外，还有一些需要注意的其他提示：
这是我用于将日志写入Azure存储的代码：
#region Setup diagnostics
DiagnosticMonitorConfiguration diagnosticsConfig
= DiagnosticMonitor.GetDefaultInitialConfiguration();
// Windows event logs
diagnosticsConfig.WindowsEventLog.DataSources.Add("System!*");
diagnosticsConfig.WindowsEventLog.DataSources.Add("Application!*");
diagnosticsConfig.WindowsEventLog.ScheduledTransferLogLevelFilter = LogLevel.Warning;
diagnosticsConfig.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
// Windows Azure logs
diagnosticsConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Warning;
diagnosticsConfig.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", diagnosticsConfig);
#endregion Setup diagnostics
您可以将Azure日志ScheduledTransferLogLevelFilter设置为Undefined，以记录发送到Trace侦听器的所有内容。
我用了 ILogger 在我的应用程序中记录的界面所以我只写了一个调用的 Trace.WriteLine 以便将任何异常记录到Azure存储中。
对我来说一个问题是，即使将所有内容都包装在一个巨大的try catch块中，在StructureMap初始化期间产生的异常也不是很有用。
我将以下扩展方法添加到我的记录器中，以便我可以获得内部异常。正是这一点导致我看到了失踪的MVC装配问题和经典的脸部时刻。
public static string BuildExceptionMessage(this ILogger logger, Exception x)
{
var logException = x;
while (logException.InnerException != null)
{
logException = logException.InnerException;
}
var errorMessage = string.Empty;
if (HttpContext.Current != null)
{
errorMessage = Environment.NewLine + "Error in Path :" + System.Web.HttpContext.Current.Request.Path;
// Get the QueryString along with the Virtual Path
errorMessage += Environment.NewLine + "Raw Url :" + System.Web.HttpContext.Current.Request.RawUrl;
}
// Get the error message
errorMessage += Environment.NewLine + "Message :" + logException.Message;
// Source of the message
errorMessage += Environment.NewLine + "Source :" + logException.Source;
// Stack Trace of the error
errorMessage += Environment.NewLine + "Stack Trace :" + logException.StackTrace;
// Method where the error occurred
errorMessage += Environment.NewLine + "TargetSite :" + logException.TargetSite;
return errorMessage;
}
我希望能帮助其他人。