Done Load .NET plugin as raw binary data

[Joe Caverly]

When developing a .NET plugin,
even though I use Plugin /u
the plugin .dll is locked,
and can only be removed from disk by exiting TCC.

This is normal .NET behaviour.

When loading a .NET Framework .dll that I created,
if I use

pshell /s "[System.Reflection.Assembly]::LoadFrom('U:\jlcutils.dll')"

jlcutils.dll can only be removed from disk by exiting TCC.

U:\>pshell /s "[System.Reflection.Assembly]::LoadFrom('u:\jlcutils.dll')"
GAC    Version        Location                                                                               
---    -------        --------                                                                               
False  v4.0.30319     u:\jlcutils.dll                                                                        

U:\>del jlcutils.dll
Deleting U:\jlcutils.dll
TCC: (Sys) The requested lookup key was not found in any active activation context.
 "U:\jlcutils.dll"
     0 files deleted       1 failed

Exit TCC to remove lock on jlcutils.dll


When loading a .NET Framework .dll that I created,
if I use

pshell /s "$bytes = [System.IO.File]::ReadAllBytes('u:\jlcutils.dll')"

This reads the DLL as a byte array:
ReadAllBytes() opens the file
Reads the entire DLL into memory
Closes the file immediately
Leaves me with a variable $bytes containing the raw binary data

Result: PowerShell never loads the DLL from disk directly,
so the file is not locked and can be overwritten or recompiled while the session is running.

pshell /s "[System.Reflection.Assembly]::Load($bytes)"

This loads the DLL from the in‑memory byte array, not from a file path.

The assembly is loaded into the current AppDomain
It is not associated with a file on disk
I can reload a new version by repeating the process
No type conflicts from stale assemblies on disk
No file locking

jlcutils.dll can easily be removed from disk without exiting TCC.

E:\Utils>pshell /s "$bytes = [System.IO.File]::ReadAllBytes('u:\jlcutils.dll')"

E:\Utils>pshell /s "[System.Reflection.Assembly]::Load($bytes)"
GAC    Version        Location                                                                               
---    -------        --------                                                                               
False  v4.0.30319                                                                                            

E:\Utils>del jlcutils.dll
Deleting E:\Utils\jlcutils.dll
     1 file deleted

This makes developing a .NET .dll much easier.

Would it be possible to apply this to .NET plugin development?

That is, after plugin /u mynet has been issued,
there will be no lock on the mynet.dll file,
making it easier to develop a .NET .dll plugin.

Joe

 

[rconn]

Wasn't quite as simple as just doing Assembly::Load(byte[]).

I had to move the managed statics to the GC heap, and create a new resolver ref class, but it's working and now allows you to unload a .NET plugin and TCC will no longer have a file lock on the dll.

It will be in the next update.