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.
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 have a solution with an application project (ASP.NET Core) and multiple library projects. I want to separate some of the library projects into a separate solution and turn them into NuGet packages.
With the libraries in the same solution I could of course simply edit something in a library, run the application and see how it works (and debug, if necessary).
However, when I turn the libraries into a NuGet package, the application references the packages from our private NuGet feed instead of the project file.
My question is: is it possible to locally "override" the package reference and use the local source code instead? That way I could still edit the libraries and see the effects in the application. This is a lot easier than having to publish a new package for every small change (especially when trying to fix an issue or implementing a new feature).
DNT (Dot Net Tools) does this. You can specify which packages to switch and where they are.
See the 'switch-to-packages' and 'switch-to-projects' command line switches.
Its a bit fiddley as (when I last tried) you had to create a config file that holds the mapping, and it seems to be easy to break the switching. But its something.
https://github.com/RicoSuter/DNT
I've not tried it, but maybe you can use it to switch to packages on a commit for the build server to work correctly? (Or to ensure the references are correct in source control?)
If you want to use nuget in your project and debug, even modify the source files of the nuget packages, this is not a good choice because you should build the nuget project(generate the new changed dll) and repack it as a nuget package, then reinstall, to enable the changes. It is too complex.
Once you install the nuget, no matter how many changes you make, it’s useless. The nuget installed at this time is the version you made before any changes. No matter how you change it, it is the previous version. The version stays at that timestamp, unless you repackage the project. Generate nupkg and update the nuget version.
So nuget is not a good choice for your situation, you should use ProjectReference.
Directly use the ProjectReference to reference two source projects, build at the same time, and get the changed parts at the same time.
ProjectReference could cross two different solutions.
Add this on the main project:
<ItemGroup>
<!--add any nuget project'csproj file like this to debug its source code-->
<ProjectReference Include="..\xxx\xxx.csproj">
</ProjectReference>
</ItemGroup>
If the proejct is out of the solution, you could directly use the full path of the nuget project's csproj to connect it.
I'm not sure what you mean by "override" but you can always add the library project to your ASP.NET Core solution and reference it like normal project references. A project referenced within a solution doesn't have to be physically placed in the same folder as the solution itself.
This, however, does require that any developer on the project has both GIT repositories cloned locally (given your two solutions are located in separate GIT repos) in order to be able to build the ASP.NET Core solution. But I don't really see that as a downside.
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've tried to look at many of the questions asked here about it, but none is exactly like my set-up.
Also, this issue is NOT directly related to Nuget, but it might be part of the solution.
I have a project which consists of a few solutions. All of the projects in those solutions use the same output path.
Example:
-Root
--Solution1
--Solution2
--Solution3
--OutputForAllProjectsInAllSolutions
I want to use NuGets in those solutions. The problem is if I'll use different version of the same NuGet package in each solution, then the each solution will override it's predecessor's reference dlls.
I was thinking of a solution, but I don't know if it's possible and how.
Something like:
-Root
--Solution1
--Solution2
--Solution3
--PackagesFolderForAllSolutions // can be done with repositoryPath right?
--OutputForAllProjectsInAllSolutions
---NugetPackageVersion1
---NugetPackageVersion2
---NugetPackageVersion3
Is it a possible? Is it a good solution? How to do it?
If not, any better suggestions?
Thanks in advance.
EDIT: I wish I could use 1 solution for all, but it's legacy code, and it has too much complexity.
The setup is 1 source-code repository with multiple solutions.
The real question appears to be "how can I make sure all projects use the same version of a dependency", but it's unclear to me if you proposed using a shared packages folder in order to save disk space. Using a shared folder will not solve the multiple versions problem, you'll just end up with a packages folder with multiple versions of a package, but maybe you want to save disk space, so I'll answer that as a separate question. I'm going to avoid the opinionated 'is it a good solution', but in my opinion the "better solution" you asked for is to migrate all projects to PackageReference and use the solution I give below. Also considering using a single solution, but that's unrelated to nuget package versions.
How can I make sure all my projects are using the same version of a NuGet dependency
Code in multiple source control repositories
If your code is spread across multiple source code repositories, then if your cross-project references are internal nuget packages, the projects that depend on projects from other repos via a nuget package will get external nuget dependencies transitively, so simply avoid upgrading nuget packages in your downstream projects. Upgrading will mean upgrading in your upstream project, generate a new nuget with a higher dependency version, generating a package, then updating the version of your internal package in your downstream project. It's a lot of effort, which is why I dislike having applications/systems spread across multiple source code repositories. There may still be reasons to do it which outweigh the costs, and to me that's what engineering is all about, dealing with trade-offs.
Code in single repository. Multiple solutions, NuGet packages via packages.config
If your code is in a single repository, at least one of your projects use packages.config and your application is spread across multiple solutions, then there's still going to be a reasonable amount of manual work, but the fewer packages.config projects there are, the less work there will be. You could use the method for a single solution application, and do it multiple times for each solution.
One solution, NuGet packages via packages.config
Right click the solution, select "Manage NuGet Packages for Solution", then go to the Consolodate tab.
NuGet packages via PackageReference
If you're using PackageReference, it doesn't matter if your repo has a single solution or multiple solutions. You can create a MSBuild props file with your NuGet package versions. As an example, have a look at this ASP.NET Core example. If you put these properties in a file named Directory.Build.props at the repo root, newish versions of MSBuild should (I've never tested it myself) import it automatically. Otherwise you'll need to edit all your project files to include an import to the props file. Then you edit the project files and change the version to use the MSBuild property. Again, example from the ASP.NET Core repo. Downside is that you can no longer use Visual Studio to update the package versions, but you can still use it to check for new versions and see what the newest versions are.
If your application has multiple repos, and multiple projects are using PackageReference, you can look into putting the props file in a git submodule, or something equivalent for your source control system.
In conclusion
I strongly recommend migrating from packages.config to PackageReference, and then you can use a MSBuild props file to automatically keep all projects using the same version of each dependency.
Can I reduce disk space by using a single packages folder for multiple solutions
Firstly, if all your projects used PackageReference, this wouldn't be an issue because NuGet does not copy PackageReference packages into solution folders, so there's even less disk usage than using packages.config with a shared packages folder, because you're still going to have one copy in the global packages folder and another in the solution packages folder.
But if you can't/won't migrate to PackageReference, then yes, as you asked in your question, you can use a nuget.config file at the root level to set <repositoryPath>packages</repositoryPath> to make all the solutions use the same packages folder at the root level, as long as the solution folders don't have their own nuget.config file that overrides the setting. You can change packages to anything you want, but I discourage using ..\anything because I hate it when projects write files outside of their repository root.
I'd begin with saying that I never had any experience with managing NuGet packages, even the simplest ones. However, I'm planning to use it in my next project, which design could rely on the answers to my question.
For a better understanding of the problem, let's assume we have the following projects, all under one solution:
Core
Foo
Bar
Both Foo and Bar depend on Core, but not on each other.
As such, I'd like to create one nuget package for the Foo + Core combination, and one for the Bar + Core combination, without separating them to different solutions.
Is this scenario possible?
Yes, your scenario is possible. NuGet package creation doesn't depend on the solution the project belongs to.
You can either define your own nuspec file to pack a package or use a csproj file to do so. Look at: https://learn.microsoft.com/en-us/nuget/tools/nuget-exe-cli-reference
Note: NuGet primarily packes .dll files into a package. Even if you use .csproj files, it looks at the and picks up the .dll from that location. You can choose to store the Sourcecode using the NuSpec file though.
For a NuSpec file:
What you want to pack entirely depends on you and you can what goes
in, in the things in a NuSpec file.
For a .csproj file(I think this is what you should use):
Use the nuget pack <nuspecPath | projectPath> [options] command
IncludeReferencedProjects as an option, and projectpath for Foo and Bar individually. This would create two separate NuGet packages
which fulfill your need.