Блог

Я создал следующую пользовательскую цель:

 [Target("MyTarget")
public class MyTarget : TargetWithLayout
  

Этот класс определен в его собственной сборке, скажем MyTargets.dll (ненастоящее имя). Файл NLog.config содержит следующие строки

 <extensions>
    <add assembly="MyTargets, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</extensions>
  

Была определена цель для использования этого нового типа:

 <target name="myTarget" xsi:type="MyTarget" />
  

Был определен регистратор для использования этого целевого объекта (опущен).

Мое приложение успешно загрузит конфигурацию, если я ссылаюсь на целевой проект сборки. Если я попытаюсь сослаться на выходную библиотеку DLL, она не загрузится. Если я программно добавлю цель из сборки (ссылка на ячейку, а не проект), тогда это сработает.

Библиотеки DLL, похоже, находятся в нужном месте, т.е. в каталоге bin. Тип должен существовать, потому что я могу ссылаться на тип в коде, но, похоже, он не работает при попытке ссылаться на тип в коде.

Почему бы просто не сделать это в коде? Ну, это часть пакета nuget, который я создаю, и я хочу, чтобы стандартный файл конфигурации распространялся среди всех потребителей этой библиотеки кода.

Любые предложения / идеи будут высоко оценены

Оказывается, я идиот.

По несвязанным причинам я решил скопировать файл NLog.config в каталог bin при сборке, сохранив оригинал на уровне корневого проекта. Это вызвало какой-то конфликт внутри NLog.

Когда я удаляю файл конфигурации из каталога bin, файл конфигурации на корневом уровне загружается правильно, и мои пользовательские цели находятся в соответствии с ожиданиями. Если я удалю файл конфигурации с корневого уровня проекта и помещу его в каталог bin (т. Е. на том же уровне, что и сборка, содержащая пользовательскую цель), то загруженный файл конфигурации не сможет найти пользовательскую цель.

Итак, подводя итог, я перестал помещать файл конфигурации в каталог bin и оставил его там, где он определен (корневой уровень проекта)