Question

我在管理控制台中有一个无法部署的工作角色（在初始化和中止之间循环）。 它在模拟器中正常运行。

令人沮丧的是，部署失败了，它似乎几乎不可能找到原因。

我检查了所有连接字符串，启用了诊断程序，检查了所有部署程序的部署情况，用Google搜索了ALOT并丢失了一些头发。

我现在的观点是，我一点一点地添加代码，并重新部署以找到失败的代码，这个过程非常慢。

worker本身连接到sql azure和azure存储。我把它连接到模拟器中的实时端点没有任何问题。

配置StructureMap（IoC）后似乎失败了。但是，我在我的网络角色中使用几乎相同的代码，这很好。

那么我可以从哪里（除了瓶子）去哪儿？

Answer 1

我将首先重新调整您目前收到的反馈意见。最大的杀手是WorkerRole中的Run（）过程。如果WorkerRole在启动时遇到问题，您可以使用try / catch将代码包装在此方法中并记录它。

如果您选择使用内置诊断程序，我建议您阅读Ryan Dunn's博客以及smarx's blog。两者都踩到了这个基础，并且在他们去的时候做了很好的记录/分享工作。 MSDN网站（对不起，首先回答所以只有两个链接:)）在这个主题上也有了很大的改进。

我将添加到这个对话中的部分是你如何遵循建议。我没有使用Intellitrace，因为我无法访问它，并且在使用远程桌面时（可以在Visual Studio中完成）到我的角色。如果您配置log4net或类似的东西（角色的本地），您将能够通过RDP登录并阅读日志。

现在，我们经常发现的两件事情......

UseDevelopmentStorage = True - 这是默认设置，可能会在部署时产生问题。已经有相当多的文字写在这上面了。
依赖关系 - 开发人员可以访问许多不属于托管角色的东西。最简单的例子是IMO，它是ASP.NET MVC。您既可以使用“稳定版本”理念进行管理，也可以使用Web平台安装程序命令行（dunnry博客上还有Azure Boostrapper）来启动角色。

对我而言，关键是RDP，因为您可以实际登录并查看正在发生的事情。

更新 - 无法相信我忘记了这个，因为它一直杀死我，但是，如果使用SQL Azure，您可能还需要配置防火墙。在开发过程中，我们经常会破坏和重新部署我们的角色，而不是更新，并导致偶尔的IP地址更改。如果在涉及SQL Azure的防火墙中未配置这些，则可能会出现问题。

希望这有助于人。

Answer 2

您是否相信它，是工作者角色的缺失程序集。我对任何面临类似问题的人的建议是对所有依赖项进行单次，双次和三次检查。

微软的回应是使用Intellitrace，但是如果你不想进行VS升级，你可以使用AsmSpy（Mike Hadlow的一个很小的实用工具）。

这最终让我发现我的一个工作者角色依赖关系依赖于asp.net mvc！它应该不存在，可惜我花了这么长时间才找到。

除了Mike上面分享的优秀提示之外，还有一些需要注意的其他提示：

确保使用https端点进行诊断
缺少组件（只是为了重申）。我也遇到了NHibernate 3.1的问题，其中代理工厂工厂程序集未复制到输出路径（即使使用copy local = true）。不得不手动复制（NHibernate.Bytecode.Castle）

以下是我用于将日志写入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;
    }

我希望能帮助其他人。

Azure - 如何解决失败的部署问题

2 个答案: