Открытый статический класс и методы не найдены в пакете NuGet
Я столкнулся со странной проблемой, когда разработал пакет NuGet. Из-за архитектуры устаревшего программного обеспечения, для которого я пытаюсь написать новую функциональность, она находится в .NET Framework 4.6.1 (знаю, знаю. Мы работаем над обновлением). Пакет NuGet написан на C#, а приложение, которое будет ссылаться на пакет NuGet, написано на VB .NET, то есть на .NET Framework 4.6.1. Устаревшее приложение использует три пакета NuGet, которые я написал для этого решения, но они не отображаются как ошибки.
Проблема в заголовке этого вопроса. Открытый статический класс и методы в написанном мною пакете NuGet помечены как «не объявленные. Они могут быть недоступны из-за уровня защиты». Из-за этой ошибки я явно не могу построить.
Я пробовал следующее:
- Удаление папок BIN/OBJ
- Восстановление/очистка и создание решений
- Увеличение версии NuGet для проверки того, что старые ссылки не сохраняются.
- Добавление ссылок на пакеты NuGet, которые поддерживают мой пакет NuGet (в основном пакеты, поддерживающие Json)
- Удаление и чтение ссылок на пакеты NuGet на мои пакеты
Возможно, стоит также отметить, что ветка, в которой я работаю для устаревших приложений, собирается без изменений, а также строится со ссылками на мои пакеты NuGet. Он не собирается, как только я добавляю вызовы в пакет NuGet. Мне интересно, проблема ли это в функции Wait(), но я не могу определить реальную проблему. Ошибки, которые появляются в выходных данных во время сборки, просто говорят на одном и том же языке: «не найдено/недоступно».
Примеры кода ниже:
В пакете NuGet у меня есть следующий код.
public static class ClassInNugetPackage
{
public static async Task Initialize(string customerNumber, int locationId)
{
await SystemState.Instance.Initialize(customerNumber, locationId);
}
public static async Task SetApiUrl(string url)
{
await SystemState.Instance.SetApiUrl(url);
}
}
Устаревшее приложение будет вызывать это в конструкторе формы следующим образом:
Public Sub New()
InitializeComponent()
Dim customerNumber = "170"
Dim customerLocationId = 2140
NamespaceInNugetPackage.ClassInNugetPackage.SetApiUrl("https://localhost:7012").Wait()
NamespaceInNugetPackage.ClassInNugetPackage.Initialize(customerNumber, customerLocationId).Wait()
If ClassInNugetPackage.BooleanValue.IsEnabled Then
MsgBox("Yes!")
End If
...
End Sub
Если метод объявлен как async, вам следует Await использовать его, даже в VB. Но я не уверен, что это было возможно еще в версии 4.6.1. Однако, поскольку вы управляете пакетом NuGet, а устаревшее приложение использует их синхронно, я бы изменил пакет, добавив эквивалентные синхронные методы, которые может использовать устаревшее приложение. вызов. Внутри пакета вы можете просто вызвать и дождаться асинхронных методов, чтобы не было фактического дублирования кода.
@JonSkeet Пакет NuGet — это частное решение в моем офисе, поэтому, к сожалению, я не могу поделиться им публично. Код, который я здесь включил, примерно 1:1 с кодом, который есть в нашей кодовой базе. Пространства имен и имена классов были заменены, вот и все. Считаете ли вы, что мне не хватает пакета или ссылки, которые могут решить эту проблему? @ JoelCoehoorn Я попробую и посмотрю, решит ли это проблему.
Intellisense показывает, что пространства имен и классы видимы, я могу выполнить автозаполнение и просмотреть определенные общедоступные методы, которые я представил в имени класса, однако при сборке Visual Studio не удается это сделать. Моими следующими большими шагами будет попытка использовать MSBuild вне Visual Studio, и если это сработает, я посмотрю, нужно ли мне обновить или исправить Visual Studio.
@JoelCoehoorn В целом я согласен, но Wait может быть приемлемым в некоторых случаях, например. консольное приложение.
Похоже, что-то сломалось в процессе сборки; Я сделал тестовое решение с библиотекой C# Framework 4.6.1, состоящей из общедоступного статического класса со статической ожидаемой функцией, и консольной программы Framework 4.6.1 VB, которая ссылалась на библиотеку C# и (как единственный оператор в программе) вызывала Wait по результату вызова процедуры. Он построен без ошибок.
Если вы в настоящее время используете PackageRef, что произойдет, если вы переключитесь на использование packages.config?
NuGet предполагает, что пакеты неизменяемы, а это означает, что каждый раз, когда вы изменяете пакет (добавляете новые API, исправляете ошибки и т. д.), вам «необходимо» увеличивать версию пакета. Альтернативно вы можете удалить пакет из своего глобального каталога пакетов, но если кто-то еще восстановил более раннюю версию пакета, NuGet не будет загружать более новую копию на свой компьютер, если он также не удалит пакет локально.
@zivkan см. пункт 3 в разделе «Я пробовал следующее:».
Вы упомянули, что получили только одну «ошибку», проверили ли вы, что не было предупреждений о разрешении пакета? Иногда возникают проблемы, которые не останавливают сборку на этом этапе, но приводят к ошибкам позже. Это может помочь повысить детализацию выходных данных сборки, чтобы получить больше информации о разрешении эталонных сборок.
@Craig Я тоже ценю твой вклад. Я использовал инструмент обновления .NET для временного перехода на проект SDK, чтобы посмотреть, будут ли мои выходные данные более отражать причинную проблему. Когда я попытался выполнить сборку, были обнаружены понижения версии пакета, которые я пропустил ранее; Поэтому я отменил свои изменения через git, а затем понизил ссылки на свой пакет nuget. Когда я приступил к сборке, я столкнулся с несвязанной проблемой, поэтому сейчас ее ищу. Я обновлю, как только решу эту проблему. Всем спасибо за ваш вклад, они помогли мне получить больше информации.
Ответы 1
Во-первых, я не сам пришел к такому решению. Комментарии сообщества действительно направили меня в лучшем направлении и привели к этому решению. База кода, к которой я пытаюсь добавить функциональность, устарела и содержит много ссылок на старые версии пакетов NuGet (опять же, мы работаем над их обновлением).
Теперь я могу строить, потому что сделал следующее:
- Убедился, что нахожусь в ветке git-репозитория основного приложения.
- Использовал .NET Upgrade Assistant для перехода на формат .NET SDK.
- Попытка сборки (при этом изменилось выходное сообщение, которое мне предоставила Visual Studio, в котором говорилось, что обнаружено два обновления пакета).
- Вернул устаревшее приложение через git.
- Пересобрал устаревшее приложение, чтобы убедиться, что сборка прошла успешно.
- Microsoft.Bcl.AsyncInterfaces и System.Threading.Tasks.Extensions понижены до версий, найденных в устаревшем приложении.
- Увеличена информация о сборке моего пакета NuGet.
- Запустил пакет NuGet в каталоге пакетов nuget через терминал Windows.
- Ссылка на новую версию пакета NuGet в устаревшем приложении.
- Успешно создали устаревшее приложение
- Добавил свой код
- Успешно создано устаревшее приложение с кодом, который ссылается на пакеты NuGet.
Спасибо всем за вашу помощь, и особенно Крейгу за указание направления, которое привело к созданию packageref и packages.config. Это заставило меня задуматься об использовании Помощника по обновлению, чтобы посмотреть, будет ли результат отличаться, и так оно и было. До перехода Upgrade Assistant на .NET SDK я видел единственную ошибку для каждого экземпляра вызова моего пакета NuGet, который имел один и тот же набор слов (не найден или недоступен), и это меня смутило.
Спасибо всем за внимание, участие и помощь. Это подтолкнуло меня к следующему шагу!
Является ли пакет NuGet общедоступным? Если да, можете ли вы сказать нам, какой именно, и какой фактический класс и метод вы пытаетесь использовать?