WIP Make it easier to build an installable package locally for WiX development and document it #5499

bergmeister · 2017-11-18T12:32:00Z

Issue #5012 has highlighted that it is not easy to get started with development work on the Windows installer.

This PR documents for the first time how to build an installable package locally and simplifies the process by moving New-MSIPackage to the packaging module where it better belongs to and more defaults/validation are added as well.

Since New-MSIPackage throws a very nice error with a download link to the required WiX toolset, I decided to not duplicate this in the documentation about having to install the WiX toolset.

I guess the best reviewer is @SteveL-MSFT who recently did a lot of installer work.

…ed by blank lines

iSazonov · 2017-11-18T14:11:15Z

docs/building/windows-core.md


 We currently have the issue [#3400](https://github.com/PowerShell/PowerShell/issues/3400) tracking this task.
+
+## Building an installer


We use Start-PSPackage function. See https://github.com/PowerShell/PowerShell/blob/cb048ea9f4f7ccc3612141ee76f7937b9ca1c823/docs/maintainers/releasing.md

Start-PSPackage is not very developer friendly because it has requirements such as that the checkout must be at the root of the filesystem and that PowerShell has to be compiled in a very specific way. The purpose of this PR is to make it easier to build MSIs locally when changing WiX code.

Start-PSPackage also does some other checks, but that's more intended for creating a release package and I can understand the scenario for a developer testing their wix changes. However, it's actually pretty easy to have PowerShell repo as your root using either New-PSDrive or Subst.

I think we should support one entry point - it is easily to support (in docs too).
Also it will be best to have the same code (csproj?) to build on local and on GitHub.

iSazonov · 2017-11-18T14:13:06Z

build.psm1

+    if ($null -eq (Get-Module packaging))
+    {
+        # Import Get-PackageSemanticVersion function from packaging module
+        Import-Module "$PSScriptRoot\tools\packaging\packaging.psd1"


I was sure we were using auto-loading.

See the example where it only imports build.psm1. We would need to have a module manifest for the build module then. Or maybe New-MSIPackage should be moved into the packaging module instead?

New-MSIPackage should be moved

SteveL-MSFT · 2017-11-18T19:39:11Z

build.psm1


+<#
+.Synopsis
+    Creates a Windows installer MSI file and assumes that the binaries are already built using 'Start-PSBuild'.


change the word file to package

SteveL-MSFT · 2017-11-18T19:43:28Z

docs/building/windows-core.md


 We currently have the issue [#3400](https://github.com/PowerShell/PowerShell/issues/3400) tracking this task.
+
+## Building an installer


Start-PSPackage also does some other checks, but that's more intended for creating a release package and I can understand the scenario for a developer testing their wix changes. However, it's actually pretty easy to have PowerShell repo as your root using either New-PSDrive or Subst.

SteveL-MSFT · 2017-11-18T19:44:35Z

docs/building/windows-core.md


 We currently have the issue [#3400](https://github.com/PowerShell/PowerShell/issues/3400) tracking this task.
+
+## Building an installer


Instead of calling it Building an installer, I think it's more correct to say Building an Installable Package (where installer is msi)

codecov-io · 2017-11-18T19:51:31Z

Codecov Report

Merging #5499 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5499      +/-   ##
==========================================
+ Coverage   60.83%   60.84%   +0.01%     
==========================================
  Files         924      929       +5     
  Lines      274195   273880     -315     
==========================================
- Hits       166793   166642     -151     
+ Misses     107402   107238     -164

Impacted Files	Coverage Δ
....Management.Automation/security/SecurityManager.cs	`30.51% <0%> (-7.56%)`	⬇️
....PowerShell.Security/security/SignatureCommands.cs	`24.77% <0%> (-5.97%)`	⬇️
...ft.PowerShell.Security/security/CatalogCommands.cs	`80.19% <0%> (-5.95%)`	⬇️
...Cmdlet/Common/BasicHtmlWebResponseObject.Common.cs	`32.75% <0%> (-5.23%)`	⬇️
...s/utility/WebCmdlet/Common/ContentHelper.Common.cs	`57.33% <0%> (-5.17%)`	⬇️
....Management/commands/management/PingPathCommand.cs	`77.94% <0%> (-4.42%)`	⬇️
.../System.Management.Automation/engine/Attributes.cs	`69.23% <0%> (-3.71%)`	⬇️
...agement.Automation/engine/interpreter/Utilities.cs	`50.8% <0%> (-2.5%)`	⬇️
...nagement.Automation/engine/runtime/MutableTuple.cs	`38.51% <0%> (-2.1%)`	⬇️
...ment.Automation/engine/CompiledCommandParameter.cs	`90.8% <0%> (-1.92%)`	⬇️
... and 35 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 79ae396...8f956f3. Read the comment docs.

TravisEz13 · 2017-11-18T20:28:48Z

docs/building/windows-core.md

+````powershell
+Import-Module .\build.psm1
+Start-PSBuild
+New-MSIPackage -ProductSourcePath '.\src\powershell-win-core\bin\Debug\netcoreapp2.0\win7-x64\publish' -ProductTargetArchitecture x64 -ProductVersion '1.2.3'


New-MSI package should not be exposed.

You could document how to use start-PsPackage for this purpose with the -SkipReleaseChecks parameter.

TravisEz13

see comments

… expose instructions in building/windows-core.md

…t commit

iSazonov · 2017-11-19T17:41:34Z

@bergmeister Could you please correct the PR title and description?

bergmeister · 2017-11-19T19:07:20Z

@iSazonov OK. I've adapted the title and description now to make it clearer that it is about WiX development where one does care too much what exactly lands in the package.

SteveL-MSFT · 2017-11-19T19:18:12Z

Thinking further about this, I think I prefer not exposing New-MSIPackage and treat that as an internal function. Have users use Start-PSPackage (so a single way to create msi packages rather than two ways). However, we can update Start-PSPackage to automatically create a PSDrive to resolve the "root folder" requirement (to not expose "private" folder path information) and use that.

bergmeister · 2017-11-19T19:24:53Z

@SteveL-MSFT If you do not want to expose New-MSIPackage any more, then an alternative would be to remove it from the manifest in CmdletsToExport and then only insiders would import the psm1 instead of the psd1 instead. WDYT?

SteveL-MSFT · 2017-11-20T22:22:53Z

I think we should remove New-MSIPackage from exported cmdlets

Tested it still work in a clean checkout

SteveL-MSFT · 2017-11-20T22:58:49Z

tools/packaging/packaging.psm1

    Import-Module .\build.psm1
    Start-PSBuild
-    Import-Module .\tools\packaging\packaging.psd1
+    Import-Module .\tools\packaging\packaging.psm1


this line is no longer needed since it's part of packaging.psm1 already

I see what you mean but the idea was to provide a copy-pasteable example that works out of the box. Would it be OK to rather squash the initialization as Import-Module .\build.psm1; Start-PSBuild; Import-Module .\tools\packaging\packaging.psm1? Otherwise I'll of course remove the line if you insist.

For the comment based help, you would only see that if you already have the packaging module loaded, so it just seems weird. I think if you want to provide an easy cut-paste, perhaps it's better to have it in https://github.com/PowerShell/PowerShell/blob/master/docs/building/windows-core.md

TravisEz13 · 2017-11-21T00:33:46Z

tools/packaging/packaging.psm1

+    cd $RootPathOfPowerShellCheckout
+    Import-Module .\build.psm1
+    Start-PSBuild
+    Import-Module .\tools\packaging\packaging.psm1


Just point to import the folder as a module.

…o wix_dev_friendly

iSazonov · 2018-01-10T09:18:58Z

@bergmeister Please resolve merge conflicts.

bergmeister · 2018-01-10T10:03:56Z

Ok, thanks for letting me know. I will come back to it soon (but not today) since it needs more time carefully extracting the diff because the conflict is quite horrible due to the move of a function that has received updates in the meantime. Maybe even a new PR with 2 separate commits (one with the improvements and one with the move) might be better to avoid accidentally reverting code changes. What do you think?

iSazonov · 2018-01-10T12:37:19Z

@bergmeister Perhaps easy make new PR.

bergmeister added 2 commits November 18, 2017 12:15

Make it easier to build an installer locally and document it.

fd07003

Fix markdown lint warning MD031 Fenced code blocks should be surround…

7357aa9

…ed by blank lines

bergmeister requested review from TravisEz13, adityapatwardhan and daxian-dbw as code owners November 18, 2017 12:32

iSazonov reviewed Nov 18, 2017

View reviewed changes

iSazonov assigned TravisEz13 Nov 18, 2017

iSazonov requested a review from SteveL-MSFT November 18, 2017 14:14

SteveL-MSFT requested changes Nov 18, 2017

View reviewed changes

change wording of help to build installable package as suggested in PR.

8dce4c3

TravisEz13 reviewed Nov 18, 2017

View reviewed changes

TravisEz13 requested changes Nov 18, 2017

View reviewed changes

bergmeister added 2 commits November 18, 2017 20:44

Move New-MSIPackage to packaging module as suggested in PR but do not…

d5e453c

… expose instructions in building/windows-core.md

Remove New-MSiPackage cmdlet help, which was already moved in the las…

6025d08

…t commit

TravisEz13 approved these changes Nov 19, 2017

View reviewed changes

bergmeister changed the title ~~Make it easier to build an installer locally and document it~~ Make it easier to build an installable package locally for WiX development and document it Nov 19, 2017

bergmeister closed this Nov 20, 2017

bergmeister reopened this Nov 20, 2017

Do not expose New-MSIPackage in packaging manifest as agreed in PR.

d330560

Tested it still work in a clean checkout

SteveL-MSFT requested changes Nov 20, 2017

View reviewed changes

TravisEz13 reviewed Nov 21, 2017

View reviewed changes

tweak new-msipackage help

8036a60

SteveL-MSFT approved these changes Nov 21, 2017

View reviewed changes

Merge branch 'master' of https://github.com/PowerShell/PowerShell int…

24e5de4

…o wix_dev_friendly

Merge branch 'master' of https://github.com/PowerShell/PowerShell int…

8f956f3

…o wix_dev_friendly

bergmeister changed the title ~~Make it easier to build an installable package locally for WiX development and document it~~ WIP Make it easier to build an installable package locally for WiX development and document it Jan 10, 2018

bergmeister mentioned this pull request Jan 11, 2018

Packaging: simplify building an installable package for Windows #5871

Merged

8 tasks

bergmeister closed this Jan 11, 2018


		We currently have the issue [#3400](https://github.com/PowerShell/PowerShell/issues/3400) tracking this task.

		## Building an installer

WIP Make it easier to build an installable package locally for WiX development and document it #5499

WIP Make it easier to build an installable package locally for WiX development and document it #5499

Uh oh!

Conversation

bergmeister commented Nov 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergmeister Nov 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergmeister Nov 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov-io commented Nov 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TravisEz13 left a comment

Choose a reason for hiding this comment

Uh oh!

iSazonov commented Nov 19, 2017

Uh oh!

bergmeister commented Nov 19, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SteveL-MSFT commented Nov 19, 2017

Uh oh!

bergmeister commented Nov 19, 2017

Uh oh!

SteveL-MSFT commented Nov 20, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iSazonov commented Jan 10, 2018

Uh oh!

bergmeister commented Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iSazonov commented Jan 10, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

bergmeister commented Nov 18, 2017 •

edited

Loading

bergmeister Nov 18, 2017 •

edited

Loading

bergmeister Nov 18, 2017 •

edited

Loading

codecov-io commented Nov 18, 2017 •

edited

Loading

bergmeister commented Nov 19, 2017 •

edited

Loading

bergmeister commented Jan 10, 2018 •

edited

Loading