Сбой пользовательской цели NLog в Azure .NET Core 2.1 - PullRequest
Новая
       38

Сбой пользовательской цели NLog в Azure .NET Core 2.1

0 голосов
/ 27 июня 2018

Я некоторое время использовал NLog с .NET Core 2.0 и пользовательскую цель для успешной записи в хранилище BLOB-объектов Azure.

Я сейчас обновился до .NET Core 2.1, и развернутое решение в Azure Web App завершилось неудачно, поскольку, согласно журналу событий Kudu, NLog не может найти пользовательскую цель, определенную в файле конфигурации NLog, , хотя и Локально работает нормально .

Мой компоновщик хоста выглядит следующим образом: 

        public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseUnityServiceProvider()
            .UseNLog()
            .UseStartup<Startup>();

и моя цель NLog определена в классе запуска: 

        public Startup(IHostingEnvironment env)
    {
        var builder = new ConfigurationBuilder()
            .SetBasePath(env.ContentRootPath)
            .AddJsonFile("appsettings.json", false, true)
            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", true)
            .AddJsonFile("appsettings.local.json", true)
            .AddEnvironmentVariables();

        Configuration = builder.Build();
        HostingEnvironment = env;

        NLogRegistry.Register(env, new ConfigurationAdapter(Configuration));
    }

NLog Registry - это просто оболочка для решения, основанного на Пользовательская цель с внедренными сервисами для NLog с .net core

т.е. 

    public class NLogRegistry
{
    public static void Register(IHostingEnvironment env, IConfigurationAdapter configuration)
    {
        //Setup custom NLog Azure Blob logger with injected configuration
        Target.Register<AzureBlobStorageTarget>("AzureBlobStorage");

        var nlog = ConfigurationItemFactory.Default.CreateInstance;
        ConfigurationItemFactory.Default.CreateInstance = type =>
        {
            try
            {
                return nlog(type);
            }
            catch (Exception)
            {
            }

            return new AzureBlobStorageTarget(configuration);
        };

        env.ConfigureNLog("nlog.config");
    }
}

Я думаю, что происходит то, что в конвейере .NET Core произошли некоторые изменения, так что NLog вызывается перед методом запуска. Поскольку NLog настроен на «автоматическое обнаружение» nlog.config, он пытается установить его до того, как у меня будет возможность правильно настроить цель.

Если я переименую файл nlog.config, тогда автообнаружение не произойдет, и NLog придется подождать, пока я не запущу метод ConfigureNLog в моем классе регистров. Тогда все отлично работает.

Кто-нибудь знает, какое правильное место в конвейере ASP.NET Core 2.1 вызывается Azure, чтобы убедиться, что я могу правильно настроить цель NLog до того, как NLog попытается выполнить самонастройку?

1 Ответ

0 голосов
/ 02 февраля 2019

Вместо внедрения IConfiguration в конструкторе в AzureBlobStorageTarget, теперь вы можете просто использовать NLog Layout-Type для AzureBlobStorageTarget-properties.

Затем настройте макет с помощью ${configsetting}, введенного с NLog.Extension.Logging ver. 1.4.0:

https://github.com/NLog/NLog/wiki/ConfigSetting-Layout-Renderer

Может также рассмотреть возможность перехода к этой цели NLog:

https://github.com/JDetmar/NLog.Extensions.AzureStorage#blob-configuration

Но если вы настаиваете на использовании пользовательской цели, основанной на внедрении зависимостей параметров конструктора:

https://github.com/NLog/NLog/wiki/Dependency-injection-with-NLog

...