Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] nuget packages bring the code along, like npm #9182

Open
Petermarcu opened this issue Mar 16, 2018 · 7 comments
Open

[Suggestion] nuget packages bring the code along, like npm #9182

Petermarcu opened this issue Mar 16, 2018 · 7 comments
Milestone

Comments

@Petermarcu
Copy link
Member

@mhamri commented on Fri Nov 10 2017

the fact that if a developer wants to do a change to a NuGet package he/she has to separately find the code in many different places like GitHub/CodePlex/google code, SourceForge, .... then do the changes, and create a new package for himself and also do a pull request, all of this is very troublesome.

because day to day i am working with different programming languages, I see this benefit, if something doesn't work, the code is just one folder far from me (vendor folder in case of composer or node_module in case of npm, ...). I saw many occasion that it leads to an instant pull request. on the other side, i saw .net developers if something doesn't work in a NuGet package, they try to find another package if that one also doesn't work they go and create their own code instead of fixing or contributing to that package. unfortunately, this behavior of NuGet that brings a ready to use black box, leads to have a less willing developer community to contribute.

my suggestion is to bring the code along the packages to a local nuget folder that is not hidden from the user (not like now that the packages folder is not part of the explorer window). on the first build the new package also will build along with the other code. if everything is good, then on subsequent builds those packages will be used. if not, the changed code inside the package will build along with the others code.

i know it's a very hard to achieve task, but it's a game changer for the .net community.


@Petermarcu commented on Fri Nov 10 2017

Its a good suggestion and something that I think we'll want to do eventually. At least making source one step away where packages at least have a link to the source and there are CLI commands to easily get those packages, build them from source, and then use that build instead of the package. Its a little easier for non-compiled languages but its definitely a real scenario that would be nice.


@richlander commented on Tue Nov 28 2017

Would SourceLink work for you?

@Petermarcu
Copy link
Member Author

I'm not sure if this is a Nuget feature or an SDK feature. I started here so it can be tracked as an experience. @KathleenDollard

@livarcocc
Copy link
Contributor

livarcocc commented Mar 16, 2018

This seems mostly like a NuGet issue. The piece that would be tooling would be the option to build the code from these packages to be consumed as the package itself.

We can leave this issue open in the CLI, but I am not so how far back on the backlog this will be. In any case, we should also file an issue on Nuget to have a conversation there as well.

@Petermarcu
Copy link
Member Author

I was thinking similar to the way it was back in dnx, basically the ability to swap a packageref with a project ref, then modify the code and use the dll you built instead of the package contents.

@Petermarcu
Copy link
Member Author

@davidfowl because he loved that feature (I liked it too :))

@livarcocc
Copy link
Contributor

We still need NuGet to tell us about the project/package in the assets.json file. And yes, folks miss that feature a lot.

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Backlog milestone Jan 31, 2020
Copy link
Contributor

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

@github-actions github-actions bot added the stale label Apr 25, 2024
@KalleOlaviNiemitalo
Copy link
Contributor

There was related work in dotnet/msbuild#8398.

@github-actions github-actions bot removed the stale label Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants