Преобразования Xdt в проекте библиотеки ссылочных классов?

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

  • Веб-API
  • ДАЛ
  • Домен

Проект 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 проекта веб-API, означает ли это, что я должен удалить веб-ссылку из DAL и добавить ее в проект веб-API? ... или я могу просто оставить ссылку и скопировать соответствующий блок applicationSettings в web.config?

publishing asp.net-web-api2 xdt-transform slowcheetah
person BBauer42    schedule 09.02.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

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

 msbuild /p:PublishOnBuild WebApi.csproj

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

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

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

Здесь у вас есть несколько вариантов,

  1. Переместите веб-ссылку на проект веб-API, как вы упомянули, и управляйте URI в web.config. Это означает, что вам нужно ссылаться на свой веб-API из DAL.
  2. Переместите блок настроек приложения в web.config, но сохраните веб-ссылку в своем DAL. Затем вы можете установить URI вашего сервиса во время выполнения. Как показано здесь
  3. [Идеально] Объединить DAL с веб-API. Я считаю, что это идеально, потому что, если вы не хотите использовать DAL в разных проектах, нет причин перемещать его в отдельный проект. На самом деле вы, кажется, столкнулись с этой проблемой, потому что вы переместили ее в первую очередь. Так что, если у вас нет веских причин для этого, это лучший вариант.
person Vignesh    schedule 31.05.2016
comment
Спасибо. Я фактически объединил проекты с тех пор, как задал вопрос, и да, я согласен, так намного проще. Если бы я повторно использовал DAL, я бы выбрал ваше второе предложение. Спасибо еще раз. - person BBauer42; 31.05.2016