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

Inherit some project.json properties from global.json #4658

Closed
muratg opened this issue Dec 18, 2015 · 8 comments
Closed

Inherit some project.json properties from global.json #4658

muratg opened this issue Dec 18, 2015 · 8 comments
Milestone

Comments

@muratg
Copy link

muratg commented Dec 18, 2015

From @djanosik on January 19, 2015 19:25

I think some common project.json properties, like authors, tags, projectUrl and other metadata should inherit from global.json. It would make it possible to share some values across projects.

Copied from original issue: aspnet/dnx#1100

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @davidfowl on January 22, 2015 19:5

Sounds like a great idea. I think we had another bug to do this.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @smbecker on May 7, 2015 20:59

Should dependency versions be apart of this? In a large system with a lot of projects, updating a reference to the latest version and ensuring that all projects are using the same version can become tedious and error prone. This would be a lot simpler if the dependency version was declared in global.json and then in the project.json, the version was left empty.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @djanosik on May 10, 2015 17:5

@smbecker I think it shouldn't, it feels wrong to me. I have some large solutions and I can't imagine this to be an issue.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @MiguelAlho on June 15, 2015 16:18

I agree with @smbecker, especially because I've been through some projects that suffered from not having a way to manage packages globally, for the entire solution. Because packages were added per project, and as the project grew, there tended to be multiple versions of the same package being referenced (like castle, log4net, automapper...) which meant problems we would find in staging/production, only. Many times it would require some type of binding redirects to be applied. This is one of the thing where dev / team discipline is required, but because it is possible to miss, some one WILL miss it. If there were a way to avoid this from happening, like defining common dependency versions in the global.json, then this pain could be reduced (though not completely eliminated).

Another place where this could help and where I've felt the pain (heavily), is when one solution references packages created from another solution. My teams case - we had a service solution with about 100 projects. A lot of those projects referenced libraries (from packages) from another solution (about have a dozen packages) and pretty much all the projects consumed a common, utilities package (used across a few solutions). When ever we tried to update these in the main project, chaos ensued. Initially it could take a half-hour to update (using the nuget package manager), but through a few tweeks, shortcuts and some custom tools, we were able to reduce this to a few seconds. One thing we did to help reduce this is too define an alternative folder (we called it a proxy) to copy the package content (without the version numbers) and switch path hints in csproj to that new location (and only for packages that were defined in a specific packages.config). This also reduced merge conflicts from having version numbers in the reference paths. All this just to add some context to a personal experience that concluded that a solution level reference for packages can be very helpful. I don't think everyone will need it, but large projects can benefit from it and leverage nuget for modularity.

Finally, another useful aspect for the dependencies in the global.json would be to enable tooling packages (the type that usually includes target="tools"). This would aid in making packages with build tools or dev tools available at the solution level and to the build server, and specified / contained by the solution.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @MiguelAlho on June 16, 2015 9:26

Just finished reading aspnet/dnx#819 . Internalizing libraries in each solution project will help avoid the first problem mentioned (multiple versions of the same package conflicting). Not sure it solves it completely - for instance, if in the same solution project A refs library Bv1.1, project B refs project A AND library Bv1.2 and you export project B as a package, what version(s) of lib B get(s) used? Still, having a single version of the dependency (and easily controlling it) across all the projects in the solution would be useful.

@TheRealPiotrP
Copy link
Contributor

@brthor, you've been thinking along these lines lately.

@Antaris
Copy link

Antaris commented Jun 9, 2016

Where does this case sit with the migration back to csproj? I'm looking for guidance on versioning a set of projects in the same solution, hoping I can set a version attribute in global.json and have that inherited across all my projects?

@TheRealPiotrP
Copy link
Contributor

The team is actively working on enabling MSBuild and the component affected will be superseded by the new project system, so I am closing this issue.

@Antaris, once we finish migrating to MSBuild you'll be able to take advantage of shared props or versioning targets to solve this scenario.

wli3 referenced this issue in wli3/cli Jul 14, 2017
Updated version for Test Platform.
@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Backlog milestone Jan 31, 2020
rainersigwald pushed a commit that referenced this issue Jul 20, 2020
….2 (#4658)

Microsoft.DotNet.Cli.Runtime
 From Version 3.1.400-preview.20327.1 -> To Version 3.1.400-preview.20329.2

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants