Условное AssemblyName заставляет проект C # всегда перестраиваться при использовании имен, отличных от «Debug» / «Release»

Question

Поэтому я добавляю расширение "d" к имени моей сборки при сборке в режиме отладки.Насколько я могу сказать, стандартный способ сделать это в C # - это отредактировать файл .csproj и ввести следующее:

<PropertyGroup>
  <AssemblyName Condition="'$(Configuration)' == 'V90 Debug'">$(AssemblyName)d</AssemblyName>
</PropertyGroup>

Это дает желаемый эффект, но теперь проект darn всегда перестраиваетвывод .dll, вызывая повторную привязку других проектов, которые зависят от него, и т. д. Без этого изменения у меня нет такой проблемы.

До сих пор увеличение многословности выходных данных проекта не помогло.

Редактировать. Еще одна важная деталь: в наших конфигурациях используются имена, такие как «V90 Release», «V90 Debug», «V100 Release» и т. Д., Чтобы мы могли ориентироваться на разные версиисреда выполнения Visual Studio.Я написал тестовое приложение со стандартными именами конфигурации и обнаружил, что в этом случае моей проблемы не возникает.

Answer 1

Вы используете старый стандарт в разработке C / C ++.Большая разница с управляемым кодом заключается в отсутствии компоновщика.Вы использовали для настройки компоновщика для использования версии библиотеки d в сборке Debug, версии библиотеки d в сборке выпуска.Этот механизм полностью отсутствует в .NET, код в библиотеках динамически связан во время выполнения.Создание практически разных имен для разных сборок значительно меньше.

Одна из проблем, с которой вы столкнетесь, если будете придерживаться этой старой стратегии, состоит в том, что у вас возникнут дополнительные проблемы со ссылочными сборками проекта.Не существует достойного способа использовать разные имена в разных конфигурациях.Зависимые сборки перечислены в узле Reference проекта, это свойство проекта, которое не зависит от конфигурации.Это не невозможно, вам понадобится гораздо больше Condition хаков для переименования эталонных сборок.Это также может повлиять на проверку зависимостей сборки.

На самом деле в этом нет необходимости, сборка отладки и выпуска сборок будет иметь одинаковые метаданные.Но если вы пропустите это, у вас возникнут проблемы во время выполнения.CLR будет сказано использовать неправильное имя сборки.Обойти это технически возможно, спрятав сборки в подкаталоге и используя событие AppDomain.AssemblyResolve для загрузки правильного.Вам понадобится событие после сборки, чтобы переименовать и скопировать сборку в этот каталог.Все это становится ужасным в спешке, когда эти сборки имеют зависимости от других сборок.

Короче говоря, ваш предыдущий стандарт просто не подходит для управляемого кода.