Open topic with navigation
WTSupported in traditional Synergy on Windows
assembly = new DotNetAssembly(name)
The returned object (@DotNetAssembly) representing the assembly.
A required alphanumeric file path, filename, partial name, or display name for the assembly.
The DotNetAssembly constructor loads a .NET assembly from a file path, filename, partial name, or display name. When this constructor is called, if the .NET CLR has not yet been loaded, it will be loaded using the following default settings:
Unless the MAXMEM environment variable is set to 50,000,000 or higher, the constructor uses a special mode of operation that reduces memory at the expense of more garbage collection. (The default 32‑bit CLR uses up to 64 MB of memory per process and the 64 bit CLR uses up to 128 MB of memory per process when this special mode is not being used.) If the CLR cannot be loaded for any reason, an $ERR_NODOTNET will occur.
Name can include an environment variable using the standard Synergy syntax (for example, MYVAR:) unless the .NET display name form is used. If neither an environment variable nor the .NET display name is used, name is searched for in the following locations, in order:
The .NET assembly API does not support search paths. If you specify an environment variable that is set to multiple directory paths, DotNetAssembly will only use the first one.
If you are loading from the GAC and didn’t specify a display name, do not include the filename extension in name. For example, system.windows.forms.dll is not valid; use system.windows.forms instead.
Name cannot be an xfServer remote file specification (for example, “file@server”).
If the assembly cannot be loaded, one of the following Synergy errors will be generated:
Loading exceptions generated by the .NET Framework are logged to the debug viewer if it is present.
The assembly is loaded using only the security evidence provided by the loader. If a security exception is thrown (for example, if you try to load an “unsafe” assembly from a mapped drive without the local client machine policy being set to specifically allow such access in the intranet zone), an $ERR_PROTEC error is generated.
Dependent assemblies are loaded automatically by the .NET assembly loader. If an assembly with the same name has already been loaded, the assembly that was loaded previously will be used. This may not be what you expect, and you should use the debug viewer to ensure that the DLLs load from the correct places.
If an attempt is made to load a duplicate assembly (with the same display name but a different file path), the DLL will not be found, and a “Could not load assembly” error ($ERR_NOLOAD) will be generated.
If you delete an assembly, all of the objects created from that assembly are deleted as well.
The example below loads a new assembly called mscorlib. See Sample programs for an example in the context of a complete program.
asm = new DotNetAssembly("mscorlib")