Почему мне иногда нужно добавлять зависимости Nuget, даже если они не используются непосредственно моим проектом? - PullRequest
Новая
       131

Почему мне иногда нужно добавлять зависимости Nuget, даже если они не используются непосредственно моим проектом?

1 голос
/ 26 мая 2020

Извините за расплывчатое название, но я действительно не знал, как его кратко сформулировать.

Вот моя проблема: у меня есть решение. NET Framework C# с двумя проектами внутри:

  • Project A, библиотека C#, которая ссылается на пакет Nuget NP
  • Project B, приложение C#, которое включает Project A в качестве ссылки на проект

В Project A у меня есть такой метод: 

public class FooClass {
    public static void Foo(){
        //does something with a class from referenced Nuget package "NP"
        NP.BarClass.Bar();
        return;
    }
}

В Project B я вызываю вышеупомянутый метод, например: 

public static void main(){
    FooClass.Foo();
}

однако это дает следующую ошибку компилятора:

Тип BarClass определен в сборке, на которую нет ссылки. Вы должны добавить ссылку на сборку NP, Version = XXXX, Culture = нейтральный, PublicKeyToken = xxxxxxxxxxx '

Решение, предложенное компилятором, состоит в том, чтобы также добавить ссылку на Пакет Nuget NP в Project B . Когда я это сделаю, все будет работать, как ожидалось.

Мои вопросы:

  • Почему это происходит только с некоторыми пакетами Nuget? Я уже некоторое время работаю с C#, и это происходит не со всеми пакетами, а только с некоторыми из них. Например, на этот раз это происходит с пакетом Microsoft.ReportingServices.ReportViewerControl.Winforms, но я видел, как это происходит и с другими пакетами nuget. Однако с другими пакетами этого вообще не происходит. Например, я использовал пакет ClosedXML в том же проекте, и это не вызывает у меня этой проблемы. Почему?
  • Почему это вообще происходит? Поскольку мой проект (Project B) не ссылается напрямую на какие-либо типы или методы из пакета NP, почему я должен включать его явно? Разве не достаточно того, что он включен в Project A, тот, который его использует?

РЕДАКТИРОВАТЬ: Мне удалось воспроизвести проблему в автономном примере, см. здесь

Ответы [ 2 ]

1 голос
/ 27 мая 2020

РЕДАКТИРОВАТЬ: Я воспроизвел проблему здесь

Что ж, после дальнейших ошибок и ошибок я наконец нашел источник проблемы и позвольте мне сказать вам: это довольно странно, по крайней мере, на мой взгляд.

Итак, причина, по которой это, казалось, происходило только в определенных случаях, заключается в том, что для этого, похоже, существует дополнительное требование. В частности, у вас должен быть перегруженный метод с таким же количеством параметров, который либо возвращает, либо принимает в качестве параметра тип из рассматриваемого пакета nuget .

В моем случае FooClass в ProjectA было примерно так: 

public class FooClass
{
    public static void Foo(string x)
    {
        //Do something
        return;
    }

    public static void Foo(ClassFromNugetPackage np)
    {
        //Do something
        return;
    }
}

Теперь, в ProjectB я вызывал только первый метод, тот с параметром string, но это давало мне ошибку , даже если проект напрямую не ссылается ни на один класс из пакета nuget.

Однако, если я переименую второй метод, он больше не будет перегрузкой, например: 

public class FooClass
{
    public static void Foo(string x)
    {
        //Do something
        return;
    }

    public static void Bar(ClassFromNugetPackage np) //Renamed method
    {
        //Do something
        return;
    }
}

проблема исчезла!

Если кто-нибудь может подсказать мне лог c за этим, я был бы счастлив. Я имею в виду, что перегрузка метода разрешается во время компиляции, верно? Компилятор должен знать, что я вызываю версию метода, которая не возвращает / не принимает данные из пакета nuget ... почему тогда ошибка?

1 голос
/ 27 мая 2020

Почему это происходит только с некоторыми пакетами Nuget? Я уже некоторое время работаю с C#, и это происходит не со всеми пакетами, а только с некоторыми из них.

Поскольку ваша проблема сложна, и мы не можем протестировать все в с нашей стороны, возможно, вы можете следовать этим:

На самом деле , у него есть вероятность конфликта между вашей версией VS Framework или формат ссылки на пакет и определенные c пакеты nuget .

Некоторые специфические c пакеты nuget установлены в проекте библиотеки классов, но когда другие проекты ссылаются на библиотеку классов, содержимое некоторые пакеты c будут конфликтовать со старой версией фреймворка VS, поэтому вам все равно нужно ссылаться на основную версию. Проект можно идентифицировать только путем добавления этой зависимости. И это просто проблема с некоторыми специальными пакетами и версией фреймворка.

И еще одна такая же, как zivkan сказал, вы должны поддерживать согласованный формат управления пакетами (Tools -> Options -> Nuget Package Manager -> General -> Package Management) для предотвращения конфликтов из-за разных форматов управления. Вы должны убедиться, что выходные файлы проекта A, включая NP , находятся в выходных файлах Porject B.

Почему это вообще происходит? Поскольку мой проект (проект B) не ссылается напрямую на какие-либо типы или методы из пакета NP, почему я должен включать его явно? Разве не достаточно того, что он включен в проект A, тот, который его использует?

Полагаю, вы использовали старую версию VS (<=VS2017) для создания таких проектов.

В общем, , вам действительно не нужно включать их в основной проект (проект B).

Фактически , In VS2017 или ранее , в форме Ссылка на проект , действительно существует проблема, заключающаяся в том, что зависимый nuget и его файлы в проекте библиотеки классов будут потеряны в проект, который ссылается на него. К счастью, , эта проблема была исправлена ​​в vs2019.

Итак, если ваша ситуация такая, как я сказал, я предлагаю вам использовать последнюю версию VS2019 .

Или в более старой версии VS, используйте ваше решение -> добавьте nuget в проект B.

На моей стороне с VS2019 я не сталкивался с такой же ошибкой.

...