-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
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 |
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. |
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. |
@davidfowl because he loved that feature (I liked it too :)) |
We still need NuGet to tell us about the project/package in the assets.json file. And yes, folks miss that feature a lot. |
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. |
There was related work in dotnet/msbuild#8398. |
@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?
The text was updated successfully, but these errors were encountered: