-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Conversation
@@ -64,6 +64,7 @@ namespace AppInstaller::CLI::Execution | |||
// TODO: Remove when the source interface is refactored. | |||
TreatSourceFailuresAsWarning = 0x10, | |||
ShowSearchResultsOnPartialFailure = 0x20, | |||
InstallerExtractedFromArchive = 0x40, |
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.
There are a few options here:
- This
- Move installer type to be a context data item
- 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?
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.
Removed InstallerExtractedFromArchive
context flag.
Added ExecuteInstallerForInstallerType
which selects the appropriate install flow based on the installerType to handle whether to use InstallerType
or NestedInstallerType
context << | ||
ExtractInstallerFromArchive << | ||
VerifyAndSetNestedInstaller << | ||
ExecuteInstaller; |
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 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.
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.
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 calledExtractFilesFromArchive
) will have a separate flow for portables that will copy the extracted files to the final portable install locationTryExtractArchive
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 theNestedInstallerType
isPortable
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.
context << | ||
ExtractInstallerFromArchive << | ||
VerifyAndSetNestedInstaller << | ||
ExecuteInstaller; |
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.
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.
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.
Added ExecuteInstallerForType(Context, InstallerType)
to handle the install flow selection logic based on installerType
@@ -318,22 +318,10 @@ namespace AppInstaller::CLI::Workflow | |||
} | |||
} | |||
|
|||
void ExecuteInstaller(Execution::Context& context) | |||
void ExecuteInstallerForType(Execution::Context& context, InstallerTypeEnum installerType) |
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.
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
.
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.
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> |
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.
<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.
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.
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]; |
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.
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.
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.
STRRET is has a max buffer length of MAX_PATH but this should be okay as it is only the name of the file
Related to:
#140
Changes:
Tests:
Microsoft Reviewers: Open in CodeFlow