I have added one of the package in the project through the nuget. The package automatically added a couple more packages to my project. I know those packages were dependent to the installing package. If I later on don't need the installed package, how do i safely remove the rest of the packages which dependent to it or does xamarin studio provide the command that can clean up those dependency.
E.g I installed the Google.Apis.CloudSpeechApi.v1beta1. It install the System.IO, System.Net and other System packages at the same time. If I removed the CloudSpeechApi package, those System packages still sitting in my Packages folder and not get cleaned up as well.
Related
I am trying to reference from a .NET Core 3.1 project, a NuGet package that targets only net40 via the NuGet compatibility shim. The package is added to my project, however the net40 dependencies are not.
The package is structured as:
lib\
net40\
AssemblyA.dll
nuspec:
<dependencies>
<group targetFramework="net40">
<dependency id="PackageB" version="1.0" />
</group>
</dependencies>
Visual Studio's Package Manager lists the dependencies, but when installed, the dependencies are not listed by VS' Preview Changes window and are indeed not installed. PackageB also targets net40.
It does work if I:
Include the dependencies in an "Any" (blank) dependency group as well as under net40
Remove the net40 dependency group and list the package directly under <dependencies> as a flat list
Remove the net40 under lib\ and use a flat list
These are not ideal as it obfuscates the true nature of the targets frameworks. The last two produce NU5128 on pack. For future reference, I should mention that it's required to remove the dependencies from the local cache for even these scenarios to work (surely a bug?).
Any ideas on how to pull dependencies from such packages? Is this simply not supported? A good test example of this is the "Polly.Net40Async" package.
(VS: 16.6.5, dotnet: 3.1.302, PackageReference, Windows 10)
I am trying to reference from a .NET Core 3.1 project, a NuGet package
that targets only net40 via the NuGet compatibility shim. The package
is added to my project, however the net40 dependencies are not.
The nuget package only targets to net40 which means the package is used for net framework 4+.
And by default, Net Core projects cannot use this type of nuget unless the package and dependencies are listed as supporting Net Core or Net Standard.
==========================================
Also, you can notice the info from the Polly.Net40Async nuget package:
group targetFramework="net40" means that if your project targetframework version is 4+, it will install the listed dependencies.
So you should not install this type of packages into Net Core 3.1 project. And it is designed by the author.
Besides, if you change the sub folder of lib in the nuget package to any, you can add the dependencies into the Net Core project.
After all, any means it targets to any framework versions--net core, net standard, net framework. And you just need to remove the condition of the dependency (contention on Net Framework 4+).
====================================
Add more detailed info
Update 1
Actually, Net Core projects can install some nuget packages which only targets to Net Framework.
In my side, the package can be installed in the Net Core project.However, there is a warning which shows it may not be fully compatible with your Net Core project. Although you can use it, there are still some problems just not encountered in special situations.
For the dependencies, since your project targets to Net Core rather than Net Framework, the dependencies will not be installed automatically along with the main package. But you can manually install these dependencies separately through Nuget Package Manager UI.(search them and then install them one by one).
And if condition group targetFramework="net40" is met, it will install these dependencies automatically along with the main nuget package. But since your project targets to Net Core, it will not install them automatically.
As a suggestion, you could search these dependencies on the Nuget Package Manager UI, and then manually install them separately.
I've created a windows service that uses Microsoft Visual Studio Installer Projects to install the service. The service was running fine until it needed the references from the Nuget package Microsoft.SqlServer.SqlManagementObjects
How do I add this package to the setup project so the references are available or can I simply install the nuget package on the target machine?
How do I add this package to the setup project so the references are available or can I simply install the nuget package on the target machine?
Since nuget does not support the setup project, so we could not add that nuget package to the setup project directly.
To resolve this issue, the most direct method is manually add the .dll files in nuget package to the setup project (Right click the setup project->Add->Assemble...->Browse).
If manually adding the .dll file is not what you want, you can add a blank library project to the setup solution, then add the that nuget package to the library project.
Add the Project Output of the library project to the setup project (Add->Project Output...->Primary output):
In this case, all the .dll files in the nuget package are available for your setup project.
Hope this helps.
I modified a solution and deleted one of the .csproj files and instead packaged the .dlls into a NuGet package. Then I added the package to the two other .csproj files that reference the .dlls. All was good - it builds locally, but I can't get it to build on the build server. When I look at the code gotten out of TFS for the build I see that the packages.config for both projects have the correct reference to the NuGet package, but when I open the solution in VS the references have little yellow exclamation marks next to them because they're broken references. The only way I can get it to build is to open the NuGet CMI and execute Uninstall-package package-name and the Install-Package package-name. Then the references are good. When I look in the packages.config of the main project it contains the correct reference to the Package. So I've given up on getting TFS to correctly grab the package, but since Install-Package and Uninstall-Package are CMI commands only I can't automate that (or can I)? Does anyone know if a way that I could automate that to happen after the source is pulled from TFS but before the build?
The yellow exclamation marks issue should be related to the reference path. When you download the source from TFS to another location, the system cannot find the references as the original reference path changed.
So, you need to reinstall the package, you can use the NuGet command line in the Package Manager Console:
Update-Package -reinstall
since Install-Package and Uninstall-Package are CMI commands only I can't automate that (or can I)? Does anyone know if a way that I could automate that to happen after the source is pulled from TFS but before the build?
The simple answer is you can not automate that. You can use the command Install-Package and Uninstall-Package to reinstall the packages to your project in the Package Manager Console, but it seems impossible to automate that. Please forgive me for the lengthy explanation below.
First, we need to know the different the operation Install packages between NuGet CLI and Package Manager, although NuGet CLI and Package Manager both support the operation Install packages.
The operation Install packages on NuGet CLI:
Obviously, NuGet will not reinstall the references when you using the Install-packages operation on the NuGet CLI, just download the package to the packages folder. See NuGet CLI referenceļ¼
The install command does not modify a project file or packages.config;
in this way it's similar to restore in that it only adds packages to
disk but does not change a project's dependencies.
Conversely, operation Install packages on Package Manager:
Installs a package and its dependencies into a project.
If you want to automate that, you have to do this operations via NuGet CLI. Since Install package on NuGet CLI will not modify the reference of project, so we could not automate the operation install package to update the reference of the project.
Besides, we also do not recommend you automate that. Once you have automate that, NuGet execute the uninstall/install operations every time before you build the project. We only need to do an uninstall/install the operation after get the project from TFS. Even we do not need to do this operation if the references of the project are not broken after NuGet restore. So according to the reference of the project to determine whether or not to use an command:
Update-Package -reinstall
in the Package Manager Console should be the best choice.
Is there any way, when installing a NuGet package. to not attach it to a project? E.g. if the package is content-only, I just want to install it per solution, not per project.
I wish to set up my NuGet dependencies such that:
Anyone checking out the project (i.e. other developers) will get the correct dependencies.
Anyone using my package will get the correct dependencies.
In VS2013 my NuGet dependencies are specified in packages.config
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="log4net" version="2.0.3" targetFramework="net45" />
</packages>
I noticed that you can also specify dependencies in the .nuspec file (much like a maven pom file) but this doesn't seem to be used by the package manager plugin.
<dependencies>
<dependency id="log4net" version="2.0.3"/>
</dependencies>
What is the correct way to configure dependencies and why?
The packages.config file lists all the packages that are currently installed for a given project. This includes any dependencies. NuGet will automatically update this file any time you add, update, or remove packages from your project, either through the NuGet UI or Package Manager Console (e.g. Install-Package log4net).
NuGet will automatically install any dependencies for a given package. NuGet will also follow the dependency chain for each of these other packages, until all dependent packages are installed. It will add these packages to the packages.config file to show that they have been installed. So you may initially install one package, but 10 packages may end up being installed based on all the dependencies. Again, this will be reflected in the packages.config file, which you shouldn't touch.
You do NOT need to edit this file.
The only way you should update packages.config is by installing or updating packages via the NuGet UI or Package Manager Console. Do not edit this file by hand.
EDIT: Add section about package restore
The packages.config file is also used by NuGet to restore packages (Automatic Package Restore) that do not exist on the user's hard drive. This is useful since you do not have to commit the packages folder to source control. So when another developer checks out your project, NuGet will automatically download any packages listed in packages.config before building. NOTE: This is not the same as installing packages. It is assumed that you've already used NuGet to install the package, which will update project references, add files, modify .config files, etc. Those changes should already be committed. All package restore does is download the binaries as if they were also committed, without bloating your repository. Package restore is mainly used for other developers building your project from source code. It is not applicable for installing a package you create, which is what the .nuspec file is for.
The .nuspec file is used when you are creating your OWN packages for others to use. The <dependencies/> section lists the packages YOUR package needs. When a developer installs YOUR package, NuGet will automatically install any dependencies listed in your .nuspec. Just like above, NuGet will follow the dependency chain by looking at each packages .nuspec file to see what dependencies it requires.
So unless you're CREATING a package, you do not have to worry about .nuspec files.
As you can see, NuGet uses the .nuspec file in each package to determine if there are any dependencies. Installing a package will update the packages.config files.
TL;DR: packages.config and .nuspec files are different things although somewhat related.