FIX: Connect to existing student version

[Samuelopez-ansys]

Description

Student version was connecting to existing session.

Platform: windows, linux

Issue linked

Close #7891
Close #7884

Checklist

• I have tested my changes locally.
• I have added necessary documentation or updated existing documentation.
• I have followed the coding style guidelines of this project.
• I have added appropriate tests (unit, integration, system).
• I have reviewed my changes before submitting this pull request.
• I have linked the issue(s) that are solved by the PR if any.
• I have assigned this PR to myself.
• I have added the minimum version decorator to any new backend method implemented.
• I have agreed with the Contributor License Agreement (CLA).

[tzhou-yyds]

Verified on Windows 11, AEDT 2026 R1, this PR branch (1.3.dev0):

✅ Attach to existing session works — started ansysedt.exe -grpcsrv 50700 -ng manually, then Desktop(version="2026.1", port=50700, new_desktop=False, non_graphical=True) connects to the same process (verified odesktop.GetProcessID() == manual instance PID, ruling out a silent new instance). release_desktop(close_projects=False, close_on_exit=False) leaves the instance alive as expected. This resolves our #7884 local-attach scenario.

⚠️ Two observations from the same test bench:

1. With the legacy workaround env var PYAEDT_USE_PRE_GRPC_ARGS=True set, the same attach silently launches a new instance instead (PID mismatch, no error raised). Users who adopted that workaround for Attaching to a remote gRPC session validates the port on localhost: _validate_port() called without machine #7884 will hit silent failures after upgrading — a code warning or docs note might be worth it.
2. After an abnormally interrupted session, re-attaching to the same port can also silently spawn a new instance until stale processes exit.

Remote-machine attach (the original #7884 remote case) was not tested — no routable gRPC path between our two machines.

[Samuelopez-ansys]

Hi @tzhou-yyds , thanks for the feedback, I applied a small fix that could impact the issue you mentioned, I tested 2026R1:

app_1 = Hfss(version="2026.1", port=50700, new_desktop=False, non_graphical=True, machine="127.0.0.1")

With an open AEDT in non graphical mode with the env. variable PYAEDT_USE_PRE_GRPC_ARGS, and it not open a new AEDT instance.

[tzhou-yyds]

Re-tested with the latest fix/issue_7891 (41658c8) on 2026R1, Windows 11 — the small fix works:

• Case B (PYAEDT_USE_PRE_GRPC_ARGS=True + Desktop(version='2026.1', port=50700, new_desktop=False, non_graphical=True)): attaches to the manually launched ansysedt -grpcsrv 50700 -ng instance, GetProcessID() matches the manual PID — no new instance spawned (previously this env var caused a silent new instance).
• Case C (your exact form: Hfss(version='2026.1', port=50700, new_desktop=False, non_graphical=True, machine='127.0.0.1') with the env var set): attach OK, PID matches as well.
• release_desktop(close_projects=False, close_desktop=False) leaves the manual instance alive as expected in both cases.

Thanks for the quick turnaround!

[SMoraisAnsys]

Overall LGTM but there is something bothering me with "Step 6". Otherwise, I left minor comments.

[Samuelopez-ansys]

Hi @SMoraisAnsys , I applied your suggestions, please could you review it again?

I reverted the self.__port set instead of using the property setter, but I also modified it in other places of desktop.py to make it consistent, please take a look. I do not understand why this is better than using the property setter, in my opinion in was more clean, but I also understand that if the property setter changes, it could be dangerous, and actually it opens the door to the question if the self.port property should have a setter, or not, because it is a very sensitive variable.

performed suggestions, and Unified self.__port set