Skip to content

feat: extend ApiModule to support unified Proton Suite (Mail, Drive, Pass, VPN)#119

Open
HardikYerne wants to merge 1 commit into
ProtonVPN:masterfrom
HardikYerne:master
Open

feat: extend ApiModule to support unified Proton Suite (Mail, Drive, Pass, VPN)#119
HardikYerne wants to merge 1 commit into
ProtonVPN:masterfrom
HardikYerne:master

Conversation

@HardikYerne

Copy link
Copy Markdown

Problem

When installing Proton VPN on Windows, the installer registers multiple separate
entries in Programs & Features / Apps & Features:

  • Proton VPN (main app)
  • TAP-ProtonVPN Windows Adapter
  • ProtonVPN Split Tunnel Driver (or similar)
  • (Optionally) other Proton apps

This is confusing for users who expect a single application. It makes uninstallation
unclear and gives the impression that the install is broken or incomplete.

Expected Behavior

All core VPN components (TAP adapter, Split Tunnel driver, service) should be bundled
under a single installer entry. Users should only see "Proton VPN" in their installed
apps list, and uninstalling it should cleanly remove all related components.

Suggested Solution

  • Use a unified installer (e.g., Advanced Installer suite feature) that registers
    only one top-level product entry
  • Driver and service components should be installed silently as part of the main
    product, without creating separate Programs & Features entries
  • On uninstall, all sub-components should be removed automatically

Why This Matters

  • Reduces user confusion
  • Improves perceived app quality
  • Simplifies clean uninstallation
  • Consistent with how most professional Windows apps handle bundled drivers/services

Environment

  • Windows 11 (or your version)
  • Proton VPN version: (check in the app → About)

@HardikYerne

Copy link
Copy Markdown
Author

Hi Proton team! 👋

I noticed that installing Proton VPN alongside Mail, Drive and Pass
creates multiple separate entries in Windows Apps & Features.

This PR extends ApiModule.cs to register all Proton app API clients
in one place as a first step toward a unified Proton Suite installer.

Happy to make any changes based on your feedback!

Thanks,
Hardik

@HardikYerne HardikYerne changed the title [Feature Request] Consolidate installer components into a single Programs & Features entry feat: extend ApiModule to support unified Proton Suite (Mail, Drive, Pass, VPN) Jun 23, 2026
@HardikYerne

Copy link
Copy Markdown
Author

Hi team! This PR is ready for review.
No conflicts with base branch.
Happy to make any changes! 🙏

@rkhan65159-cell

Copy link
Copy Markdown

Yy

@rkhan65159-cell

Copy link
Copy Markdown

About pull requests

Pull requests let you propose, review, and merge code changes.

Pull requests are proposals to merge code changes into a project. A pull request is GitHub's foundational collaboration feature, letting you discuss and review changes before merging them. This helps teams work together, catch issues early, and maintain code quality.

View your pull requests

Working with pull requests

The Conversation tab of a pull request displays a description of the changes, a timeline of events, and comments and reviews from collaborators. This central hub lets you track the discussion and progress of the proposed changes.

The Commits tab shows all commits made to the pull request branch in chronological order. This helps you understand the development history and see how the changes evolved over time.

The Checks tab displays the status of any automated tests, builds, or other continuous integration workflows that run when you push commits. These checks help ensure your changes meet quality standards before merging.

The Files changed tab shows the differences between the proposed changes and the existing code, making it easy to see what will change when the pull request merges.

The Merge status of a pull request can be viewed directly in the header from anywhere in the pull request page. Click to open the details so you can quickly identify blockers, missing approvals, and get your pull request ready to merge.

Draft pull requests

When you create a pull request, you can choose to make it a draft pull request. Draft pull requests cannot be merged, and code owners are not automatically requested to review them. This is useful when you want to share work-in-progress without formally requesting reviews.

When you're ready to get feedback on your pull request, you can mark your draft pull request as ready for review. Marking a pull request as ready for review will request reviews from any code owners. You can convert a pull request to a draft at any time. See Changing the stage of a pull request.

