Залежна DLL не копіюється у папку виводу збірки у Visual Studio

У мене є візуальне рішення студії. У мене багато проектів у вирішенні. Є один головний проект, який виступає як старт, і використовує інші проекти. Є один проект сказати "ProjectX". Його посилання додається до основного проекту. ProjectX посилається на інший .NET dll (скажімо, abc.dll), який не є частиною рішення.

Тепер цей abc.dll повинен бути скопійований у папку bin / debug основного проекту, але він там не копіюється. Чому це не скопійовано з відомих причин?

Я виявив, що якщо ProjectX посилався на abc.dll, але безпосередньо не використовував жодного з типів, визначених у abc.dll, то abc.dll НЕ буде скопійовано в основну папку виводу. (Це буде скопійовано у вихідну папку ProjectX, щоб зробити це надзвичайно заплутаним.)

Отже, якщо ви явно не використовуєте жодного з типів з abc.dll в будь-якому місці ProjectX, тоді поставте фіктивну декларацію десь в одному з файлів ProjectX.

AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied

Не потрібно робити це для кожного класу - одного разу буде достатньо, щоб зробити копію DLL і все працювати так, як очікувалося.

Додаток: Зауважте, що це може працювати в режимі налагодження, але НЕ для випуску. Детальніше див. У відповіді @ nvirth.

Лише стороною відповіді на відповідь Overlord Zurg.

Я додав посилання на манекен таким чином, і він працював у режимі налагодження:

public class DummyClass
{
    private static void Dummy()
    {
        var dummy = typeof(AbcDll.AnyClass);
    }
}

Але в режимі випуску залежний dll все ще не скопіювався.
Однак це спрацювало:

public class DummyClass
{
    private static void Dummy()
    {
        Action<Type> noop = _ => {};
        var dummy = typeof(AbcDll.AnyClass);
        noop(dummy);
    }
}

Ця інформація фактично коштувала мені годин, щоб розібратися, тому я подумав, що поділяюсь цим.

Так, вам потрібно встановити Copy Localна true. Однак я впевнений, що вам також потрібно посилатися на цю збірку з головного проекту і налаштовувати Copy Localнаtrue неї - вона не просто копіюється з залежної збірки.

Ви можете дістатися до Copy Localоб'єкта, натиснувши на збірку під Referencesта натиснувши F4.

Це виглядає гладко, коли ви робите це атрибут збірки

[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{        
    public ForceAssemblyReference(Type forcedType)
    {
        //not sure if these two lines are required since 
        //the type is passed to constructor as parameter, 
        //thus effectively being used
        Action<Type> noop = _ => { };
        noop(forcedType);
    }
}

Використання буде:

[assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]

Побіг у цьому ж питанні. Довідкова інформація: перед тим як будувати, я додав у рішення новий Project X. Проект Y залежав від проекту X, а проект A, B, C залежав від проекту Y.

Помилки побудови полягали у тому, що не вдалося знайти dll Project A, B, C, Y та X.

Основною причиною було те, що новостворений Project X орієнтований на .NET 4.5, тоді як решта проектів рішення орієнтована на .NET 4.5.1. Проект X не будувався, не спричиняючи решти проектів.

Переконайтеся, що будь-які нові додані проекти націлені на ту ж версію .NET, що й решта рішення.

Не впевнений, чи допомагає це, але для мене багато разів я посилаюся на DLL (що автоматично додає його до папки бін). Однак DLL можуть знадобитися додаткові DLL (залежно від того, які функції я використовую). Я НЕ хочу посилатися на тих, хто знаходиться в моєму Проекті, тому що їм просто потрібно опинитися в тій же папці, що і DLL, яку я фактично використовую.

Я досягаю цього у Visual Studio, "додаючи існуючий файл". Ви повинні мати змогу додати його де завгодно, крім папки Add_data. особисто я просто додаю його до кореня.

Потім змініть властивості цього файлу на ...

Build Action = None (встановлення цього параметра на зразок вмісту насправді копіює "root" версію в корінь плюс копію у кошику).

Копіювати у вивідну папку = Копіювати, якщо новіше (В основному поміщає її у папку BIN, лише якщо вона відсутня, але після цього не робиться)

Коли я публікую .. мої додані DLL існують лише у папці BIN і більше ніде в місці публікації (що я хочу).

Ви також можете перевірити, чи DLL-файли, які ви шукаєте, не включені в GAC. Я вважаю, що Visual Studio розумно не копіює ці файли, якщо вони вже є в GAC на машині збирання.

Я нещодавно зіткнувся з цією ситуацією, коли я тестував пакет SSIS, який потребував збірок, щоб існувати в GAC. З тих пір я це забув і цікавився, чому ці DLL-файли не виходили під час збирання.

Щоб перевірити, що знаходиться в GAC (з командного рядка для розробників Visual Studio):

gacutil -l

Або виведіть у файл, щоб полегшити читання:

gacutil -l > output.txt
notepad.exe output.txt

Щоб видалити збірку:

gacutil -u MyProjectAssemblyName

Я також повинен зазначити, що після того, як я видалив файли з GAC, вони були правильно виведені в каталог \ bin після збірки (Навіть для збірок, на які безпосередньо не посилалося в кореневому проекті). Це було в Visual Studio 2013 Update 5.

У моєму випадку це була найглупіша річ, викликана поведінкою TFS / VS за замовчуванням, з якою я не згоден.

Оскільки додавання dll як посилання на основний проект не спрацювало, я вирішив додати його як "Існуючий предмет", з Copy Local = Завжди. Вже тоді файлу там не було.

Виявляється, незважаючи на те, що файл присутній у VS Solution та все, складене як локально, так і на сервері, VS / TFS не додав фактично додавання файлу до керування джерелом. Вона взагалі не була включена до "Очікує на зміну". Мені довелося вручну перейти до «Провідника управління джерелами» та явно натиснути на значок «Додати елементи в папку».

Дурний, бо я вже 15 років розвиваюся в VS. Я раніше стикався з цим, я просто не пам’ятав, і я якось пропустив це, тому що все ще компілюється через те, що файл є регулярною посиланням, але файл, доданий як існуючий елемент, не копіювався, оскільки його не існувало на сервер управління джерелом.

Я сподіваюся, що це економить когось деякий час, оскільки я втратив на це 2 дні свого життя.

Це невеликий твіст на прикладі nvirth

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}

