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 PackageLineup to manage versions #1996

Merged
merged 1 commit into from Aug 16, 2017

Conversation

Projects
None yet
8 participants
@natemcmaster
Member

natemcmaster commented Aug 14, 2017

Changes:

  • Removes the Version attribute from all PackageReference and removes dependencies.props file (aspnet/BuildTools#362)
  • Removes the aspnetcore-tools feed (aspnet/BuildTools#367)
  • Add PackageLineup dependencies on Internal.AspNetCore.Universe.Lineup (aspnet/Universe#538) and .Partners.Lineup (aspnet/CoreCLR#267)
  • Uses Directory.Build.props and Directory.Build.targets to reduce duplication in csproj files
  • Move Kestrel.Performance from test/ to benchmarks/. It's not really a "test" project.

New workflow:
When cloning this repo, you must execute build.cmd /t:Pin or build /t:Restore first 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:Pin or build /t:Restore again.

cc @cesarbs @halter73 @pakrym @muratg

See aspnet/KoreBuild#239
See also https://github.com/aspnet/BuildTools/wiki/%5Bspec%5D-Package-version-lineups

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Aug 14, 2017

Contributor

New workflow: ....

Add it to Readme.md?

Contributor

benaadams commented Aug 14, 2017

New workflow: ....

Add it to Readme.md?

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Aug 14, 2017

Member

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

Member

natemcmaster commented Aug 14, 2017

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

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Aug 14, 2017

Member

Add it to Readme.md?

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.

Member

natemcmaster commented Aug 14, 2017

Add it to Readme.md?

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.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Aug 14, 2017

Member

This uncovered at least one interesting issue: aspnet/BuildTools#369

Nevermind. Appears to have been random network issue with myget.

Member

natemcmaster commented Aug 14, 2017

This uncovered at least one interesting issue: aspnet/BuildTools#369

Nevermind. Appears to have been random network issue with myget.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Aug 14, 2017

Contributor

people tend to ignore README files, esp. if they're regular contributors already.

They start as new contributors first 😉

Contributor

benaadams commented Aug 14, 2017

people tend to ignore README files, esp. if they're regular contributors already.

They start as new contributors first 😉

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Aug 14, 2017

Member

I updated the README.

Member

natemcmaster commented Aug 14, 2017

I updated the README.

@ryanbrandenburg

Looks good.

Show outdated Hide outdated Directory.Build.props Outdated
@@ -17,8 +15,7 @@
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Logging.Console" Version="$(AspNetCoreVersion)" />
<PackageReference Include="Microsoft.NETCore.Compilers" Version="$(MicrosoftNETCoreCompilersVersion)" PrivateAssets="All" />

This comment has been minimized.

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

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.

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

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.

This comment has been minimized.

@natemcmaster

natemcmaster Aug 15, 2017

Member

@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.

https://github.com/aspnet/BuildTools/blob/da73e105376f5b980593c1519e58d8bcde8fdb65/src/Internal.AspNetCore.Sdk/build/FindUnusedReferences.targets#L6

@natemcmaster

natemcmaster Aug 15, 2017

Member

@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.

https://github.com/aspnet/BuildTools/blob/da73e105376f5b980593c1519e58d8bcde8fdb65/src/Internal.AspNetCore.Sdk/build/FindUnusedReferences.targets#L6

@@ -0,0 +1,7 @@
<Project>

This comment has been minimized.

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

So these Directory.Build.props and *.targets files let us describe per-directory behavior? Neat.

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

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" />

This comment has been minimized.

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

It's happening!

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

It's happening!

@@ -0,0 +1,23 @@
<Project>
<Import Project="..\Directory.Build.props" />

This comment has been minimized.

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

So Directory.Build.props files will not chain themselves by default?

@ryanbrandenburg

ryanbrandenburg Aug 15, 2017

Member

So Directory.Build.props files will not chain themselves by default?

This comment has been minimized.

@natemcmaster

natemcmaster Aug 15, 2017

Member

Right. The Directory.Build import only finds the first file in or above the project directory. We have to manually chain beyond that.

@natemcmaster

natemcmaster Aug 15, 2017

Member

Right. The Directory.Build import only finds the first file in or above the project directory. We have to manually chain beyond that.

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver Aug 16, 2017

Contributor

By convention, I almost universally expect this to work (across all the .NET Core projects):

  1. get clone
  2. build.cmd

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 build.cmd work as it does today, without args for the user?

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).

Contributor

NickCraver commented Aug 16, 2017

By convention, I almost universally expect this to work (across all the .NET Core projects):

  1. get clone
  2. build.cmd

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 build.cmd work as it does today, without args for the user?

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).

@mikeharder

This comment has been minimized.

Show comment
Hide comment
@mikeharder

mikeharder Aug 16, 2017

Contributor

@NickCraver: @natemcmaster can confirm, but I'm pretty sure git clone; build.cmd should continue to work as it does today. What is changing is that solutions cannot be opened in Visual Studio before running build.cmd /t:Pin or build /t:Restore from the command line.

Contributor

mikeharder commented Aug 16, 2017

@NickCraver: @natemcmaster can confirm, but I'm pretty sure git clone; build.cmd should continue to work as it does today. What is changing is that solutions cannot be opened in Visual Studio before running build.cmd /t:Pin or build /t:Restore from the command line.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Aug 16, 2017

Member

Correct. build.cmd work the same before and after this change. The VS workflow is the only piece that changes.

By the way, some clarity on /t:Pin vs /t:Restore.

/t:Restore depends on /t:Pin and executes a "dotnet restore".
/t:Pin only pins package reference versions but does not execute 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

Member

natemcmaster commented Aug 16, 2017

Correct. build.cmd work the same before and after this change. The VS workflow is the only piece that changes.

By the way, some clarity on /t:Pin vs /t:Restore.

/t:Restore depends on /t:Pin and executes a "dotnet restore".
/t:Pin only pins package reference versions but does not execute 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

Use PackageLineup
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.

@natemcmaster natemcmaster merged commit 26f1d4b into aspnet:dev Aug 16, 2017

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@natemcmaster natemcmaster deleted the natemcmaster:lineups branch Aug 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment