|
WSupported on Windows
|
|
|
|
assembly = new DotNetAssembly(name)
Arguments
assembly
The returned object (@DotNetAssembly) representing the assembly.
name
A required alphanumeric file path, filename, partial name, or display name for the assembly.
Discussion
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:
- The latest installed version of the CLR
- The workstation build flavor (wks)
- Single-domain loader optimization
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 global assembly cache (GAC)
- The location of dbr
- The dbl\bin directory
- The windows\system32 directory
|
Although the .NET assembly API allows search paths, this is not supported usage, and we recommend that you don’t use them. Search paths only work at runtime, and the gennet/gennet40 utility does not support them. |
|
|
If you are loading from the GAC and didn’t specify a display name, do not include the file 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:
- “File not found” ($ERR_FNF)
- “Protection violation” ($ERR_PROTEC)
- “Could not load assembly” ($ERR_NOLOAD)
Loading exceptions generated by .NET 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.
If CAS policy is not enabled in your version of .NET, an $ERR_FNF error will be generated in some cases when the assembly being loaded is located on a network share. You can work around this issue by adding the <loadFromRemoteSources> element to either the dbr.exe app.config or the machine.config file.
Examples
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")