Я б додав його до подій Postbuild, щоб скопіювати необхідні бібліотеки у вихідні каталоги. Щось на зразок XCopy шляхотехнічних бібліотек targetdirectory

Ви можете знайти їх у властивостях проекту -> Створення подій.

Проблема:

Зустрічався з аналогічною проблемою для пакета DLL NuGet (Newtonsoft.json.dll), де вихід збірки не включає посилання DLL. Але збірка проходить чудово.

Виправити:

Перегляньте свої проекти в текстовому редакторі та шукайте посилання з тегами в них. Як Правда чи Неправда. "Приватне" є синонімом "Копіювати місцеве". Десь у своїх діях MSBuild бере на себе пошук залежностей, він знаходить свою залежність десь іншим і вирішує не копіювати її.

Отже, перегляньте кожен .csproj / .vbproj файл і видаліть теги вручну. Перебудуйте, і все працює як у Visual Studio, так і в MSBuild. Після того, як ви працюєте, ви можете повернутися та оновити те місце, де ви вважаєте, що вони повинні бути.

Довідка:

https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/

НЕ ПОТРІБНА ДУМКА У КОДІ
Просто:

додати посилання на виконуваний проект

або / і переконайтеся, що посилання у виконаному проекті "Copy Local"встановлено на TRUE(що було моєю " помилкою "), здається, що це "перекреслило" налаштування в базовій бібліотеці-проекті, на яку посилається ...

Якщо ви праві, натисніть на посилання, на яке посилається, ви побачите властивість під назвою Copy Local . Якщо для параметра Copy Local встановлено значення true, збірка повинна бути включена в бін. Однак у Visual studio є проблема, що іноді вона не включає посилається dll у папку bin ... це вирішення, яке працювало для мене:

TLDR; Visual Studio 2019 може просто потребувати перезавантаження.

Я зіткнувся з цією ситуацією, використовуючи проекти, засновані на проекті Microsoft.NET.Sdk.

<Project Sdk="Microsoft.NET.Sdk">

Конкретно:

• Project1: цілі .netstandard2.1
  • посилання Microsoft.Extensions.Logging.Consoleчерез Nuget
• Project2: цілі .netstandard2.1
  • посилання Project1через на проект
• Project2Tests: цілі .netcoreapp3.1
  • посилання Project2через посилання на проект

Під час виконання тесту я отримав повідомлення про помилки, яке вказує на це Microsoft.Extensions.Logging.Console його неможливо знайти, і справді його немає у каталозі виводу.

Я вирішив вирішити цю проблему, додавши Microsoft.Extensions.Logging.Consoleдо цього Project2, лише щоб виявити, що Nuget Manager Visual Studio не перераховуєтьсяMicrosoft.Extensions.Logging.Console встановлених Project1, незважаючи на його наявність у Project1.csprojфайлі.

Просте вимкнення та перезапуск Visual Studio вирішило проблему без необхідності додавати додаткові посилання. Можливо, це врятує когось 45 хвилин втраченої продуктивності :-)

Ви можете встановити і основний проект, і вихідний шлях збірки ProjectX до однієї папки, тоді ви зможете отримати всі необхідні клітини у цій папці.

Переконайтесь, що використовуваний вами залежний dll не має цільової .net-рамки вище, ніж цільова .net-рамка програми додатка вашого проекту.

Ви можете перевірити це, вибравши проект, потім натисніть клавішу ALT + ENTER, потім виберіть Застосування з лівого боку та виберіть Цільовий каркас свого проекту.

Припустимо, залежно від dll Target Framework = 4.0 та dll Target Framework = 3.5, а потім змініть це на 4.0

Дякую!

Окрім звичайних вище, я мав публікувати багатопроектне рішення. Мабуть, деякі файли націлені на різні рамки.

Тож моє рішення: Властивості> Конкретна версія (помилково)

Додайте DLL як існуючий елемент до одного з проектів, і він повинен бути відсортований

VS2019 V16.6.3

Для мене проблема якось була основним .proj-файлом із записом, подібним до цього, для проекту, DLL якого не було скопійовано у батьківську папку біна проекту:

<ProjectReference Include="Project B.csproj">
  <Project>{blah blah}</Project>
  <Name>Project B</Name>
  <Private>True</Private>
</ProjectReference>

Я вручну видалив рядок, <Private>True</Private>і DLL потім було скопійовано в основну папку біна проекту при кожній збірці основного проекту.

Якщо ви переходите до посилання на проблемний проект у папці посилань основного проекту, клацніть по ньому та перегляньте властивості, там є налаштування "Копіювати локальне". Приватний тег прирівнюється до цього налаштування, але для мене чомусь зміна локальної копії не вплинула на приватний тег у файлі .proj.

Прикро, що я не змінив місцеве значення копії для посилання, не маю уявлення, як воно встановилося таким чином, і інший день даремно простежував дурну проблему з VS.

Дякую всім іншим відповідям, які допомогли зонувати мене у справі.

HTH