I'm writing API system tests for one big system that referenced nuget package dll from another our system. What I'm going to achieve is to replace this package with fake one. It helps to avoid test both systems together and do it separately. But how can I do it. Can I change nuget source depends on config transformation for instance? Or some another way to do it?
There are a couple of ways to do this and I would recommend not changing your config files using transforms.
In your tests you can specify a new repositoryPath in nuget.config that points to a separate packages folder if you are using packages.config. If you are using project.json you can use the glocalPackagesFolder property.
In this new packages location, you can drop in the the fake package with the same package id and version and the application under test would pick the fake package from there. This way you dont really have to modify your source code. For more information around your nuget.config, check out the documentation here
Related
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.
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.
I need to create csproj file that will be usable as project reference in VS2013 and will output prebuilt binary as it's "Build" result.
We use referenced projects for build, however company policy doesn't allow access to some of that projects for everyone. As a result projects need to be updated manually to make them build. This is really a major inconvenience when switching branches and when making edits to project files, so I want to create dummy project that will be bound to pre-built binaries as their "output" and will be placed instead of real projects.
EDIT: Moving that assembly to Nuget package is not an option for now since Nuget has some issues with dev flow (when you need to debug/test/develop package). I saw some VS extension that implements switching between Nuget package and local project which might solve this issue, but I'm not sure if it will be accepted and want to explore other options.
To be clear - the thing I want to avoid is editing project in any way, so that project can be built cleanly after pulling it from Git, and I don't have to clean it every time before commit.
I haven't properly tested it, but the solution seems really simple (if I understand the question properly).
Just add this to the existing .csproj, overriding the Build target to just give the path to the pre-built assembly.
<Target
Name="Build"
Returns="$(TargetPath)" />
This assumes the TargetPath property already defined, and it should automatically be if you're modifying the original .csproj. Otherwise just define it yourself in a <PropertyGroup> before the Build task.
Note that having TargetPath defined is important for the ProjectReferences in your own project to resolve.
How about having those restricted (binary only) projects reside in an internal Nuget package feed, so that Nuget can install the packages as needed, on build?
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 :-)