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

Is there a way to manage allowedVersions across all projects in a solution? #7181

Open
StingyJack opened this issue Aug 7, 2018 · 6 comments
Labels
Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Status:Excluded from icebox cleanup Status:Inactive Icebox issues not updated for a specific long time Type:Feature

Comments

@StingyJack
Copy link
Contributor

StingyJack commented Aug 7, 2018

I want to limit a set of packages to stay below a specific version number for every project in a solution. Is there a way to do that (EDIT: without having to manage this at each individual projects)?

@mishra14
Copy link
Contributor

mishra14 commented Aug 8, 2018

@jainaashish and @anangaur Have been discussing something related. Guys do you have any docs for @StingyJack ?

@4creators
Copy link

4creators commented Aug 8, 2018

It is two step process: (i) abstract versions as global properties in msbuild, (ii) declare versions capped to highest one you want to use. Warning: this will not prevent NuGet from restoring whatever it wants from dependency graph.

(i) use Directory.Build.props in the root of your solution and declared dependencies version in form of properties in that file instead of doing it in every project. Directory.Build.(props|targets) are files automatically included by MSBuild 15 in so called extension points into every project which is built.

(ii) Declare package version in the form capped from top limiting version range as desired. NuGet version ranges docs

Directory.Build.props file content

<PropertyGroup>
    <MicrosoftNETCoreAppPackageVersion>(,2.1.302]</MicrosoftNETCoreAppPackageVersion>
    <MicrosoftNetCoreILAsmPackageVersion>(,2.1.0-rtm-26528-02]</MicrosoftNetCoreILAsmPackageVersion>
    <XunitPackageVersion>(,2.4.0]</XunitPackageVersion>
    <MoqPackageVersion>(,4.9.0]</MoqPackageVersion>
    <NewtonSoftJsonPackageVersion>(,11.0.2]</NewtonSoftJsonPackageVersion>
    <MicrosoftBuildPackageVersion>(,15.7.179]</MicrosoftBuildPackageVersion>
    <LibGit2SharpPackageVersion>(,0.25.2]</LibGit2SharpPackageVersion>
    <SystemDrawingCommonPackageVersion>(,4.5.0]</SystemDrawingCommonPackageVersion>
    <SystemRuntimeCompilerServicesUnsafePackageVersion>(,4.5.1]</SystemRuntimeCompilerServicesUnsafePackageVersion>
</PropertyGroup>

Project.csproj package reference:

  <ItemGroup>
    <PackageReference Include="Microsoft.Build" Version="$(MicrosoftBuildPackageVersion)" />
    <PackageReference Include="Microsoft.Build.Framework" Version="$(MicrosoftBuildPackageVersion)" />
    <PackageReference Include="Microsoft.Build.Tasks.Core" Version="$(MicrosoftBuildPackageVersion)" />
    <PackageReference Include="Microsoft.Build.Utilities.Core" Version="$(MicrosoftBuildPackageVersion)" />
    <PackageReference Include="Moq" Version="$(MoqPackageVersion)" />
    <PackageReference Include="Newtonsoft.Json" Version="$(NewtonSoftJsonPackageVersion)" />
    <PackageReference Include="xunit" Version="$(XunitPackageVersion)" />
    <PackageReference Include="xunit.extensibility.core" Version="$(XunitPackageVersion)" />
    <PackageReference Include="xunit.extensibility.execution" Version="$(XunitPackageVersion)" />
    <PackageReference Include="xunit.runner.console" Version="$(XunitPackageVersion)" />
  </ItemGroup>

@anangaur
Copy link
Member

anangaur commented Aug 8, 2018

We are looking at ways to improve the central package version management for NuGet but this is still in incubation phase and not committed yet. You can find more details on the issue: #6764

@StingyJack
Copy link
Contributor Author

@4creators - thanks but we are not able to move to package reference until at least the first three of these are resolved, as well as the warning you noted. Most of the software I write/maintain is for the heavily regulated pharmaceutical packaging industry. I can't be fooling with (nor would I want to) random restores or tools that decide to change the version numbers of components.

@anangaur that's fine. I'll just have to keep writing more powershell scripts to manage projects and dependencies.

@japj
Copy link

japj commented Jan 21, 2019

have you looked at https://github.com/Microsoft/MSBuildSdks/tree/master/src/CentralPackageVersions for managing nuget package versions centrally?

@StingyJack
Copy link
Contributor Author

@japj - thanks for the heads up but that requires package reference.

@ghost ghost added the Status:Inactive Icebox issues not updated for a specific long time label Sep 1, 2022
@jeffkl jeffkl added Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. and removed Pipeline:Icebox labels Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Status:Excluded from icebox cleanup Status:Inactive Icebox issues not updated for a specific long time Type:Feature
Projects
None yet
Development

No branches or pull requests

8 participants