-
-
Notifications
You must be signed in to change notification settings - Fork 403
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
Use CentralPackageVersioning in samples to simplify maintenance #3207
Comments
* Move NuGet versions to Directory.Packages.props * Introduce CslaVersion property --------- Co-authored-by: Serhii Shushliapin <[email protected]>
(#3207) Co-authored-by: Serhii Shushliapin <[email protected]> Co-authored-by: Rockford Lhotka <[email protected]>
…#4050) * #3207 Convert into SDK project format * #3207 Introduce Directory.Packages.props --------- Co-authored-by: Serhii Shushliapin <[email protected]>
…on (#4052) * #3207 Convert into SDK project format * #3207 Introduce Directory.Packages.props * #3207 Fix base Docker images --------- Co-authored-by: Serhii Shushliapin <[email protected]>
@TheCakeMonster, @rockfordlhotka, do you have any opinion if it makes any sense to introduce CPM in single-project sample solutions such as DataPortalCacheExample? I ignored them for now, since for me it looks redundant... At the same time, if consistency is more important, I can come up with a single PR that introduces CPM for all the simple .net8 based solutions (for the .net8 projects there is much less work needed so a single PR should be ok). |
I don't see any value in that case, just added complexity. |
They produce following errors (for all projects in the solution) ``` C:\d\github\csla\Samples\BlazorExample\BlazorExample\DataAccess\DataAccess.csproj(7,3): warning MSB4011: "C:\d\github\csla\Samples\BlazorExample\Directory.Packages.props" cannot be imported again. It was alre ady imported at "C:\Program Files\dotnet\sdk\8.0.300\NuGet.props (35,3)". This is most likely a build authoring error. This subsequent import will be ignored. ``` Related to MarimerLLC#3207
They produce following errors (for all projects in the solution) ``` C:\d\github\csla\Samples\BlazorExample\BlazorExample\DataAccess\DataAccess.csproj(7,3): warning MSB4011: "C:\d\github\csla\Samples\BlazorExample\Directory.Packages.props" cannot be imported again. It was alre ady imported at "C:\Program Files\dotnet\sdk\8.0.300\NuGet.props (35,3)". This is most likely a build authoring error. This subsequent import will be ignored. ``` Related to #3207
* #3207 Convert into SDK project format * #3207 Introduce Directory.Packages.props * #3207 Upgrade to .net 8.0 --------- Co-authored-by: Serhii Shushliapin <[email protected]>
* #3207 Convert into SDK project format * #3207 Introduce Directory.Packages.props * #3207 Restore missing NuGet packages and references * #3207 Fix build configuration error --------- Co-authored-by: Serhii Shushliapin <[email protected]>
Central package versioning is now a first class citizen of .NET, and make management of things like sample applications easier. It probably makes sense to change over the samples to make use of this scheme so that they are easier to keep upgraded to the newer versions of CSLA.
https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management
I realised this whilst working on the compilation error we ended up with in the Blazor sample apps. I ended up having to change version numbers in multiple places, which is no longer necessary.
Suggested Solution
Upgrade each sample application separately, so that we can upgrade them one at a time. In the longer term we might decide that refactoring the samples folder makes sense to enable even simpler upgrades. However, being too aggressive may make upgrades larger, and hinder progress rather than enable it.
Further Improvement
The two Blazor samples BlazorExample and BlazorServerExample share backend packages, but are separate apps. I would suggest that moving both into a Blazor subfolder, so that the Directory.Packages.props file can apply to both, would be even better; this ensures that they are more likely to both compile together. See #3204 for an example of the current problem - upgrading just one of the two sample apps breaks the other.
The text was updated successfully, but these errors were encountered: