Можем ли мы автоматически скопировать *.dll.config?

В Visual Studio есть раздел «свойства», когда у вас открыт активный файл. Для App.config у него есть свойство с именем Copy to Output Directory, варианты

• Do Not Copy
• Copy if Newer
• Copy Always

Вам нужен либо второй, либо третий вариант.

В следующем посте есть лучший ответ:

Visual Studio/MSBuild копирует библиотеку классов, на которую ссылаются app.config как *.dll.config в папку bin текущего проекта

// Add this <ItemGroup> at the end of your .csproj file before </Project> and after <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<ItemGroup>
    <Content Include="app.config">
        <Link>$(TargetName).dll.config</Link>
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
</ItemGroup>

Переименуйте app.config в проекте dll в [dllname].dll.config. Измените свойства того же файла на «копировать всегда» и перестройте. Отлично работает для меня. Я также попытался добавить еще один параметр через диалоговое окно «Настройки» в VS, и он отлично обновился, хотя это больше не был app.config. Кстати, с использованием обновления VS2013 3.

Другой способ сделать то же самое — создать файл жесткой ссылки с [dllname].dll.config в папке проекта и изменить его свойства на «копировать всегда», таким образом, у вас все еще будет ваш app.config как обычно, но если вы обновили его, он также обновит ваш файл [dllname].dll.config. Единственное реальное предостережение здесь заключается в том, что он может не отслеживать жесткую ссылку, когда вы регистрируетесь в системе управления версиями, такой как TFS, и вы можете случайно перезаписать ссылку. Но опять же, он учитывает ссылки, когда вы «добавляете существующий элемент» в качестве ссылки, поэтому он может работать или не работать в вашей ситуации. Вам решать.

С хостом CLR по умолчанию только EXE может иметь файл .config. Не DLL. Копирование файла .dll.config должно быть бессмысленным, если вы не откроете и не проанализируете файл самостоятельно. В этом случае вам следует использовать другое имя, чтобы избежать путаницы.

У меня такая же проблема. У вас может возникнуть ситуация, когда Свойства не помогут вам скопировать app.config туда, куда вам нужно. Например, когда вы выполняете интеграционное модульное тестирование. Тогда у вас может быть два варианта:

1. Использовать событие после сборки

   copy /Y «$(ProjectDir)App.config» «....\test\Debug\$(TargetFileName).config»

2. Вручную скопируйте разделы файла конфигурации из libA.dll в libA.Test.dll.

В итоге я использую 2, так как он оказался более надежным для меня.

Хотя я опаздываю, но мой ответ может помочь другим. Я использовал следующую команду в качестве события перед сборкой:

copy /Y $(SolutionDir)\[YOUR_LIBRARY_PROJECT]\app.config $(ProjectDir)$(OutputPath)[YOUR_LIBRARY_NAME].dll.config

Я старался быть как можно более динамичным, и приведенная выше команда сработала.