A little background. I'm relatively new to the NuGet package manager system, but so far I have installed a few packages.
The question I have regarding NuGet is how do we know how to reference the installed package using the using directive?
I know that NuGet packages have a descriptions in the NuGet package manager. However, they don't always show how to import the packages. So I mostly end up Googling for examples of the package that I install to see if there is an example that shows what the using directive is to import that package.
Recently I have installed the package Selenium.WebDriver.PhantomJS.Xplatform I have difficulty finding examples online that show where the package resides and how to import it.
The problem is that a NuGet package can contain zero or more assemblies that can be added as references to the project in which you install it. So there is no one-on-one relationship between packages and assemblies; neither is there between namespaces and assemblies (an assembly can contain multiple namespaces, or the same namespace can be used by multiple assemblies), so neither is there between package names and the names of the assemblies therein nor the namespaces therein.
So: you have to know what you're doing. There is a reason you chose to install Selenium.WebDriver.PhantomJS.Xplatform. Somebody must have told you to, or you must have read it somewhere that you should do that.
When you do come along a situation where you hear or read "You should install package Foo!", then that source should also give you examples for how to use the types contained within those packages. And that's where you should read which namespaces to import in order to do so.
Some libraries also don't need any code to function; they're plugin-like additions to other libraries that you should already have in place in order to use them.
Usually nuget packages have a github repository or maybe a website.
Sometimes you can find examples, sometimes you have to go through source code.
I went to their Github repository and found that one of the namespaces they use is: OpenQA.Selenium.
You can check their source code here.
when I put that using directive it tells me The type or namespace
name...
All above describes the details about how to know using directive, so add some details to clarify why nuget not responsible for it, what in VS responsible for it and what the Intellisense(the option ) can do for us.
NuGet packages how to know their using directive?
Nuget in VS is just a Package Manager, it won't know the using directive.
For the most nuget packages, they contain at least one assembly, when you consume the package, actually you add reference to the assemblies from the package. So it's equivalent to that you have some assemblies developed by someone, then you reference them locally(add=>reference=>browse) in your project. So in this situation Nuget won't know how to use the assemblies with using...
(Here we just talk about the assemblies in package, nuget package has much more advantage from its install.ps1,build content...)
What actually do this in VS for you is Intellisense, it's responsible for recognizing your using statement in code editor,and help provide quick-info suggestions.(add using namespace,import reference...)
The function you're talking about is Intellisense, not Nuget, and Intellisense is used to check if your using directive is correct, it will search whether the namespace you use exists in referenced assemblies, but it will only display wrong(if can't find) or right, it won't tell you how to use the assemblies and what namespace defined in them! That's something you need to go through source code or research the example, like Vyacheslav and CodeCaster answered.
Related
I have two packages installed, and both contain the same precompiled assembly file. This causes an error in Unity and I have no idea how to resolve this issue. Both files are necessary for the packages to function, so deleting them is not in question. How should I resolve this error?
I've forked one of the packages and attempted to rename the DLL file and re-add everything into the Assembly References section of the Assembly Definition Import file - however, one version of the DLL file is 3.8.0.0 while the other is 3.15.0.0.
The DLL file is Google.Protobuf.DLL
Many thanks.
Welcome to the Dependency Hell =)
If we are talking about how to resolve this - don't think there is some easy solution =/ I can suggest several options but both are not perfect at all.
Let's say that package A requires protobuf v3.8.0.0 and package B requires protobuf v 3.15.0.0.
First of all, you can try to check older releases of package B to try to find one with protobuf v3.8 dependency instead of v3.15. Or, vice versa, try to find newer release of package A with v3.15 dependency instead of v3.8. If you are lucky enough - it can help.
If package A or package B has source code available (for example, it is a git repo), you can try to adapt it to another version of the protobuf library manually (create your custom version or even make a pull request to the package repo). But this variant can cause future problems with package updates as you will have to support your custom changes.
I used to have nuspec for my library. There I had roslyn analyzers package added using <dependency/>. The package is not required for the lib itself. It is needed for the library clients only. Now I use new sdk-style project. The only way to add nuget dependencies there, that I see, is to use <PackageReference/>. But that will install the package to the lib itself too. And in my case it breaks the project because analyzers are designed for the clients only. Is there any way to force some package for the clients but avoid for the package. The only option that I see tight now is to use NuspecFile but I want to get rid of nuspec.
I do not think, that this is possible with packages references, because it contradicts the concept of dependencies. If your project does not depend on a package, then it is by design not a dependency, especially not if it is only used by clients or it must not be included into your project. It is the responsibility of the client to use the package or not.
I want to force the installation because it contains compile-time checks to avoid incorrect usage.
There is no need for your library to include the package, because there is no dependency. It is an option to help avoid incorrect usage. I think that it would be more resonable to let clients choose themselves, whether or not they want to use Roslyn analyzers or not. Keep in mind that there are other analyzers, too, and not everybody might be able to use yours or even want to use yours, but you can recommend it on your project site.
The reason why you can add unused dependencies to NuSpec files is that there is no way for the package manager to know if the package is used anywhere, since there is no build environment or compiler that can check it. It is more of a loophole by design and you may not rely on that.
I'm creating a Visual Studio Project Template and bundling it inside of a VS Extension. I need Projects created from the Template to reference ~20 NuGet packages.
Is it possible to have the references resolved from nuget.org rather than having to include all of the references inside the VSIX?
The NuGet documentation on Visual Studio Templates provides instructions on how to add packages inside the VSIX, but it requires the file be stored locally on disk and the .nupkg is bundles inside the vsix:
Add your nupkg files as custom extension content in your source.extension.vsixmanifest file. If you're using the 2.0 schema it should look like this:
<Asset Type="Moq.4.0.10827.nupkg" d:Source="File"
Path="Packages\Moq.4.0.10827.nupkg" d:VsixSubPath="Packages" />
Question already asked
I know a similar question was asked (Creating a Visual Studio Project Template that already includes a Nuget Package Reference?) and answered (not possible), but this was asked in 2011.
5 years later, is it still not possible?
Since there is still no Built-In functionality to Install/Upgrade packages from online Repo, here is a small workaround wich might help:
Prerequisites
First, install the NuGet.VisualStudio nuget package into your project.
You get that from here
When installed, the package will automatically set the Embed Interop Types property of the assembly reference to True. The reason it does so is to make your code resilient against version changes when users update to newer versions of NuGet.
For the same reason, you must NOT use any other types besides the above interfaces in your code. You must NOT reference any other NuGet assemblies either, including NuGet.Core.dll.
After setting up all that stuff, you can do the following in your RunFinished-Method:
var componentModel = (IComponentModel) Package.GetGlobalService(typeof(SComponentModel));
IVsPackageInstallerServices installerServices =
componentModel.GetService<IVsPackageInstallerServices>();
if (!installerServices.IsPackageInstalled(project, "Newtonsoft.Json")) {
var installer = componentModel.GetService<IVsPackageInstaller>();
installer.InstallPackage(
"All",
project,
"Newtonsoft.Json",
(System.Version) null,
false);
}
Note
That example shows based on Newtonsoft.Json how you can install a package.
For sure you can choose the projects targeting the installation. Also you can determine the Version to be installed.
It seems a bit uncomfortable, but unfortunately there is no other way around.
Usings
using Microsoft.VisualStudio.ComponentModelHost;
using Microsoft.VisualStudio.Shell;
using NuGet.VisualStudio;
Let me know if that helps!
Yes, you can create a nuget package and add those other packages as its dependencies. Then when you download that package it will get all its dependencies and add to your project.
So, I have a class library that I know will be used by websites and I need to access the config settings. I added a reference to System.Configuration, but I cannot find ConfigurationManager in the class library. A couple of things, one when I added a reference to the System.Configuration, it shows up as "System.configuration" with a lower case 'c', which I thought was odd. Another thing, when I access System.Configuration, the closest thing to ConfigurationManager is "ConfigurationSettings". I viewed the properties of the reference in a web app that allows me to use ConfigurationManager and this class library and they both point to the exact same file. Do I need to do this another way?
Here is a SS of my reference to it:
See https://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager%28v=vs.100%29.aspx
It lies in System.Configuration namespace and assembly System.Configuration. Make sure you go to Framework tab in Add references and select System.Configuration
As of Visual Studio Community 2017, I was not able to find the DLL using any of the methods that are listed here in this answer nor in any of the more antiquated responses on this site or others.
I had to find this NuGet package, which was a little nerve-wracking for me as I've never used NuGet, and then installed it using NuGet which is shipped with Visual studio.
You can install version 4.4.1 via the command line using:
Install-Package System.Configuration.ConfigurationManager -Version 4.4.1
Or, by searching for "System.Configuration.ConfigurationManager" in the Nuget Package Manager.
For me, I was getting this even with the reference added. I tried shutting everything down and re-opening the project and still it wouldn't resolve what I had typed in.
Finally I just deleted my lines of code and typed in the fully qualified "System.Configuration.ConfigurationManager.AppSettings", and it "found itself". No real explanation for why that worked. It even figured out that the "using" reference at the top of the code was there so I didn't need to qualify it any longer. Weird!
I think it just comes down to some quirkiness in VS when doing some references. No real explanation to it.
I'm trying to figure out what the best way to handle this scenario is.
Let's say I have a library that's referenced by multiple different non-related solutions, let's call it WebServiceInterface.dll. This library has a dependency on JSON.NET.
Before NuGet
The JSON.NET binary was referenced via a SVN external in the WebServiceInterface project. Other solutions which had a dependency on WebServiceInterface referenced the project (also as an SVN external) and as a result pulled both the project, and it's dependencies.
With NuGet
I haven't figured out how to force the JSON.NET reference to be stored under the WebServiceInterface project (as opposed to the RandomSolution\packages location). I found reference # nu-get to project-level and solution-level pacakges, but I can't seem to find out how to specify this when I add a dependency via nu-get.
The goal here is that when someone checks out WebServiceInterface and adds it to a new solution that it builds (instead of having broken references to JSON.NET which point to the packages directory under whatever the last solution was that checked in).
When I went to find out if Chris B had created a NuGet issue for this, I couldn't find one. EDIT: He did, see his comment below. But I did find a semi-documented feature of NuGet that I used to solve this problem: Allow specifying the folder where packages are installed
Let me break this question into 2 issues:
getting NuGet to allow for multiple solutions to use the same packages location
getting the NuGet packages to automagically fetch from source control when you include a project that has NuGet packages
Problem 1:
By default NuGet stores packages in a packages folder in the solution's folder. To change that location, create a nuget.config file in the solution's root folder with the following contents:
<settings>
<repositoryPath>..\..\..\Utilities\Library\nuget.packages</repositoryPath>
</settings>
<repositoryPath> is relative to your solution; so obviously make it whatever you want. Make each solution have it's own relative path to the same packages folder.
As far as NuGet's flow, from that point, the paths in repositories.config are relative to the folder containing repositories.config, not the solution, so now all projects/packages are managed independent of the solution location.
This allows multiple solutions to use the same packages in source control, and if those solutions use the same projects (that use NuGet packages), those solutions/projects will all be kept in sync no matter which solution updates the package.
Problem 1 completely solved.
Problem 2:
Let me address this from 2 perspectives. This applies to Visual Studio and TFS -- I'll leave SVN for someone else to address.
First: if you have no source code on your drive and do a get of a solution (not a project), I prefer to make it so that you get everything that solution needs to build. There shouldn't be any missing references to go manually grab. That much we can do by adding the package files as solution items. Yes, in each solution. A bit of work, yes, but when it's done the package files will fetch/update from source control automagically.
Second: In a new solution, when you include an existing source control project that has NuGet packages, you have to manually fetch the packages from source control and add them as solution items. At least anyone else getting your solution in the future will automagically get everything they need to successfully build. At least with VS/TFS, this is just the way it is, AFAIK. If projB depends on projA, and you add projB to a new solution, VS/TFS won't automatically grab projA from TFS. You have to do that manually. So then the same goes for dll references (like NuGet packages).
Summary of my solution:
Only one copy of packages in source control for all solutions
Any solution can update packages and all the other solutions will be kept in sync*
* Once one solution updates packages to new paths or file names, they will appear as missing references to the other solutions and you'll have to manually clean that up. But at least you know right where the packages are in source control "(as opposed to the RandomSolution\packages location)."
The packages are always stored at the solution level, so if you install a package into multiple projects, they came from the same place. I don't believe you can configure it so that each project has its own packages folder.
I'm not sure there's a nice way to do what you're trying. You could maybe have a build step on the project that fetches the package, but I don't know how well that will suit you.
I'd recommend posting in the NuGet Issue Tracker to get a discussion going. The people working on it seem pretty active, so it might be something they can add support for in a future version :-)