-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Fix parallel builds by specifying the application type for WAP #7783
Conversation
The WAP packaging project in VS <= 16.7.3 produces a global property as part of its normal operation that causes MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing this property to match the WAP values, we can get consistent builds. That property is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This is just like #3412, but a couple versions of VS in the future. If you want to read a pareto-identical commit message, go read that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is absolutely bonkers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nnnnn. Yes.
@msftbot merge this when it's done building |
Hello @DHowett! I think you told me that you want to delay the approval for a certain amount of time, but I am not confident that I have understood you correctly. Please try rephrasing your instruction to me. |
@msftbot merge this when 5 minutes do |
Hello @DHowett! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
This failed in x86 with no explanation. Really loving it. |
Fundamental change in approach.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
@@ -11,6 +11,7 @@ | |||
<OpenConsoleUniversalApp>false</OpenConsoleUniversalApp> | |||
<ApplicationType>Windows Store</ApplicationType> | |||
<NoOutputRedirection>true</NoOutputRedirection> | |||
<TargetPlatformIdentifier>Windows</TargetPlatformIdentifier> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<!-- LOAD BEARING CODE: If we don't say Windows here, the project system might get confused and start building and not building APPXs because of the implicit decisions on UWP. -->
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
idk about that one -- this feels more correct (like, just that we shoulda specified it).. but i can see the argument
The WAP packaging project is sensitive to including applications that it
thinks are UWPs. The changes we made to separate WindowsStoreApp and
WindowsAppContainer weren't comprehensive enough to convince WAP that we
were not still UWPs.
Because of that, it would run sub-builds of each of these projects (and
all their dependencies) with an additional
GenerateAppxPackageOnBuild
property set. The existence of this property caused MSBuild to think the
projects needed to be built again.