How to free/Unblock .NET DLLs

Comments

• angelo_melo

  4:04PM

  Some context:
  
  I am trying to prevent DLL locking issues.
  
  We currently have a multi-developer environment in which developers compile .NET code and place the resulting DLLs and dependencies in a shared location. The BASIC+ code that loads and executes the .NET assemblies then copies the contents of that shared location into a temporary folder and loads the DLLs from there.
  
  This lets us deploy updated DLLs to the shared location without encountering file-locking issues.
  
  The tedious part is that, each time we want to run a new version of the DLLs, we must modify the BASIC+ code to use a new temporary folder. The updated DLLs are then copied into that folder and loaded from there.
  
  This lets us immediately load and run newly compiled DLLs, but the approach has two drawbacks:
  
  1. OpenInsight continues to hold references to DLLs loaded from previous temporary folders and versions.
  2. We must manually create, track, and clean up the temporary folders.
• KevinFournier

  5:02PM

  I'm not aware of a way to force OI to release it's lock on a DLL beyond shutting OI down. You can try posting in the Revelation forums and seeing if Bryan knows of an undocumented way to do this.
• BarryStevens

  8:16PM

  CLAUDE says this:
  
  In OpenInsight, "DLL locking" issues usually show up in two different flavors — worth covering both since the fix differs:
  
  **1. Windows file-locking on externally called DLLs (CALLDLL/LOADDLL)**
  
  When Basic+ code calls `CALLDLL` (or the older `LOADDLL`/`CALLDLL`/`FREEDLL` triad), OpenInsight loads that DLL into its process space and, by default, keeps it loaded for the rest of the session — even after the call returns. That's what causes the classic dev-cycle pain: you rebuild the DLL, try to copy the new version over the old one, and Windows won't let you because OI still has a handle open on it.
  
  To prevent this:
  - **Explicitly call `FREEDLL`** after you're done with the DLL, rather than relying on OI to release it when the session ends. This drops the lock immediately.
  - **During active development**, don't load the DLL from the same path you're rebuilding into. Load a versioned/timestamped copy (e.g., `mydll_v2.dll`) or work from a separate dev folder, then swap the "live" copy only when OI isn't holding a handle.
  - **Restart the OI Engine/IDE process** between rebuilds if you must load from the same path — this is the blunt but reliable option for solo/small-scale dev work.
  - If the DLL is shared across multiple OI sessions on a server, consider wrapping it as an **out-of-process COM server (EXE) instead of an in-process DLL** — trades a bit of call-speed for isolation, since each session talks to its own process rather than all locking one shared file.
  
  **2. COM object reference locking (relevant to your NEWCOM/Graph API work)**
  
  If you're using `NEWCOM` to create COM objects (like `Msxml2.ServerXMLHTTP.6.0`), the underlying DLL stays locked as long as any live object reference exists. This bites people because Basic+ garbage collection isn't always obvious about *when* it releases the reference.
  
  To prevent it:
  - **Explicitly null out the object variable** when done: `oXMLHTTP = ""` (or the equivalent destroy call) rather than letting it fall out of scope implicitly.
  - **Avoid holding COM object handles in global/common variables** across multiple calls unless you genuinely need persistence — that's the most common cause of a DLL staying locked far longer than expected.
  - If you're doing this inside a loop (e.g., calling the Graph API repeatedly), create and release the object **each iteration** rather than reusing one instance indefinitely, unless you've confirmed reuse is safe.
  
  Quick check — when you say DLL locking, are you running into it during **development** (can't rebuild/redeploy a DLL you're actively working on), or in **production** (a live DLL getting stuck locked during normal operation)? That'll tell me which of these to dig into further.