search

jmrog / vscode-nuget-package-manager

An extension for Visual Studio Code that lets you easily add or remove .NET Core 1.1+ package references to/from your project's .csproj file using Code's Command Palette.
MIT License
34 stars 17 forks source link

nuget.config package sources #23

Open ghost opened 7 years ago

ghost commented 7 years ago

Internally we use a private nuget repository - and it would be helpful if this extension could support utilizing the package sources from the nuget.config instead of the constant https://api-v2v3search-0.nuget.org/autocomplete

jmrog commented 7 years ago

Great idea! I'll add that ability as soon as I have some time (unless you want to PR it).

robvanpamel commented 7 years ago

Are you using a default Nuget configuration at this moment? If so where is this located? We are also using a private repository. The results from this repository are not showing up due to this.

jmrog commented 7 years ago

Just providing a quick update:

I haven't had a lot of time to look into this issue. One blocker is that I'm fairly unfamiliar with using private NuGet repositories. Based on the information I've found here and here, it looks like managing this can get pretty complex (e.g., you can have various config files, at the global, solution, and project levels, as well as at other "default" locations, and those config files can specify multiple package sources, some of them having additional credentials configuration blocks, etc.). Given my lack of time, I'm wondering whether there are any "interim" solutions that would be good enough in the meantime. Any thoughts about that?

@robvanpamel To whom were those questions directed?

jmrog commented 7 years ago

I've made some decent progress on this, but have now hit a bit of a blocker. This extension currently assumes that the repository exposes an HTTP(S) endpoint that can be used for searching its contents (as nuget.org does). Purely local (non-HTTP(S)) repositories won't do that, and I'm not sure whether all hosted custom NuGet repositories will do that, either (or how exactly to discover the relevant endpoint for custom repos, if they do expose one). So, I could really use some input from anyone who wants this feature, explaining which features they care about the most -- e.g., purely local repositories or just alternative HTTP(S) repositories? -- and/or where I might find out more about these details, since I've never used custom repositories myself.

For now, I'm guessing that, for purely local (non-HTTP(S)) NuGet repositories, I'll simply have to make the extension search the package directory for relevant information (which could be clunky); for HTTP(S) repositories, I'm not sure whether they'll all expose a search endpoint or not (and, if not, the solution there could be even more clunky). That information is needed before I can proceed.

Kampfmoehre commented 7 years ago

