W przypadku często zadawanych pytań dotyczących NuGet.org, takich jak pytania dotyczące konta NuGet.org, zobacz NuGet.org często zadawane pytania.
Wszystkie informacje dotyczące interfejsu użytkownika i narzędzi wiersza polecenia są dostępne w przewodniku Instalacji.
Narzędzie wiersza polecenia, nuget.exe
, kompiluje i działa zwykle w systemie Windows. Program NuGet może działać w systemach operacyjnych Unix przy użyciu polecenia mono
, ale nie jest oficjalnie obsługiwany przez zasady pomocy technicznej nuGet.
Firma Mono przeniosła własność do firmy Wine i nie jest już utrzymywana przez firmę Microsoft.
Podstawowym źródłem informacji o pakiecie jest jego strona listy na nuget.org (lub inny prywatny kanał informacyjny). Każda strona pakietu na nuget.org zawiera opis pakietu, jego historię wersji i statystyki użycia. Sekcja Informacje na stronie pakietu zawiera również link do witryny internetowej projektu, w której zazwyczaj można znaleźć wiele przykładów i innej dokumentacji, aby dowiedzieć się, jak jest używany pakiet.
Aby uzyskać więcej informacji, zobacz Znajdowanie i wybieranie pakietów.
- Program Visual Studio w systemie Windows obsługuje interfejs użytkownika Menedżer pakietów i konsolę Menedżer pakietów.
- Visual Studio dla komputerów Mac ma wbudowane funkcje NuGet zgodnie z opisem w temacie Dołączanie pakietu NuGet w projekcie.
- Program Visual Studio Code (wszystkie platformy) nie ma bezpośredniej integracji nuGet. Użyj interfejsu wiersza polecenia NuGet lub interfejsu wiersza polecenia dotnet.
- Usługa Azure DevOps udostępnia krok kompilacji umożliwiający przywrócenie pakietów NuGet. Możesz również hostować prywatne kanały informacyjne pakietów NuGet w usłudze Azure DevOps.
W programie Visual Studio użyj polecenia Pomoc > dla programu Microsoft Visual Studio i przyjrzyj się wersji wyświetlanej obok Menedżer pakietów NuGet.
Alternatywnie uruchom konsolę Menedżer pakietów (Narzędzia > NuGet Menedżer pakietów konsoli Menedżer pakietów>) i wprowadź polecenie $host
, aby wyświetlić informacje o nuGet, w tym o wersji.
Narzędzie NuGet zwykle działa w językach .NET i jest przeznaczone do uwzględnienia bibliotek platformy .NET w projekcie. Ponieważ obsługuje również automatyzację msBuild i Visual Studio w niektórych typach projektów, obsługuje również inne projekty i języki w różnych stopniach.
Najnowsza wersja pakietu NuGet obsługuje języki C#, Visual Basic, F#, WiX, C++i Q#.
Pakiet NuGet ma pełną obsługę różnych szablonów projektów, takich jak Windows, Web, Cloud, SharePoint, Wix itd.
Przejdź do karty Aktualizacje w interfejsie użytkownika Menedżer pakietów i wybierz pozycję Aktualizuj wszystko lub użyj Update-Package
polecenia w konsoli Menedżer pakietów.
Aby zaktualizować sam szablon, należy ręcznie zaktualizować repozytorium szablonów. Zobacz blog Xavier Decoster na ten temat. Należy pamiętać, że jest to wykonywane na własne ryzyko, ponieważ aktualizacje ręczne mogą uszkodzić szablon, jeśli najnowsza wersja wszystkich zależności nie jest ze sobą zgodna.
Tak, narzędzie NuGet działa bezpośrednio z wiersza polecenia. Zapoznaj się z przewodnikiem instalacji i dokumentacją interfejsu wiersza polecenia.
Zobacz Przewodnik instalacji. Aby sprawdzić bieżącą zainstalowaną wersję narzędzia, użyj polecenia nuget help
.
Użytkownik może rozpowszechnić nuget.exe zgodnie z postanowieniami licencji MIT. Użytkownik jest odpowiedzialny za aktualizowanie i obsługę wszelkich kopii nuget.exe, które zdecydujesz się rozpowszechnić.
Tak, istnieje możliwość dodania niestandardowych poleceń do nuget.exe
usługi , zgodnie z opisem w wpisie Roba Reynolda dostępnym za pośrednictwem Archive.org.
Obiekt najwyższego poziomu w modelu obiektów automatyzacji programu Visual Studio jest nazywany obiektem DTE (Development Tools Environment). Konsola udostępnia tę wartość za pomocą zmiennej o nazwie $DTE
. Aby uzyskać więcej informacji, zobacz Omówienie modelu automatyzacji w dokumentacji rozszerzalności programu Visual Studio.
Próbuję rzutować zmienną $DTE na typ DTE2, ale otrzymuję błąd: Nie można przekonwertować wartości "EnvDTE.DTEClass" typu "EnvDTE.DTEClass" na typ "EnvDTE80.DTE2". Co jest nie tak?
Jest to znany problem ze sposobem interakcji programu PowerShell z obiektem COM. Spróbuj wykonać następujące czynności:
`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`
Get-Interface
jest funkcją pomocnika dodaną przez hosta programu PowerShell NuGet.
Zobacz Tworzenie i publikowanie pakietu.
Mam wiele wersji mojej biblioteki, które są przeznaczone dla różnych wersji programu .NET Framework. Jak mogę skompilować pojedynczy pakiet, który go obsługuje?
Zobacz Obsługa wielu wersji i profilów programu .NET Framework.
Zobacz Omówienie pakietów hostingu.
Zobacz Zbiorcze publikowanie pakietów NuGet (jeffhandly.com).
Tak, zobacz wpis Scott Hanselman w blogu Jak uzyskać dostęp do NuGet, gdy nuget.org jest w dół (lub jesteś w samolocie) (hanselman.com).
repositoryPath
Ustaw ustawienie przy Nuget.Config
użyciu polecenia nuget config -set repositoryPath=<path>
.
Ustaw wartość disableSourceControlIntegration
in Nuget.Config
na true
. Ten klucz działa na poziomie rozwiązania i dlatego należy go dodać do $(Solutiondir)\.nuget\Nuget.Config
pliku. Włączenie przywracania pakietu z programu Visual Studio powoduje automatyczne utworzenie tego pliku.
Zobacz Włączanie i wyłączanie przywracania pakietów.
Dlaczego otrzymuję komunikat "Nie można usunąć błędu zależności" podczas instalowania pakietu lokalnego z zależnościami zdalnymi?
Musisz wybrać źródło Wszystkie podczas instalowania pakietu lokalnego w projekcie. To agreguje wszystkie kanały informacyjne zamiast używać tylko jednego. Przyczyną tego błędu jest to, że użytkownicy lokalnego repozytorium często chcą uniknąć przypadkowego zainstalowania pakietu zdalnego z powodu zasad firmy.
Mam wiele projektów w tym samym folderze, jak mogę używać oddzielnych plików packages.config dla każdego projektu?
W większości projektów, w których oddzielne projekty działają w oddzielnych folderach, nie jest to problem, ponieważ NuGet identyfikuje packages.config
pliki w każdym projekcie. W przypadku pakietów NuGet 3.3 lub nowszych i wielu projektów w tym samym folderze można wstawić nazwę projektu do packages.config
nazw plików, używając wzorca packages.{project-name}.config
, a pakiet NuGet używa tego pliku.
Nie jest to problem podczas korzystania z funkcji PackageReference, ponieważ każdy plik projektu zawiera własną listę zależności.
- Dodaj
https://api.nuget.org/v3/index.json
do listy źródeł lub - Usuń
%appdata%\.nuget\NuGet.Config
(Windows) lub~/.nuget/NuGet/NuGet.Config
(Mac/Linux) i pozwól nuGet na jego ponowne utworzenie.
Przeprowadzono migrację do elementu PackageReference, dlaczego kompilacja kończy się niepowodzeniem "Ten projekt odwołuje się do pakietów NuGet, których brakuje na tym komputerze".?
W projektach packages.config po zainstalowaniu pakietu z elementami build
props lub targets nuGet doda EnsureNuGetPackageBuildImports
element docelowy, aby sprawdzić, czy zawartość msbuild pakietów została zaimportowana przed utworzeniem.
target
Jeśli element został zmodyfikowany ręcznie, narzędzie NuGet może nie być w stanie wykryć, że wymaga usunięcia podczas migracji.
Jeśli projekt jest PackageReference
i nadal masz ten element docelowy w pliku projektu, należy go bezpiecznie usunąć.