Pull request refs and merge branches

When you open a pull request, GitHub creates up to two temporary, read-only Git references for it:

Ref Description
refs/pull/PULL_REQUEST_NUMBER/head Points to the latest commit on the pull request's head branch.
refs/pull/PULL_REQUEST_NUMBER/merge A merge branch—a simulated merge commit that represents what the repository would look like if the pull request were merged right now. This ref is only available when the pull request has no merge conflicts.

The merge branch automatically updates when the head branch changes. To fetch it locally:

git fetch origin refs/pull/PULL_REQUEST_NUMBER/merge
git checkout FETCH_HEAD

Replace PULL_REQUEST_NUMBER with the number of your pull request.

For information about how GitHub Actions uses the merge branch, see Events that trigger workflows.

Differences between commits on compare and pull request pages

The compare and pull request pages use different methods to calculate the diff for changed files:

  • Compare pages show the diff between the tip of the head ref and the current common ancestor (that is, the merge base) of the head and base ref.
  • Pull request pages show the diff between the tip of the head ref and the common ancestor of the head and base ref at the time when the pull request was created. As a result, the merge base used for the comparison might be different.

Further reading

1 similar comment
@rkhan65159-cell

Copy link
Copy Markdown

About pull requests

Pull requests let you propose, review, and merge code changes.

Pull requests are proposals to merge code changes into a project. A pull request is GitHub's foundational collaboration feature, letting you discuss and review changes before merging them. This helps teams work together, catch issues early, and maintain code quality.

View your pull requests

Working with pull requests

The Conversation tab of a pull request displays a description of the changes, a timeline of events, and comments and reviews from collaborators. This central hub lets you track the discussion and progress of the proposed changes.

The Commits tab shows all commits made to the pull request branch in chronological order. This helps you understand the development history and see how the changes evolved over time.

The Checks tab displays the status of any automated tests, builds, or other continuous integration workflows that run when you push commits. These checks help ensure your changes meet quality standards before merging.

The Files changed tab shows the differences between the proposed changes and the existing code, making it easy to see what will change when the pull request merges.

The Merge status of a pull request can be viewed directly in the header from anywhere in the pull request page. Click to open the details so you can quickly identify blockers, missing approvals, and get your pull request ready to merge.

Draft pull requests

When you create a pull request, you can choose to make it a draft pull request. Draft pull requests cannot be merged, and code owners are not automatically requested to review them. This is useful when you want to share work-in-progress without formally requesting reviews.

When you're ready to get feedback on your pull request, you can mark your draft pull request as ready for review. Marking a pull request as ready for review will request reviews from any code owners. You can convert a pull request to a draft at any time. See Changing the stage of a pull request.

Pull request refs and merge branches

When you open a pull request, GitHub creates up to two temporary, read-only Git references for it:

Ref Description
refs/pull/PULL_REQUEST_NUMBER/head Points to the latest commit on the pull request's head branch.
refs/pull/PULL_REQUEST_NUMBER/merge A merge branch—a simulated merge commit that represents what the repository would look like if the pull request were merged right now. This ref is only available when the pull request has no merge conflicts.

The merge branch automatically updates when the head branch changes. To fetch it locally:

git fetch origin refs/pull/PULL_REQUEST_NUMBER/merge
git checkout FETCH_HEAD

Replace PULL_REQUEST_NUMBER with the number of your pull request.

For information about how GitHub Actions uses the merge branch, see Events that trigger workflows.

Differences between commits on compare and pull request pages

The compare and pull request pages use different methods to calculate the diff for changed files:

  • Compare pages show the diff between the tip of the head ref and the current common ancestor (that is, the merge base) of the head and base ref.
  • Pull request pages show the diff between the tip of the head ref and the common ancestor of the head and base ref at the time when the pull request was created. As a result, the merge base used for the comparison might be different.

Further reading

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.

2 participants