Skip to content

Build tasks for optional workload generation/authoring#7169

Merged
joeloff merged 2 commits intodotnet:mainfrom
joeloff:joeloff/workloads
Apr 6, 2021
Merged

Build tasks for optional workload generation/authoring#7169
joeloff merged 2 commits intodotnet:mainfrom
joeloff:joeloff/workloads

Conversation

@joeloff
Copy link
Member

@joeloff joeloff commented Mar 30, 2021

Initial set of build tasks to unblock workload authoring so consumers can evaluate and see whether it fits into their workflow.

Tasks include

  • Converting static nupkg to MSI for workload (no manifest)
  • Converting workload manifest packages into a group of MSIs
  • Auto generating SWIX authoring for MSIs and components
  • Creating empty merge manifest projects for producing .vsman files (related to VSDROP based insertions).

Tests are being worked on.

@joeloff joeloff requested review from dsplaisted, sfoslund and wli3 March 30, 2021 18:01
@joeloff
Copy link
Member Author

joeloff commented Mar 30, 2021

@mmitche any suggestions who from the Arcade side I can add?

@jonathanpeppers and @pranavkm as an FYI.

@mmitche
Copy link
Member

mmitche commented Mar 30, 2021

@chcosta Is good at these types of reviews.

@joeloff joeloff requested a review from chcosta March 30, 2021 18:05
@chcosta
Copy link
Member

chcosta commented Mar 30, 2021

Ack. There's a lot of changes. I'll try to look today, but more likely have to set aside time tomorrow.

@joeloff
Copy link
Member Author

joeloff commented Mar 30, 2021

Thanks @chcosta

@chcosta
Copy link
Member

chcosta commented Apr 2, 2021

Sorry, I didn't get you this today. 🙁

Copy link
Member

@chcosta chcosta left a comment

Choose a reason for hiding this comment

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

Seems fine, though admittedly, my eyes glazed over at some of the nuance of msi-ness that I haven't looked at for quite a while now. Left a couple of minor bits of feedback.

Not having tests, make it hard for me to do any validation apart from staring at the code on screen. If you want a more detailed review of the msi / setup stuff, you might ask Nikola, but in general this looks reasonable.

<Compile Include="..\..\Common\Internal\BuildTask.cs" />
</ItemGroup>

<ItemGroup Condition="'$(TargetFramework)' == 'net472'">
Copy link
Member

Choose a reason for hiding this comment

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

Is this condition needed?

@joeloff joeloff merged commit 0457d51 into dotnet:main Apr 6, 2021
akoeplinger pushed a commit to akoeplinger/arcade that referenced this pull request Apr 12, 2021
* Build tasks for optional workload generation/authoring

* PR feedback
@jkoritzinsky
Copy link
Member

Can we try to share some of the work here with Microsoft.DotNet.Build.Tasks.Installers? Or is that not possible with the workload design?

@joeloff
Copy link
Member Author

joeloff commented Apr 14, 2021

@jkoritzinsky such as sharing code?

@jkoritzinsky
Copy link
Member

Yes, that's what I was thinking.

@joeloff
Copy link
Member Author

joeloff commented Apr 14, 2021

Ah, the installers for the workloads are very specific and a lot of the tasks focus on generating the corresponding authoring for Visual Studio.

@jkoritzinsky
Copy link
Member

Ah that makes sense.

Is there any way we can make part of the UX of the packages similar so that (for example) moving dotnet/windowsdesktop to use it would be as simple as changing a project reference? At least for the simple cases of the Installers package.

Or would building the workloads infra on top of the installers package infra make any sense?

If that’s not possible it’s ok, but I’d like to share/layer if possible. If not with the Installers package than layer on top of the Shared Framework SDK.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants