The 'Source' parameter is not respected for the transitive package management based project(s)

[iotalambda]

Details about Problem

NuGet product used: Package Manager Console

NuGet Package Manager Host version: 4.7.0.5212

dotnet.exe --version: 2.1.302

VS version: 15.7.5

OS version: Microsoft Windows [Version 10.0.14393]

Detailed repro steps so we can see the same problem

PM> Install-Package AutoMapper.Collection.EntityFrameworkCore -Version 0.1.0-ci-00003 -Source https://www.myget.org/F/automapperdev/api/v3/index.json

The following error appears
The 'Source' parameter is not respected for the transitive package management based project(s) My.Project.Namespace. The enabled sources in your NuGet configuration will be used.
and the install fails.

Adding https://www.myget.org/F/automapperdev/api/v3/index.json as a nuget feed for VS works as a workaround, but I don't want to do that. I want to use this source for this nuget package only and ensure that my coworkers do not have to configure their VS in order to build the project.

[Leon99]

This behavior is really annoying, I'm surprised it's not getting enough attention.

[jmevel]

I personally get the same warning message but the Source parameter is actually taken into account.

If I delete my package source from my Nuget feeds list in VS options and then run the command Install-Package "PrivatePackageName" it fails (as expected).
But if I run Install-Package "PrivatePackageName" -Source "PrivateNugetFeedURL" I get the warning message but it actually works.

Package Manager Console Host Version 4.8.1.5435
Visual Studio version 15.8.9

[SeppPenner]

I have the same issue...

[michael-hawker]

@karann-msft all MyGet packages suggest this command-line setup to add private packages via the Package Manager Console. However, trying to execute that command leads to this issue.

VS Version: 16.3 Preview 3

[zijianhuang]

same with VS 2019 Pro latest, and local .net core package.

[SylwesterZarebski]

Using MyGet packages on multiple computers working on same project is not really possible.
Only workaround is add multiple feeds (for every project or package) to every computer, which is not scalable at all.
Needs to fix is ASAP.

[JimBobSquarePants]

Using MyGet packages on multiple computers working on same project is not really possible.
Only workaround is add multiple feeds (for every project or package) to every computer, which is not scalable at all.
Needs to fix is ASAP.

Why not add the package sources to a Nuget.config and add it to source control?

[SylwesterZarebski]

Thanks, i'll try that. Last time i tried (few years ago) VS nuget manager did not support it.

[michael-hawker]

@JimBobSquarePants that's fine if you know you want to be pulling from MyGet for a long-term project, but sometimes you just want to pull a dev package to test something quick or try out a new feature, setting up a NuGet.config for that single purpose isn't a great workaround.

I think the main thing here is that MyGet still provides an easy copy-paste command on their website in order to pull down the package, but that's broken because of this bug.

[JimBobSquarePants]

@michael-hawker You should be using a Nuget.config file for ALL projects that are source controlled. It's just good practice.

[weitzhandler]

I agree with @michael-hawker.
I'm now working on a repo and wanna test one of the NuGet packages I made local changes to.
It really doesn't make sense to add that file or change it to accommodate for my local path.
What I ended up doning instead is adding that path to the NuGet sources in VS.
It would have been better if there woulda been an opt in option "Allow installation of packages from unknown sources", that eliminated that error and allows for hassle free package installation.

[davidfowl]

@JimBobSquarePants agreed but it's a PITA for local testing since you end up having to put a physical path in the NuGet.Config. That's fine if the repo is a throw away for testing but not something to check into source control.

@weitzhandler What happens if you have dependencies on other packages that aren't on nuget feeds? There are several issues with local package development that makes things painful for fast iteration:

• Package versions need to be revved every build to avoid getting the cached version on install
• The a pseudo local feed of each project needs to be added (unless you build all packages to the same output location).

[nkolev92]

Hey all,
if you are trying to work with packages that under development, please consider upvoting #6579.

[weitzhandler]

@davidfowl thanks for your explanation.
My use case is quick testing scenarios. Regarding the version, I go with ..*.1, and since usually the packages I'm working on don't have these increments it works out to be fine.
Adding the source to VS settings is fine with me.

[IanKemp]

Not only has there been no fix for this issue in almost two years, we haven't even been provided an explanation as to why this happens. Par for the course for the NuGet team, though.

[Mike-E-angelo]

FWIW it seems some of our users are running into this issue when attempting to run a command we provide in our CI/CD (example). An example report of this issue can be seen here.

[nkolev92]

@Mike-E-angelo

The scenario you linked is our primary motivation as to why is the source parameter is not respected.

We want to steer people in a direction where their restores are repeatable and that can't happen if a package is not in any of the sources specified for that solution/repo/project.

[ElektroStudios]

Since year 2018, and still no fix and even no answer in 2024. Take your own conclusions.