Feature request: Submitter installer should update only the selected DCC(s) without replacing the whole DeadlineCloudSubmitter directory

[oehmends]

Describe the problem

When I run the Deadline Cloud Submitter installer on Windows (DeadlineCloudSubmitter-windows-x64-installer.exe) to update the submitter for a single DCC, the component selection screen is destructive. Whatever set of DCCs I check on the "Select Components" page becomes the entire contents of the installed DeadlineCloudSubmitter directory. The installer replaces the whole directory with just my new selection rather than merging with what was already installed.

Concretely:

1. I have previously installed submitters for several DCCs (e.g. Maya, Nuke, Houdini) into DeadlineCloudSubmitter.
2. Later I only want to update one submitter (say Maya).
3. I re-run the installer and check only Maya (which is the natural thing to do, since I only want to touch Maya).
4. The installer wipes/replaces the DeadlineCloudSubmitter directory so that only the Maya submitter remains. The submitters for the other DCCs I did not re-select are gone.

Because of this, before every update I have to remember the exact set of components I previously installed and re-check all of them, or manually back up the DeadlineCloudSubmitter directory for the DCCs I don't want to lose and restore them afterwards. This is error-prone and frustrating for what should be a simple "update one submitter" operation. It's easy to accidentally remove working submitters for other DCCs.

This behaviour is closely related to how the installer manages the shared DeadlineCloudSubmitter install directory across components (see also #307 for other install-scope/pathing behaviours of the same installer).

Installer instructions for context: https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submitter.html

Proposed Solution

Make the installer's component selection non-destructive / incremental so that updating one DCC does not remove submitters for DCCs that are already installed. Some options:

1. Pre-populate the component checkboxes from what is already installed. When re-running the installer against an existing DeadlineCloudSubmitter install, detect the currently installed components and check them by default. The user can then just add/remove intentionally instead of losing everything they don't re-check.
2. Treat unselected components as "leave as-is" rather than "remove". Only install/overwrite the components that are checked; leave previously installed components untouched. Provide a separate, explicit "uninstall/remove" flow for removing a component.
3. At minimum, warn before removing already-installed components ("You have Nuke and Houdini submitters installed but they are not selected. Continue and remove them?") so the destructive replacement is not silent.

The clearest fix is a combination of (1) and (2): detect existing components, pre-check them, and only modify the components the user actually changed.

Example Use Cases

Interactive update of a single submitter without clobbering the others:

# Existing install already contains Maya + Nuke + Houdini submitters
DeadlineCloudSubmitter/
  ├─ maya submitter (v A)
  ├─ nuke submitter (v A)
  └─ houdini submitter (v A)

# Run installer, select ONLY Maya to update it
DeadlineCloudSubmitter-windows-x64-installer.exe

# Desired result: only Maya is updated, Nuke + Houdini are preserved
DeadlineCloudSubmitter/
  ├─ maya submitter (v B)   <- updated
  ├─ nuke submitter (v A)   <- preserved
  └─ houdini submitter (v A) <- preserved

Unattended/scripted update where I only want to touch one component and keep the rest:

# Today this replaces the whole install with just Maya, dropping Nuke/Houdini.
# Desired: --enable-components only adds/updates the listed components and
# leaves already-installed components in place.
.\DeadlineCloudSubmitter-windows-x64-installer.exe `
  --mode unattended `
  --enable-components deadline_cloud_for_maya
# Nuke and Houdini submitters that were installed previously should remain.

[larrygao001]

Part of this behavior was added deliberately to keep upgrades clean. Running the previous version's uninstaller first prevents stale files, duplicate entries in Programs and Features, and duplicate PATH/environment entries. But we agree the side effect of silently removing submitters you didn't re-select is surprising and error-prone, especially for the common "update just one DCC" workflow.

We're treating this as a valid feature request and are looking at improvements along the lines you suggested.