-
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
Inherit some project.json properties from global.json #4658
Comments
From @davidfowl on January 22, 2015 19:5 Sounds like a great idea. I think we had another bug to do this. |
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. |
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. |
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. |
@brthor, you've been thinking along these lines lately. |
Where does this case sit with the migration back to |
….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>
From @djanosik on January 19, 2015 19:25
I think some common
project.json
properties, like authors, tags, projectUrl and other metadata should inherit fromglobal.json
. It would make it possible to share some values across projects.Copied from original issue: aspnet/dnx#1100
The text was updated successfully, but these errors were encountered: