I've got a public nuget package that has a prerelease version that depends on the aspnetwebstacknightly feed on myget. Does anyone know if there's a way to create a dependency in my package on that feed? I haven't been able to find anything helpful. I'm guessing there's no way to do this, but just want to try SO as a last resort. :)
You can have the dependency defined in your package. The only issue is that when you push yours to nuget.org without that dependency being present there, your package consumers will have to configure the MyGet feed as well for that dependency to be resolved during install time.
More precisely, the MyGet feed should be put below the NuGet.org feed, and your package should be installed using the "All" aggregate package source.
You could communicate this in your package readme.txt or in your package metadata to have it visible on the NuGet.org package details page. You could also try to add some PowerShell scripts and try to find a way around it, but the issue you're fighting with is by design. However, I would not recommend doing any of this.
Basically, you'll have this issue as long as your dependency has not been pushed to NuGet.org. Why not expose your pre-release package on MyGet and configure the aspnetwebstacknightly MyGet feed as an upstream package source in your feed? Be sure to enable the "proxy" checkbox for this package source so that your dependency will be resolved as well without consumers needing to configure both feeds (installing your package from your feed would also fetch your dependency from your feed - which under the hood then queries the aspnetwebstacknightly feed).
Hope that helps!
Related
I have an Azure Pipelines job setup to authenticate to a private NuGet feed in Azure Artifacts, and then build my .NET project that relies on a NuGet package in the feed. However, my private package is a pretty common name. How can I ensure that it only installs that specific package from my private feed, and doesn't try to fallback to the NuGet general gallery? I do not want it to pull in an incorrect package that has the same name and version name as my private package.
Once you configure multiple sources/feeds, NuGet will look for a package in all these sources together with no guarantee of where the package will be downloaded from. However, you could make the AzDo artifacts feed as the only configured feed and then upstream other sources from it. This way NuGet will get all packages from the configured AzDo artifacts source and AzDo artifacts will source other packages not available with it from the upstreamed sources in the order defined. More info can be found here: https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops
Since NuGet implemented NuGet Package ID Prefix reservation, latest versions of Visual Studio show a new icon for verified packages.
Today I've noticed all packages in my custom MyGet feed got the same icon, however, I did not make any additional change.
Is this the expected behavior in MyGet?
Since the NuGet protocol does not really describe when a package should be "verified" when used outside of Nuget.org, we at MyGet now use the following convention:
If a package originates from a MyGet feed, it is shown as "verified" (e.g. it comes from your feed)
If a package is proxied from, e.g. NuGet.org, the package is never shown a verified as MyGet reaches out upstream to fetch the package and its not part of your feed yet. Additionally, since the V2 protocol does not expose the verified boolean, we can never show the verified label for upstream package sources.
How to gracefully stop support of NuGet package in nuget.org repository? Actually I moved the package to another NuGet channel (e.g. moved https://www.nuget.org/packages/my_old_package/ to https://www.nuget.org/packages/my_new_package/). And want to notify existing subscribers that they should switch.
Currently, I consider the following solutions:
Publish last build with description like "This package is no longer
supported. Switch to other package..."
Simply delete package - not sure how will it affect customers.
What approach can you recommend?
You can unlist the old NuGet package so it will not be found when searching for packages. Unlisting is what happens when you delete the package either from the command line using NuGet.exe or from the gallery on nuget.org.
With the NuGet package being unlisted existing users can still use that package. Restoring the package will still work since the NuGet package still exists.
Notifying existing users of the NuGet package not being supported is not a feature of NuGet. If you need that you would have to implement yourself. For example, you could add a readme.txt to the latest NuGet package which informs the user that this package is now deprecated and they should be using a different NuGet package. The readme.txt will automatically be opened by Visual Studio when the package installed. The only problem here is that this approach is incompatible with unlisting the NuGet package. The NuGet package with the readme.txt would still need to be listed on nuget.org.
Another approach, which may or may not be a possibility, is to have your old NuGet package simply install the other NuGet package. So the old NuGet package has no content itself but just has a dependency on the other NuGet package.
Of these approaches I think I would just unlist all the versions of the old NuGet package. You could also update the package description on nuget.org by editing the metadata directly on the site to indicate the old NuGet package is deprecated.
I have a web public folder which I use when I want to share any file so I was thinking on having my nuget package there. I tried to push it using:
nuget push Me.Utility.1.0.nupkg API_KEY -Source http://www.mywebpage.mx/packages
then it asked me for the credentials but none of the ones I put have worked (the credentials are correct). My web folder is not a nuget feed is just a web shared folder. Is not clear to me if the problem is that it should be a nuget feed (something like myget service) or which is the minimum infrastructure that I need to have since this is only one nuget package. I want to host my package at my own server and also I want my package to appear in the official gallery, so in that case should I set up my own nuget feed?
Could you please explain how this should be done?
MyGet.org supports pushing packages upstream, for instance to NuGet.org. Check out this blogpost to know how to do this: http://blog.myget.org/post/2012/03/01/Introducing-MyGet-package-source-proxy-(beta).aspx
The official gallery meaning nuget.org? With nuget.org you can't choose to host your nupkg on an external site, nuget.org has to host it for you. You might be confusing myget.org and nuget.org concepts.
PS: if you use the argument to override 'source' then you are no longer using the official gallery nuget.org. Hence the question title is confusing.
We have a (free) product that may help you. ProGet gives you the ability to host a custom NuGet feed on your own network, and allows you seamlessly connect to an existing feed such as the NuGet.org one with a "connector". If you publish to the official NuGet gallery and enable caching on your private feed in ProGet, anytime you consume your own package from the official NuGet feed it will automatically cache it (and any others) on your network for you.
I find Nuget to be a very powerful tool with a lot of potential. However, I am confused, how does Nuget get updates for a package (e.g. ELMAH)? Is it looking at an ftp server for new downloads?
Thank
NuGet looks a package sources to find updates. By default, it uses the official nuget feed (https://go.microsoft.com/fwlink/?LinkID=206669) to find updates. When package authors push new versions of packages to the feed, they are instantly available.