Use PackageLineup to manage versions #1996
Conversation
Add it to Readme.md? |
|
This uncovered at least one interesting issue: aspnet/BuildTools#369. On CI only (not local builds), the restore call to roslyn's myget feed hangs for 100s. It can't reproduce locally. It doesn't cause restore to fail, but makes CI builds slower. I'll investigate |
That's a good idea. FYI if this experiment succeeds in solving our issues with managing PackageRef versions, then we'll be updating the most repos to this and adding this as general guidance to our engineering wiki page. That said, I'm hoping an appropriate error will be show up in VS and is clear enough that contributors don't have to hunt for a solution. I've found people tend to ignore README files, esp. if they're regular contributors already. |
Nevermind. Appears to have been random network issue with myget. |
They start as new contributors first 😉 |
|
I updated the README. |
Directory.Build.props
Outdated
| <PackageReference Include="Microsoft.NETCore.Compilers" Version="2.6.0-rdonly-ref-61915-01" PrivateAssets="All"> | ||
| <!-- | ||
| Suppresses the warning about having an explicit package version in this repo. | ||
| We are okay with this for now as the experimental version of the compiler is unique to Kestrel (for now). |
There was a problem hiding this comment.
Could we get a link to an issue here describing when we'll no longer be ok with it "for now"?
There was a problem hiding this comment.
@pakrym you wrote aspnet/Announcements#268. Any idea when features/readonly-ref will be merged in roslyn? Is there a good issue we can use to track progress on this?
cc @VSadov
There was a problem hiding this comment.
I've heard no exact dates, we can track dotnet/csharplang#666
There was a problem hiding this comment.
Thanks. I've added this to the comment.
| @@ -17,8 +15,7 @@ | |||
| </ItemGroup> | |||
|
|
|||
| <ItemGroup> | |||
| <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="$(AspNetCoreVersion)" /> | |||
| <PackageReference Include="Microsoft.NETCore.Compilers" Version="$(MicrosoftNETCoreCompilersVersion)" PrivateAssets="All" /> | |||
There was a problem hiding this comment.
Totally unrelated to your PR, but it would be nice if SOMETHING along the line of our toolchain gave a warning when you had a reference that you don't use.
There was a problem hiding this comment.
@pakrym built something close to this. But we haven't turned it on by default because it doesn't catch everything. i.e. some packages, like Microsoft.NETCore.Compilers, contribute build-time only assets to the build which don't show up in the final artifacts.
| @@ -0,0 +1,7 @@ | |||
| <Project> | |||
There was a problem hiding this comment.
So these Directory.Build.props and *.targets files let us describe per-directory behavior? Neat.
| <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="$(AspNetCoreVersion)" /> | ||
| <PackageReference Include="Microsoft.Extensions.Options" Version="$(AspNetCoreVersion)" /> | ||
| <PackageReference Include="System.Threading.Tasks.Extensions" Version="$(CoreFxVersion)" /> | ||
| <PackageReference Include="Microsoft.AspNetCore.Hosting.Abstractions" /> |
| @@ -0,0 +1,23 @@ | |||
| <Project> | |||
| <Import Project="..\Directory.Build.props" /> | |||
There was a problem hiding this comment.
So Directory.Build.props files will not chain themselves by default?
There was a problem hiding this comment.
Right. The Directory.Build import only finds the first file in or above the project directory. We have to manually chain beyond that.
|
By convention, I almost universally expect this to work (across all the .NET Core projects):
IMO, this initial requirement or args would be a lot more palatable if it was instead inferred in some way. Is there nothing we can check for to see if this should be automatically called (inside the script), making It's also a little doubly confusing I think, since we just announced to all users the .NET Core 2 bits auto-restored everywhere they needed to. Yes, that's a different thing, but it's a backwards set of reality and messaging overall (especially if this spreads to other repos). |
|
@NickCraver: @natemcmaster can confirm, but I'm pretty sure |
|
Correct. By the way, some clarity on /t:Pin vs /t:Restore. /t:Restore depends on /t:Pin and executes a "dotnet restore". /t:Pin is most useful when you have VS open already and have automatic restore enabled. Otherwise, you can get contention on writing to project.assets.json |
PackageLineup is a way to manage PackageReference versions across large projects. It removes the version information from the repository and instead pulls the information from an external "lineup" file.
Changes:
Versionattribute from all PackageReference and removesdependencies.propsfile (Implement version pinning from PackageLineup's BuildTools#362)test/tobenchmarks/. It's not really a "test" project.New workflow:
When cloning this repo, you must execute
build.cmd /t:Pinorbuild /t:Restorefirst before the repo can be used in Visual Studio/Code. This step generates the PackageReference versions. VS will display an error message if you don't.To update to the latest packages, run
build.cmd /t:Pinorbuild /t:Restoreagain.cc @CesarBS @halter73 @pakrym @muratg
See aspnet/KoreBuild#239
See also https://github.com/aspnet/BuildTools/wiki/%5Bspec%5D-Package-version-lineups