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

Implementation for Zip Install (Non-Portable) #2320

Merged
merged 8 commits into from
Jul 13, 2022

Conversation

ryfu-msft
Copy link
Contributor

@ryfu-msft ryfu-msft commented Jul 8, 2022

Related to:
#140

Changes:

  • Adds the initial implementation for supporting installing from a zip file that contains a nested installer
  • Does not add support for nested Portable packages which will be addressed in a separate PR due to complexity

Tests:

  • Added E2E tests
  • Added Unit tests for verifying zip workflow and archive extraction behavior
Microsoft Reviewers: Open in CodeFlow

@ryfu-msft ryfu-msft requested a review from a team as a code owner July 8, 2022 20:34
@@ -64,6 +64,7 @@ namespace AppInstaller::CLI::Execution
// TODO: Remove when the source interface is refactored.
TreatSourceFailuresAsWarning = 0x10,
ShowSearchResultsOnPartialFailure = 0x20,
InstallerExtractedFromArchive = 0x40,
Copy link
Member

Choose a reason for hiding this comment

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

There are a few options here:

  1. This
  2. Move installer type to be a context data item
  3. Leverage IsArchiveType

Option 3 seems to be the least amount of adding additional context data and the easiest. Is there any case in which we wouldn't use the nested type for an archive?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed InstallerExtractedFromArchive context flag.

Added ExecuteInstallerForInstallerType which selects the appropriate install flow based on the installerType to handle whether to use InstallerType or NestedInstallerType

src/AppInstallerCLICore/Workflows/ArchiveFlow.cpp Outdated Show resolved Hide resolved
src/AppInstallerCLICore/Workflows/ArchiveFlow.cpp Outdated Show resolved Hide resolved
src/AppInstallerCLICore/Workflows/ArchiveFlow.h Outdated Show resolved Hide resolved
Comment on lines 390 to 393
context <<
ExtractInstallerFromArchive <<
VerifyAndSetNestedInstaller <<
ExecuteInstaller;
Copy link
Member

Choose a reason for hiding this comment

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

This flow will be less efficient for portables; we should just extract directly to the final location. Not sure if that works great with the database tracking files though. We might need to be less efficient just so any files we could lose track of are in %TEMP% and will be more readily cleaned up.

Copy link
Contributor Author

@ryfu-msft ryfu-msft Jul 12, 2022

Choose a reason for hiding this comment

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

I am thinking that portables will require more tasks than the one I have currently specified.
Here is what I am proposing when we start the implementation for portable(s) in an archive.

  • ExtractInstallerFromArchive (now called ExtractFilesFromArchive) will have a separate flow for portables that will copy the extracted files to the final portable install location
  • TryExtractArchive will have an additional parameter to indicate whether we will append to the database file in the final install location to keep track of the files that are extracted and copied.
  • The install location will need to have the directory created prior to extraction, so this will likely need to be its own step that creates the InstallDirectory and the local db file if it does not exist already. So something like SetupPortableInstallDirectory that we call prior to all of these steps if the NestedInstallerType is Portable

Once we enter the portable install flow, we can then use IsArchiveType to check whether we should install multiple portables for a given archive package.

Comment on lines 390 to 393
context <<
ExtractInstallerFromArchive <<
VerifyAndSetNestedInstaller <<
ExecuteInstaller;
Copy link
Member

Choose a reason for hiding this comment

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

My gut is to create ExecuteInstallerForType(InstallerType) and then have ExecuteInstaller call it with installer.InstallerType and this call it with installer.NestedInstallerType rather than the extra state management.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added ExecuteInstallerForType(Context, InstallerType) to handle the install flow selection logic based on installerType

src/AppInstallerCommonCore/Archive.cpp Outdated Show resolved Hide resolved
src/AppInstallerCommonCore/Archive.cpp Outdated Show resolved Hide resolved
src/AppInstallerCommonCore/Archive.cpp Outdated Show resolved Hide resolved
@ghost ghost added the Needs-Author-Feedback Issue needs attention from issue or PR author label Jul 11, 2022
@ghost ghost removed the Needs-Author-Feedback Issue needs attention from issue or PR author label Jul 12, 2022
@ryfu-msft ryfu-msft requested a review from JohnMcPMS July 12, 2022 23:38
@@ -318,22 +318,10 @@ namespace AppInstaller::CLI::Workflow
}
}

void ExecuteInstaller(Execution::Context& context)
void ExecuteInstallerForType(Execution::Context& context, InstallerTypeEnum installerType)
Copy link
Member

Choose a reason for hiding this comment

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

The intention was to create a WorkflowTask derivative. Example:

struct ShowPackageAgreements : public WorkflowTask

That allows the continued use of the stream operators rather than checking IsTerminated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Created a WorkflowTask derivative for ExecuteInstallerForType

@@ -1370,4 +1370,8 @@ Please specify one of them using the `--source` option to proceed.</value>
<data name="NestedInstallerNotFound" xml:space="preserve">
<value>Nested installer file does not exist. Ensure the specified relative path of the nested installer matches: </value>
</data>
<data name="NestedInstallerFilesNotSpecified" xml:space="preserve">
<value>No nested installer files specified; ensure that your manifest includes an entry for NestedInstallerFiles</value>
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
<value>No nested installer files specified; ensure that your manifest includes an entry for NestedInstallerFiles</value>
<value>No nested installer files specified; ensure that the manifest includes an entry for NestedInstallerFiles</value>

Is this actually possible per the basic manifest validation? I wanted the check for empty to ensure that we didn't crash, but if we don't think it will actually happen due to previous checks then the localized string doesn't seem necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a comment clarifying that this check should be prevented by manifest validation and removed localized string.

if (SUCCEEDED(hr))
wil::com_ptr<IShellItem> pShellItemFrom;
STRRET strFolderName;
WCHAR szFolderName[MAX_PATH];
Copy link
Member

Choose a reason for hiding this comment

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

Are the paths actually limited to MAX_PATH? If not, I would prefer if we could do a variable length path so that we don't hit a length issue here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

STRRET is has a max buffer length of MAX_PATH but this should be okay as it is only the name of the file

@ghost ghost added the Needs-Author-Feedback Issue needs attention from issue or PR author label Jul 13, 2022
@ghost ghost removed the Needs-Author-Feedback Issue needs attention from issue or PR author label Jul 13, 2022
@ryfu-msft ryfu-msft merged commit 662842c into microsoft:master Jul 13, 2022
@ryfu-msft ryfu-msft deleted the zipInstall branch July 13, 2022 20:06
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.

3 participants