I've got 3 projects in my solution; Api, Tests and Tests.Acceptance. When I bring the solution down from Git the Test and Test.Acceptance files fail to restore.
I've tried adding a .nuget\NuGet.config\ with the following code
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\packages" />
</config>
</configuration>
And while that seems to pull the packages into that folder the actual solutions themselves are not heeding the config.
I have not run a Update-Package -reinstall on the project, is this a necessary step in getting the csproj files to obey the new NuGet.config?
You are right that the HintPath will confuse other users when cloning a project in a few scenarios like an absolute repository path that is specified in a user's nuget config that is not overridden by the project. As long as everyone uses the same repositoryPath - either through a global config or a NuGet.Config file in the solution folder -, this shouldn't be a problem.
If you want to support a wide variety of these configs, I suggest moving off packages.config and use the new PackageReference nuget mechanism in VS 2017 / NuGet 4 where the csproj file itself lists the packages it needs and does not contain any hint paths. Furthermore, a global package cache will be used for all projects. Refer to NuGet's blog post on the integration, especially the section What about other project types that are not .NET Core? (Note that the mechanism is fully supported in the currently released VS 2017 version)
Related
This issue describes in more detail and discusses the problem I was describing in a recent question - a project was in multiple solutions and the <HintPath> was to a local packages directory. So depending which solution was being built, it ran into dependency confusion issues.
Does anyone know of a good workaround? It can't be unusual to have the same project in multiple solutions and it seems crazy that Nuget, which is supposed to help avoid dependency hell, is relying on fragile local paths.
Does anyone know of a good workaround? It can't be unusual to have the
same project in multiple solutions and it seems crazy that Nuget,
which is supposed to help avoid dependency hell, is relying on fragile
local paths.
I think you could change the repositoryPath path in nuget.config file so that the hintpath will uses packages under the global nuget caches rather than copy the packages again under your solution folder. This relieves nuget package dependency.
Open C:\Users\xxx(current user name)\AppData\Roaming\NuGet\NuGet.Config and then add these in it:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="%USERPROFILE%\.nuget\packages" />
</config>
</configuration>
Then restart VS and it will reference the packages directly from the global nuget caches.
Then run update-pacakges -reinstall under Tools-->Nuget Package Manager-->Package Manager Console to uses the new Hintpath.
Besides, use PackageReference nuget management format will avoid this behavior and you will not bother by the complex Hintpath problems. It is a new nuget package management format and much easier.
Right-click on the packages.config file--> migrate packages.config to PackageReference.
And Note that when you migrate into Build Server, and if you only build it by command line, you should run nuget restore xxx.sln to restore these packages. See this link.
In .Net core projects, there is a .csproj file and inside it the first line specifies the SDK you are targeting in that project, similar to:
<Project Sdk="Microsoft.NET.Sdk.Web">
My question is whether it is possible to create a whole new SDK (maybe by extending the Microsoft.NET.Sdk.Web) and then using this new custom SDK in some other projects, in a way that the new project would have something like this in its .csproj file:
<Project Sdk="My.Own.Sdk">
How could something like this be done?
Yes, you can do it for fun, but there is unlikely to be an official support for publishing.
How to: Use MSBuild project SDKs
It shows the how msbuild loads the props and targets, and you can find the SDK.props and SDK.targets file in the .NET SDK installing folder (represented as dotnet, for example C:\Program Files\dotnet on Windows)
What you need to do to create your own sdk is to make a folder inside dotnet/sdk similarly to any other SDKs look like.
And make the SDK.props and SDK.targets files with path dotnet/sdk/<SDK_VERSION>/Sdks/<YOUR_SDK_NAME>/Sdk, as the entry that reference your props and targets to customize your build steps,
If there is any other file needed by convention, create your new one to mimic the existings.
But still, the officially supported way to customize the callers' build steps is to create a nuget package with a convention subfolder build and the props and targets files would be automatically into the project that referenced the package.
Yes, this is definitely possible, and yes, it can be even published. You can find inspiration at Microsoft.Build.Traversal, for example.
SDK is, basically, nuget package, that has two files, Sdk\Sdk.props and Sdk\Sdk.targets.
If you publish NuGet package with such files to NuGet.org, you may then reference it as
<Project Sdk="YourNugetName/1.0.0">
</Project>
Where the 1.0.0 is your version.
For testing, the Sdk may also contain (fully qualified) path to directory that contains the same content as the nuget package, and just running dotnet build consumes the defined SDK, and runs target Build on it.
I'm really new to NuGet and having all kinds of trouble with it. So the latest problem is that I generated a bunch of .nupkg files and put them in a shared folder on the network and then set NuGet up to look there for updates. So let's say in the folder I have:
Author.library.2.1.0.nupkg
Author.library.2.2.0.nupkg
Author.library.2.2.1.nupkg
I then found out that the target framework (.net) is different for some of my projects (under the same solution), so I generated new packages for each target:
Author.library.net40.2.1.0.nupkg
Author.library.net40.2.2.0.nupkg
Author.library.net40.2.2.1.nupkg
Author.library.net45.2.1.0.nupkg
Author.library.net45.2.2.0.nupkg
Author.library.net45.2.2.1.nupkg
Next I right-clicked on the solution and chose Manage NuGet Packages for Solution and then went to Online, pointed to the Installed Packages and was able to install each package to the applicable projects (.csproj files). But now when I open the NuGet Package Manager for the solution and click on Installed Packages, all I see is once instance of library. If I click on it, on the right I can see that it's pointing to the Author.library.net45 package, but I have no way of seeing the .net40 version of the library. So I can't add it to the .40 projects.
And lastly, what if I want some of the projects to point at an older version of a package. I know that I am suppose to be able to specify that in the packages.config file:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Author.Library" version="2.2.0" allowedVersions="
[2.0.0,2.3.0)" targetFramework="net45" />
</packages>
which should load anything above (and including) 2.0 through 2.3)
or
<package id="Author.Library" version="(,2.4.0" targetFramework="net45" />
which should load any version below 2.4.
So my main question is why can't I see the two versions of the package in the NuGet Package Manager? And also, how do I best limit the versions that will apply to a particular library.
It looks like you cannot see the different packages since they both have the same package id of Author.Library. This is based on what you have shown in your packages.config file.
Also I would not have separate NuGet packages just for assemblies that target different frameworks. Instead put them in a single NuGet package in their own lib directory (e.g. lib/net40 lib/net45). You can have multiple assemblies targeting different frameworks in the same NuGet package. NuGet will pick the best match when installing the NuGet package into the project. Also note that you can use a NuGet package that contains just .NET 4.0 assemblies with a .NET 4.5 project since the assembly is compatible.
The allowedVersions attribute in the packages.config file is the thing to use if you want to restrict the NuGet packages that a project can update to.
Ive made a small Application that will be published in a nuget package.
Additional to my C# code i made a little html UI for administrative purposes.
Now i would like this html files to be placed in the new Project Explorer if this is possible?
To build the package ive downloaded the CreateNewNuGetPackageFromProjectAfterEachBuild Package.
Would be nice if someone has an idea how i can solve this.
Best Regards
Andre
You can have content files in a NuGet package that are added to a project. This is documented in the NuGet nuspec reference documentation.
For NuGet version 2 you can use a files element with a Content attribute:
<file src="css\mobile\*.css" target="content\css\mobile" />
This will create a css\mobile directory inside the project when the NuGet package is added.
With NuGet 3 in Visual Studio 2015 update 1 the new recommendation is to use a contentFiles if you need to support the newer project types that use a project.json file. Note that the recommendation is that these files are immutable and are not to be modified by a developer.
<contentFiles>
<files include="any/any/images/abc.png" buildAction="EmbeddedResource" />
VS2013 had a bug where NuGet would add packages as pending changes, even if you told it not to with .tfignore. There was a workaround, but it doesn't work with VS2015/NuGet3, and NuGet is back to its old tricks. Is there a "Nu" workaround? :-)
Microsoft Connect item: NuGet adds packages to TFS despite .tfignore
It looks like this is fixed in version 3.2 RC of the NuGet Visual Studio 2015 Extension - updating to this version worked for me, at least.
A discussion about this issue can be found here where it is recommended to update from NuGet 3.1 to 3.2 RC.
Update
Version 3.2 of the extension has now been released (found here) which includes this fix.
Clarification
To get this working you need two things:
A nuget.config file containing the disableSourceControlIntegration setting
A version of the NuGet Visual Studio 2015 Extension that respects the disableSourceControlIntegration setting (versions from 3.2 onward should work)
As indicated in the docs:
NuGet first loads NuGet.config from the default location, then loads any file named NuGet.config starting from the root of the current drive and ending in the current directory.
This means that you can specify <solution><add key="disableSourceControlIntegration" value="true" /></solution> in the default config file for your user profile (found at %APPDATA%\NuGet\NuGet.Config) or in the NuGet config file in your solution directory, e.g., \MySolution\.NuGet\NuGet.config.
In your %AppData%\NuGet\NuGet.Config file, add the following just before the </configuration> XML tag...
<config>
<add key="repositoryPath" value="C:\NuGetPackages" />
</config>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
...you can specify any path you want - the important thing is putting it OUTSIDE your TFS workspace!
Now you never have to worry about that stuff again. Your solution folder will not contain any packages anymore; all solutions will default to using your custom packages location instead.
NOTE - This works is on a per-user basis.
Until now, I've been doing the same in a one-config-per-solution (\.nuget\NuGet.Config) manner. Thanks to #dsghi for the insight!
Make sure your solution folder does not contain a .nuget folder (old way of doing things). Even if the folder is NOT included in the solution and only in the file system, it will override everything!
I have the same problem and I haven't found a real solution yet.
The only workaround I've found so far is:
Right click the packages folder in "Team Explorer - Pending Changes"
and select "undo".