We are using mostly our TeamCity Buildserver for our own packages and some Microsoft MyGet Feeds (Example . Especially the latter could lead to confusing results, if you take the ASPNetCore package for example, it currently has the version 2.0.0-rtm-26232 on https://dotnet.myget.org/F/aspnetcore-release/api/v3/index.json but it also exists on the offcial NuGet Feed in version 2.0.0-preview2-final. Maybe this should be made visible in the NuGet Dropdown either on the "Choose your package list" or the "Choose your package version list". I would rather not see another list to choose the feed if a package exists in multiple feeds. Maybe a small label behind the package/version indicating the origin in form of the key used in NuGet.config?

Also I would just start with using the common NuGet.config in project root for simplicity. If there is demand for other configs you could always provide that later.

mblataric commented 7 years ago

Hi!

We are running our own nuget feed using Nuget.Server. We figured its better than exposing some local folder and this way it is accessible over internet as well. So I am all for http support. As for nuget.config - this is a bit of a mistery becuse linux and macos have a global one in ~/.nuget/NuGet/nuget.config - while windows does not. Have no idea where this file is located on windows. I guess you could check existance of ~/.nuget/NuGet/nuget.config and nuget.config in project root folder. If it is easier only check project root folder we can go for that as well, adding one file is not a big deal.

Regards and thanks for this nice addon, Mario

awarrenlove commented 6 years ago

I think the simplest option would be to move the URLs to a new configuration option. It wouldn't solve the issue of having to maintain your Nuget URLs in multiple places unfortunately, but it should be a fairly straightforward stopgap to allow private Nuget searches until a better dynamic solution is found. It also wouldn't solve the problem of Nuget servers that don't expose a URL for searching, but at least those that do could be integrated with this extension.

jmrog commented 6 years ago

@awarrenlove Yeah, I agree that that is probably the best "stop gap" solution. Thanks for the input. I've done some work toward implementing the feature, but just have had so little time lately to work on this extension that I haven't completed it. Hopefully I can do that soon!

awarrenlove commented 6 years ago

Is the branch jr/alternative-nuget-sources-23 up-to-date on GitHub? If it is, I'll see what I can do to finish it out.

jmrog commented 6 years ago

@awarrenlove It isn't, but I just now branched off of it and rebased the new branch onto master, then pushed the new branch. That branch is jr/alternative-nuget-sources-23-rebased. Feel free to take a look at it, but, if I remember correctly, most of the new stuff that's there was very hastily thrown together and left in a "half-way" state (e.g., there are debugger; statements here and there, a bunch of TODOs, etc.). It might ultimately be easier for you to branch off from master, but I'll leave that up to you. There's actually a lot of cleanup I'd like to do not only on that branch, but time just hasn't been available much at all lately!

Also, thanks for your interest in helping!

vandensd commented 6 years ago

In need of this if this can progress any time soon. Alternative is to run via command line as long as I have a nuget.config present to hit my private myget.

jmrog commented 6 years ago

I'm trying to get back into this a bit. No promises, though -- between work and a 1.5-year-old at home, my time has been very limited. Open to help!

erotavlas commented 5 years ago

Hello, What is the current status of this? Was needing to resolve package from local nuget server in a C# solution. Was going to change server manually in the nuget.config but was unable to determine which config this extension is loading.

ozanerturk commented 5 years ago

@jmrog Hello, I actually working on that problem rigth now. I have some idea to implement this feature. Once i finished development i will share it on my branch https://github.com/ozanerturk/vscode-nuget-package-manager Maybe we could merge it after. I am planning to do: -- resolve nuget.config from local source (first project folder afterr appdata) -- consume both json and xml source -- use particular proxy setting in nuget config etc.

jmrog commented 5 years ago

@jmrog Hello, I actually working on that problem rigth now. I have some idea to implement this feature. Once i finished development i will share it on my branch https://github.com/ozanerturk/vscode-nuget-package-manager Maybe we could merge it after. I am planning to do: -- resolve nuget.config from local source (first project folder afterr appdata) -- consume both json and xml source -- use particular proxy setting in nuget config etc.

Awesome! I'd be happy for this to happen!

ozanerturk commented 5 years ago

I need your advise on that @jmrog , what if new usage flow would be something like below: 1-type down shourtcut for extension 2-show avalible nuget sources(if it is possible skip for single source, go 4 ) 3-select source 4-query spesific source and list package names 5- verison selection 6- write on *.[cf]sproj

I tried to collect all sources and fetch from all of them but it cause lots of dirty code and validation problem.(Same package names from different sources, which version from which source etc.) Finally I think maybe user select the source in the first place then proceed to default flow, version selection etc.

Addition to that when I checkout the repository, I could not able to compile it successfully. I had to change some parts like : https://github.com/jmrog/vscode-nuget-package-manager/blob/923c980fed71183c15557a8a6cec0b709a430e35/src/actions/add-methods/fetchPackageVersions.ts#L17 to fetch(${versionsUrl}${selectedPackageName}/index.json,getFetchOptions(vscode.workspace.getConfiguration().get("http")))

or https://github.com/jmrog/vscode-nuget-package-manager/blob/923c980fed71183c15557a8a6cec0b709a430e35/src/actions/shared/checkProjFilePath.ts#L8 to .then<Array<string>>((foundProjFile: Array<string>) => {

is there anything wrong or it is about my local configuration like node version. Thanks.

ozanerturk commented 5 years ago

It seems you are busy. I will continue my development with above explanation. Once you notice please let me know :)

kuskmen commented 4 years ago

Sorry, to bother you guys, but have you got any update on this or any workaround?

Regards, Kuskmen

ozanerturk commented 4 years ago

It is a kinda old discussion. Honestly, while I was developing this functionality I realize that there is actually no need to use a package manager extension at all. Just like other programming language and their package managers. Whenever you need a package, search that in NuGet or any other sources then install it by CLI or type down the specific package with a version in .csproj file. For custom sources, I think it is better for you to take a look at NuGet.Config and how it is work. Then the CLI will serve your needs.

johndoylekbx commented 2 years ago

@ozanerturk Could you please provide more details + instructions on where + how to manually edit the NuGet.Config settings. I also have this requirement. I don't understand how NuGet can resolve our packages if it's not configured to look in our internal, private, unpublished package source url. Apparently the full, licensed Visual Studio supports configuring more NPM package sources. I only have access to VS Code.

ozanerturk commented 2 years ago

Hello @johndoylekbx The editors itself is actually not the case. I was trying to point out that .NET developers got used to have a package manager explorer in their editor. Like the Nuget package manager comes with Visual Studio built in. But normally in any other language, you just use a cli tool to install new packages.

Nuget.config should be located in your local machine. Each time you use `dotnet cli it uses the nuget with this config under the hood. The exact location depends on the platform. https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior

Here you can find how to add a new source to your nuget config. https://docs.microsoft.com/en-us/nuget/consume-packages/package-source-mapping This source could be a local source or a nuget server.