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

Add workload restore command #18910

Merged
merged 1 commit into from
Jul 20, 2021
Merged

Add workload restore command #18910

merged 1 commit into from
Jul 20, 2021

Conversation

wli3
Copy link

@wli3 wli3 commented Jul 14, 2021

Adding _FindAllReferenceWorkload target to find workloads in project.
Discover the projects and then pipe all arguements to workload install
command

@wli3 wli3 requested review from dsplaisted and sfoslund July 14, 2021 18:16
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

</PropertyGroup>
</Target>

<Target Name="_FindAllReferenceWorkload" DependsOnTargets="_SetSkipResolvePackageAssets;GetSuggestedWorkloads;PrepareProjectReferences" Returns="@(_ResolvedSuggestedWorkloads)">
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsplaisted help me double check the RemoveProperties are right

============================================================
-->

<Target Name="_FindAllReferenceWorkload"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsplaisted I end up adding a outer build version instead using the same one

@wli3 wli3 force-pushed the workload-restore2 branch from 5f128b2 to d2aeceb Compare July 14, 2021 18:20
Projects="@(_MSBuildProjectReferenceExistent)"
Targets="GetSuggestedWorkloads"
BuildInParallel="$(BuildInParallel)"
Properties="%(_MSBuildProjectReferenceExistent.SetConfiguration); %(_MSBuildProjectReferenceExistent.SetPlatform); GenerateErrorsForMissingWorkloads=false; SkipResolvePackageAssets=true"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise here, are these properties avoidable?

@wli3 wli3 force-pushed the workload-restore2 branch 2 times, most recently from 3fe20dd to 3912692 Compare July 14, 2021 21:03
src/Cli/dotnet/Parser.cs Outdated Show resolved Hide resolved

[Fact]
public void WhenCallWithDirectoryWith2ProjectItShouldFindAll()
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any tests confirming we can get from the project/sln arg in the parse result to a resolved list of projects

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WhenCallWithSlnOrProjectArgumentItCollectProjectsFromSolution is the pass in example

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it's not covering the parsing/ reading the parse result value

@wli3
Copy link
Author

wli3 commented Jul 14, 2021

@dsplaisted Rainer checked msbuild part too, so I think it won't be too bad. I'll get it in once test passes.

@wli3 wli3 force-pushed the workload-restore2 branch from c883636 to 9c80ba9 Compare July 14, 2021 23:09
@wli3 wli3 enabled auto-merge July 14, 2021 23:09
@wli3 wli3 force-pushed the workload-restore2 branch 2 times, most recently from efd9c34 to ad609bf Compare July 14, 2021 23:23
Comment on lines +89 to +93
internal static List<string> DiscoverAllProjects(string currentDirectory,
IEnumerable<string> slnOrProjectArgument = null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should discover all projects here. We should do the same thing as MSBuild, which is more or less to expect that there is a single project or solution file in the directory, and error out if not. The actual logic is in ProcessProjectSwitch: https://github.com/dotnet/msbuild/blob/1d845f30213e9ba4f36d4d5a366c0cc8285eed6e/src/MSBuild/XMake.cs#L2763

Ideally we wouldn't have to duplicate the logic. It looks like RunCommand has a simple form of it (FindSingleProjectInDirectory) which only looks for project files, not solution files.

Copy link
Author

@wli3 wli3 Jul 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about the same thing, but why make it difficult. I started with refactoring RunCommand. But when there are 2 projects in the folder what the user should do? It is valid, and workload restore can handle it (unlike runcommand), why fail and ask the user to input one by one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All other MSBuild and dotnet commands require you to specify the project if there is more than one in the folder. It seems weird to make dotnet workload restore the one exception.

{
var globalProperties = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)
{
{Constants.MSBuildExtensionsPath, AppContext.BaseDirectory},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a bit confusing to me. I see that RunCommand does the same thing, but it would be nice to have a comment explaining this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the line. It still works.


getValuesCommand.GetValues()
.Should()
.BeEquivalentTo("microsoft-android-sdk-full", "microsoft-net-runtime-mono-tooling");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these names are changing, you may want to update stage 0 and see if that includes the rename so that this test doesn't start failing when it happens.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

due to #19021 I will update stage 0 in a different PR

src/Tests/Microsoft.NET.Build.Tests/WorkloadTests.cs Outdated Show resolved Hide resolved
src/Tests/Microsoft.NET.Build.Tests/WorkloadTests.cs Outdated Show resolved Hide resolved
@dsplaisted dsplaisted disabled auto-merge July 15, 2021 02:25
@wli3 wli3 force-pushed the workload-restore2 branch from ad609bf to 10169f0 Compare July 18, 2021 21:15
Copy link
Contributor

@Nirmal4G Nirmal4G left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some suggestions for the targets!

@@ -13,5 +13,6 @@ Copyright (c) .NET Foundation. All rights reserved.

<Import Project="$(MSBuildThisFileDirectory)Microsoft.NET.DefaultAssemblyInfo.targets" />
<Import Project="$(MSBuildThisFileDirectory)Microsoft.NET.DefaultOutputPaths.targets" />
<Import Project="$(MSBuildThisFileDirectory)Microsoft.NET.Sdk.GetRequiredWorkloads.CrossTargeting.targets" />
Copy link
Contributor

@Nirmal4G Nirmal4G Jul 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This targets file is meant to have multi-targeting/outer-build logic for Workloads, right?
So, the following name below might make more sense!

Suggested change
<Import Project="$(MSBuildThisFileDirectory)Microsoft.NET.Sdk.GetRequiredWorkloads.CrossTargeting.targets" />
<Import Project="$(MSBuildThisFileDirectory)Microsoft.NET.Sdk.Workloads.CrossTargeting.targets" />

@wli3 wli3 force-pushed the workload-restore2 branch from d3814a9 to df633b7 Compare July 19, 2021 21:36
@wli3
Copy link
Author

wli3 commented Jul 19, 2021

@dsplaisted all issue addressed

@wli3 wli3 force-pushed the workload-restore2 branch from df633b7 to c95fa4b Compare July 19, 2021 22:38
@wli3
Copy link
Author

wli3 commented Jul 19, 2021

@dsplaisted I'll merge once tests pass

@wli3 wli3 enabled auto-merge July 19, 2021 22:55
@wli3 wli3 force-pushed the workload-restore2 branch from c95fa4b to 87b09f9 Compare July 19, 2021 23:29
@wli3 wli3 force-pushed the workload-restore2 branch from 87b09f9 to bbd4211 Compare July 20, 2021 02:15
Adding _FindAllReferenceWorkload target to find workloads in project.
Discover the projects and then pipe all arguements to workload install
command
@wli3 wli3 force-pushed the workload-restore2 branch from bbd4211 to 5d2faf1 Compare July 20, 2021 04:36
@wli3 wli3 merged commit 17181d3 into dotnet:main Jul 20, 2021
@wli3 wli3 deleted the workload-restore2 branch July 20, 2021 15:59
@marcpopMSFT marcpopMSFT mentioned this pull request Jul 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants