Skip to content

Conversation

@TravisEz13
Copy link
Member

@TravisEz13 TravisEz13 commented Sep 10, 2018

PR Summary

Make sure MSI build works when not preview

PR Checklist

<Component Id="SetPath" Guid="{9dbb7763-7baf-48e7-b025-3bdedcb0632f}" KeyPath="yes">
<Condition>ADD_PATH=1</Condition>
<Environment Id="PATH" Action="set" Name="PATH" Part="last" Permanent="no" System="yes" Value="[$(var.ProductDirectoryName)]$(var.PwshPath)"/>
<Environment Id="PATH" Action="set" Name="PATH" Part="last" Permanent="no" System="yes" Value="$(var.PwshPath)"/>
Copy link
Member

Choose a reason for hiding this comment

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

Just curious on why we are making these changes. It looks to me this change doesn't change the behavior -- Value="[$(var.ProductDirectoryName)]$(var.PwshPath)" basically does the same before the change, isn't it?

Copy link
Member Author

@TravisEz13 TravisEz13 Sep 10, 2018

Choose a reason for hiding this comment

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

The variable is set to empty (meaning to delete the variable) in the non-preview case and the build fails

@bergmeister
Copy link
Contributor

bergmeister commented Sep 10, 2018

@TravisEz13 Can you please explain briefly? To me it looks like this is a stylistic change only and not a fix

@TravisEz13
Copy link
Member Author

@bergmeister The variable is set to empty (meaning to delete the variable) in the non-preview case and the build fails

@TravisEz13 TravisEz13 merged commit 172a8a0 into PowerShell:master Sep 10, 2018
@TravisEz13
Copy link
Member Author

used admin to squash when windows CI was finished as this did not affect other platforms

TravisEz13 added a commit that referenced this pull request Sep 10, 2018
The variable was set to empty (meaning to delete the variable) in the non-preview case and the build fails.
The fix avoids setting the variable to empty
@TravisEz13 TravisEz13 added this to the v6.1.0 milestone Sep 10, 2018
@TravisEz13 TravisEz13 deleted the Fix_msi_for_6_1 branch September 10, 2018 21:37
@TravisEz13
Copy link
Member Author

@bergmeister feel free to continue the discussion. This was blocking the 6.1 builds so I merged so it's easier to take for the build.

else
{
[Environment]::SetEnvironmentVariable("PwshPath", 'preview', "Process")
[Environment]::SetEnvironmentVariable("PwshPath", "[$productDirectoryName]preview", "Process")
Copy link
Contributor

@bergmeister bergmeister Sep 10, 2018

Choose a reason for hiding this comment

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

@TravisEz13 Non-blocking comment: Would it not be cleaner if a the variable was declared directly here to not convolute the script with WiX syntax?

Copy link
Member Author

Choose a reason for hiding this comment

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

This variable was already there and only used for this purpose. I don't think I'm getting the meaning of your statement.

Copy link
Member Author

Choose a reason for hiding this comment

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

I do think there is probably a cleaner way of doing this. Like refering to the preview directory by name, but the goal here was to make a quick change that would not require a lot of re-testing for the 6.1.0 release.

Copy link
Contributor

Choose a reason for hiding this comment

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

[$productDirectoryName]preview is WiX syntax that we inject into the WiX file. The build script should be generic and know as little about WiX as possible to reduce coupling if installer technology changed for example or WiX 4 brings breaking changes in syntax. How about this:

[Environment]::SetEnvironmentVariable("PwshPath", (Join-Path $productDirectoryName 'preview'), "Process")

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm fine with that change for 6.2.

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