I'm writing a C# class library for net461 that is consuming a NuGet package. The package adds two assembly references to my project as these are the ones you normally need. But in this special case, I also need to reference a third assembly inside the package. I can easily do this by pointing to the folder beneath Packages folder, but that will give me a version-dependent hint path that will break next time the consumed package is updated.
How can I avoid this scenario? I cannot seem to find any way in VS2017 to do a "deep" assembly reference into the referenced Nuget package...
I am also the author of the consumed package, so I could expose the third assembly as as well, but that would pollute the 99% other projects only needing the two first assembly references.
Thanks in advance
Ulrik
Create another nuget package that references your existing nuget package as a dependency. Then add the additional assembly reference in what is basically a wrapper package. Consume that instead.
Or
Create a copy of the nuget package that includes the assembly reference and add a suffix to the package name. Only issue is you will have to publish two packages whenever you change it. Not sure if it will matter when you have projects using each in the same solution as the dlls should match.
Or
Just include the assembly as a reference and pollute the other projects. I don't think it will hurt.
Related
Visual Studio 2019.
I have several assemblies in my projects.
Assembly A (nuget package),
Assembly B - references to assembly A and use some classes from it,
Application C - references to Assembly B and use code that inside using code from assembly A,
When building, output for assembly B contains assembly A, but application C doesn't contain assembly A.
Is any change to get assembly A goes to output folder for application, without referencing it directly?
When netfx projects using packages.config reference a netfx shared library, the relevant references are copied across to the netfx project since the dlls are packaged with nuget. Netstandard, however, does not include the dlss in the package but expects the top-level project to read the nuget references and get them itself.
When using packages.config, this doesn't work so the references are missing. If you are using package reference, then it does work.
The solution is either to not use netstandard (which would be a shame); reference the missing nugets directly; or ideally, change your project to package reference, if you can, so it works.
Right-click packages.config and "Convert to package reference"
I'm a newcomer to .NET world, and at this point I'm super confused about the packages, references and how to reference them in my c# project.
I have 3 project in my solution:
DataAccess - which contains the logic for accessing data, the mapping between DTOs and entities, etc.,
DataAccessTest - contains unit tests for DataAccess project,
Service - wraps the DataAccess project into a Windows service.
Now, DataAccess project references AutoMapper (among others) to help with data transformation. It's included in <PackageReference /> element in the csproj file. It seems to be working fine when I'm doing dotnet restore, however dotnet build fails when trying to resolve the namespaces! The same goes for JetBrains Rider - it doesn't find the namespaces until I explicitly reference them in <Reference>!
Not sure if related, but the same goes for the dependent projects. For example, DataAccessTest references the DataAccess project - so that the test will run. However, it still requires adding the transitive dependencies (for example AutoMapper), on top of the project reference.
Is this the intended behavior? Do you need to keep both <PackageReference> and <Reference> for project to compile correctly?
In C# you Have to take care about referencing to other projects. if one project has been referenced to other project, the other project couldn't use or reference to first project. if you did, it will gives you compilation Error.
You need to install Nuget packages for each project that references methods in that package. So, if only your DataAccess project requires AutoMapper, it should be sufficient to add the Nuget package to that project. The solution is not much more than a wrapper around a bunch of projects. You should be able to publish a project separately. The project will take care of its own dependencies. It is hard to find out what goes wqrong. It may be helpful if you create a small testproject, e.g. create an empty console project and a DataAccess Library. Then you add a Nuget package to your DataAccess library and copile all stuff. In this way you can try to find out what is goning wrong. Make sure to install the Nuget Packages for the correct project (I got this wrong several times before I discovered how it really worked).
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.
I'm getting my knickers in a twist with 'project' versus 'package' (ie Nuget package) references in asp.net 5.0. I'd really like for someone to explain a bit more fully the way references are pulled in in asp.net 5.0. How does a 'dnu restore' determine if something is a project reference rather than a package reference?
I had thought that a reference would be pulled in as a project if the projects were in the same directory, but this is clearly not the whole story. It does appear that you can have a deeper directory nesting and still pick up the project reference.
Here is an outline of my common project structure:
I've got a set of projects, some of which reference one another. There are libraries called TextHelpers and MathHelpers and a project called MainProject. The libraries live in a folder called Libraries, and the MainProject lives in a folder called Tools. This separation is necessary as Libraries and Tools belong to different Git repos:
Root/Libraries/TextHelpers.Project1 - version 1.0.0-*
Root/Libraries/TextHelpers.Project2 - version 1.0.0-*
Root/Libraries/MathHelpers.Project1 - version 1.0.0-*
Root/Libraries/MathHelpers.Project2 - version 1.0.0-*
Root/Tools/MainProject - version 1.0.0-*
Usually MainProject references the libraries as Nuget packages from a private Nuget repository (just a folder on the file system) which serves the libraries.
While I'm building MainProject, however, sometimes I need to make a change to one of the library projects, or sometimes I'd like to step into the files without using a Nuget symbol server. For this reason, I'd like to switch to referencing the (live) projects rather than from the (static) Nuget packages. How would I do this?
I've discovered this much so far: if I have a global.json file, a 'dnu restore' creates a project.lock.json with 'project' rather than 'package' references. Is this the whole story?
dnu and dnx look in the following folders:
The folder where the current project is (that means the parent folder of the folder containing the project.json of the current project). E.g. if you have repo/src/project1/project.json it will look in repo/src
Any other folder included in global.json
Then the algorithm is really naive: if it finds a folder with the name matching the package in any the folders mentioned above it will assume those are the sources for that package.
For example, if you have
src/P1/project.json
src/System.Collections/project.json
and in src/P1/project.json you have a reference to System.Collections, it will use src/System.Collection instead of the NuGet package System.Collections. Projects take precedence over packages.
Caveats:
Since the algoritm looks in the current folder and everything in global.json you might be able to reference some projects from one folder but not another. If in my previous example you'd add a test/T1/project.json project but src is not in global.json then the projects in src will reference System.Collections the project while T1 will reference the package (installed in the global packages folder).
There's no verification to see if the project reference is actually that package. If the name matches, it's a match. So an empty project could replace any package.
If you have multiple project with the same name you can get in trouble.
Hope this helps and answers your question.
Side note: with dotnet (the tool replacing dnx) you can specify for every reference if you want the project or the package to have higher priority.
I'm curious how others do it, or if there's an easier way...
I'm having multiple projects which are referencing the same DLL i.e. nhibernate.dll.
Those dlls are stored in version folders like NHibernate-3.2.0.
If a new version comes out and we are going to upgrade to it, we create a new version folder and need to update all referencing projects to the new dll.
Is there some easier way to do that? Like some central project (lets call it REF_PROJ) which references nhibernate and all other projects are only referencing REF_PROJ?
So the updating of the new version has only be done at one central place, the REF_PROJ.
Your solution is one way. The "better" way IMHO is to use nuget packages. Specifically the nhibernate nuget package. Then you can right click on the solution and update all the nhibernate packages when a new version comes out.
EDIT: To add to the other answer. If you wish to use a specific version of the nuget package that targets a particular version of the assembly in the package, use --version when you install them from the package manager console.
Just have a root folder, not version specific. Or if you really need version specific, then have 2 copies - one in the root folder and one in a version specific folder.
here is an example of what i mean.
nhibernate
--> nhibernate 3.2
----> nhibernate.dll
--> nhibernate.dll
Another solution is to using the GAC
register your assemblies into gac, and add reference to it from multiple projects without specifing assembly version . and update it easy with gac util.