Преобразования XDT в проекте библиотеки классов?

Question

У меня есть решение с этими тремя проектами.

• Веб-API
• DAL
• Домен

Проект DAL - это библиотека классов, имеющая веб-ссылку. Таким образом, app.config в этом проекте имеет следующий раздел:

<applicationSettings>
    <Company.Project.Domain.Properties.Settings>
      <setting name="Company_Project_Domain_Some_Service" serializeAs="String">
        <value>http://my.server.local:8888/somePath/service.asmx</value>
      </setting>
    </Company.Project.Domain.Properties.Settings>
  </applicationSettings>

Я установил медленный гепард и использую преобразования конфигурации в этом проекте DAL. Например, у меня есть app.production.config, который преобразует вышеуказанную веб-ссылку, чтобы указывать на рабочую веб-ссылку следующим образом:

<applicationSettings>
    <Company.Project.Domain.Properties.Settings>
      <setting name="Company_Project_Domain_Some_Service" serializeAs="String">
        <value>http://my.PRODUCTIONSERVER.local:8888/somePath/service.asmx</value>
      </setting>
    </Company.Project.Domain.Properties.Settings>
</applicationSettings>

Когда я публикую API, web.config не содержит НИКАКОЙ настройки приложения, показанной выше. Я могу использовать рефлектор, чтобы развернуть файл DAL.dll и увидеть путь к service.asmx. Однако он не выполняет преобразование, поэтому опубликованное приложение НЕ использует my.PRODUCTIONSERVER.local:8888.

Таким образом, два вопроса.

1. Почему публикация НЕ использует преобразование xdt в указанной библиотеке классов?
2. Если блок настроек приложения ДОЛЖЕН быть в файле web.config проекта Web API, означает ли это, что я должен удалить веб-ссылку из DAL и добавить ее в проект Web API?... или я могу просто оставить ссылку и скопировать соответствующий блок applicationSettings в файл web.config?

Answer 1

Во-первых, добавление веб-ссылок в библиотеку не кажется хорошей идеей. Потому что библиотеки - это многократно используемые фрагменты кода, которые являются автономными и могут использоваться в разных проектах. Исходя из этой логики, мне любопытно узнать, почему вы решили выделить DAL в проект, а не в другую папку в веб-API. Но я оставлю это обсуждение на потом.

Чтобы ответить на ваш первый вопрос,

Почему публикация НЕ использует преобразование xdt в указанной библиотеке классов?

Публикация только трансформирует конфиги внутри веб-приложения, из которого вы публикуете. Я не уверен, как вы публикуете свое приложение, но если бы вы использовали командную строку, вы, вероятно, сделали бы что-то подобное.

 msbuild /p:PublishOnBuild WebApi.csproj

MsBuild использует ваш файл.csproj для создания и публикации вашего приложения. А в.csproj содержится информация, необходимая для трансформации. Следовательно, MsBuild НЕ знает, что ему нужно преобразовать app.config из библиотеки, на которую есть ссылка, поэтому ваша конфигурация из DAL не преобразуется, а просто копируется.

Переходя ко второму вопросу

Если блок настроек приложения ДОЛЖЕН быть в файле web.config проекта Web API, означает ли это, что я должен удалить веб-ссылку из DAL и добавить ее в проект Web API? ... или я могу просто оставить ссылку и скопировать соответствующий блок applicationSettings в файл web.config?

У вас есть несколько вариантов здесь,

1. Переместите веб-ссылку в проект Web API, как вы упомянули, и управляйте URI в web.config. Это означает, что вам нужно ссылаться на свой веб-API от DAL.
2. Переместите блок настроек приложения в web.config, но сохраните веб-ссылку в своем DAL. Затем вы можете установить URI вашего сервиса во время выполнения. Как показано здесь
3. [Идеально] Слияние DAL с Web Api. Я считаю, что это идеально, потому что, если вы не хотите делиться DAL между проектами, нет причин переносить его в отдельный проект. На самом деле вы, похоже, сталкиваетесь с этой проблемой, потому что вы ее сначала убрали. Так что, если у вас нет веских причин для этого, это лучший вариант.