Add vs-solutionpersistence repo (v1.0.6). Used to read solution files. #386
Conversation
|
The following two prebuilts are being detected: Microsoft.NETCore.App.Ref.8.0.8 @richardstanton - How is Nerdbank.GitVersioning being used? I am wondering if required for the source-build usage scenario. I would like to avoid having to source-build it as well. |
|
I wonder if the Microsoft.NETCore.App.Ref.8.0.8 prebuilt is caused from the sdk rollforward setting. This could be problematic in online builds. We may need to add special casing to handle it. |
It is used to generate the assembly version and the nuget package version consistently with how we normally build. It seemed that other repos in source-build-externals were also using it, and it lives in dotnet so it seemed safe to use. It isn't essential, the versioning could be done manually, but didn't want it to accidentally get out of sync. |
If you look closely you will see the references are removed for source-build in the other repos. For example here is the patch that removes it for IdenityModel - https://github.com/dotnet/source-build-externals/blob/main/patches/azure-activedirectory-identitymodel-extensions-for-dotnet/0001-fix-for-source-build.patch#L34 |
It seems like the problem was that I specified net8.0 instead of $(NetCurrent). However, I also added a fix to change rollForward to disable. This should help prevent any strange behavior on build machines with multiple SDKs. |
3215426 to
daa2f7d
Compare
Description
This repo provides a common library to read Visual Studio solution files and the new .slnx solution file format. There are requests to read slnx solution files for msbuild and dotnet. This repository is small and has no dependencies.
PR Checklist
If you are upgrading the version of a repo submodule, please follow this
checklist:
the upgrade. Both this PR and the PR doing the upgrade in the consuming repo
should link to that issue.
in the consuming repo in a timely manner? If consuming the dependency flow of
this update takes a long time or needs to be backed out, it may require the
reversion of the upgrade in this PR. That's something we want to avoid.
version upgrade, consider using a separate PR or at least changing the title of
the dependency flow PR to accurately reflect the purpose of the change. Seeing
a PR named "Upgrade IdentityModel to 8.0.1", for example, provides better
clarity than "Update dependencies from dotnet/source-build-externals".