CoreDotNetAccessControl rejects DotNetFacade name-value argument on Windows

[schmalto]

Description

Description

shareMATLABSession can fail on Windows while initializing the MATLAB MCP Server
existing-session setup. The Windows ACL factory calls:

CoreDotNetAccessControl(DotNetFacade=options.DotNetFacade)

but CoreDotNetAccessControl declares its constructor arguments using
options.?CoreDotNetAccessControl. Because the class does not expose matching
public settable properties, MATLAB rejects the DotNetFacade name-value input.

Observed error:

Warning: shareMATLABSession failed: Invalid default value for property
'PermissionManager' in class 'mcpserver.internal.fs.DefaultFSAdaptor':
Invalid default value for property 'WindowsACLManager' in class
'mcpserver.internal.fs.internal.permissionmanager.WindowsPermissionManager':
Invalid default value for property 'DotNetAccessControl' in class
'mcpserver.internal.fs.internal.permissionmanager.internal.windowsacl.DefaultWindowsACLManager':
Invalid argument list. Function 'CoreDotNetAccessControl constructor' does not
accept input arguments because class
'mcpserver.internal.fs.internal.permissionmanager.internal.windowsacl.internal.dotnet.CoreDotNetAccessControl'
referenced in the arguments block does not have public settable properties.

This blocks existing-session MCP workflows where MATLAB must be launched by an
external/vendor process before the MCP server attaches.

Environment where observed:

• Windows 11 Pro
• MATLAB R2023b Update 11, 23.2.0.3097123
• MATLAB MCP Server v0.11.2
• MCP server mode: --matlab-session-mode=existing

Expected behavior: shareMATLABSession should create the session details file
and allow matlab-mcp-server.exe --matlab-session-mode=existing to attach.

Actual behavior: shareMATLABSession fails during default Windows ACL permission
manager construction.

Suggested Fix

Update CoreDotNetAccessControl so its constructor explicitly accepts the
DotNetFacade name-value argument already passed by createDotNetAccessControl.
This preserves dependency injection and is preferable to changing the factory to
call CoreDotNetAccessControl() with no arguments.

diff --git a/matlab/matlab_mcp_toolbox/mcp/+mcpserver/+internal/+fs/+internal/+permissionmanager/+internal/+windowsacl/+internal/+dotnet/CoreDotNetAccessControl.m b/matlab/matlab_mcp_toolbox/mcp/+mcpserver/+internal/+fs/+internal/+permissionmanager/+internal/+windowsacl/+internal/+dotnet/CoreDotNetAccessControl.m
@@ -21,12 +21,11 @@ classdef CoreDotNetAccessControl < handle & mcpserver.internal.fs.internal.permi
     methods
         function obj = CoreDotNetAccessControl(options)
             arguments
-                options.?mcpserver.internal.fs.internal.permissionmanager.internal.windowsacl.internal.dotnet.CoreDotNetAccessControl
+                options.DotNetFacade(1, 1) mcpserver.internal.facade.dotnet.DotNetFacade = ...
+                    mcpserver.internal.facade.dotnet.DefaultDotNetFacade()
             end
 
-            for prop = string(fieldnames(options).')
-                obj.(prop) = options.(prop);
-            end
+            obj.DotNetFacade = options.DotNetFacade;
         end
     end
 end

[ybenouag]

Hi @schmalto,

Thanks for the report and diagnosis. We reproduced it on Windows with R2023b and your analysis is correct.

Workaround until we ship a fix: in a fresh MATLAB session, before running shareMATLABSession() or using any .NET, switch to the .NET Framework runtime:

dotnetenv("framework");

Then run shareMATLABSession() and attach as usual. This path avoids the affected constructor and is always available on Windows.

We will update this issue when the fix is ready. Thanks again!