halilmollaoglu

Hi,

I'm hitting what looks like the same underlying issue, but manifesting differently: instead of Add() silently failing to persist, calling any classic Devolutions.PowerShell cmdlet (e.g. Get-RDMSession) from inside a Custom (PowerShell) Synchronizer entry throws immediately:

System.IO.FileLoadException: Could not load file or assembly 'Client, Version=2026.3.0.0, Culture=neutral, PublicKeyToken=null'. Could not find or load a type. (0x80131522)

Repro:

1. RDM 2026.3.10 (Windows), Devolutions Server data source.

2. New Entry → Synchronizer → Custom (PowerShell).

3. Script body:

Import-Module Devolutions.PowerShell -ErrorAction Stop

Get-RDMSession -Name "<any existing entry name>" -ErrorAction Stop

4.Run now → the exception above is thrown immediately on Import-Module/Get-RDMSession.

This suggests the injected $RDM proxy context is loading its own copy of the Client assembly, and the classic Devolutions.PowerShell module's attempt to load its own copy of the same assembly (different load context/version) conflicts with it. As a result, inside a Custom PowerShell Synchronizer, only $RDM.Add(Name) is usable, none of the standard Get-RDMSession / Set-RDMSession / Remove-RDMSession cmdlets work, which makes it impossible to reliably update or clean up existing entries from within a synchronizer (only pure "create new" is possible).

Is this the same root cause as the ticket mentioned above, or a separate one? Happy to provide more logs/repro details if useful.