Hi,

According to this thread (https://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=22694&HighLight=1) it has been a problem with a known but not prioritized solution.

Loading typeimports causes the llblgen designer to keep the assembly locked, preventing VS to build.

Is there any workaround for this? I've decided to copy my dll with a post-build step to the folder containing the .typeimports file - then only the copy step fails, but I can build. However, it would be great if there was a better solution.

BR, Jan

Edit: LLBLGen version 5.6.1 VS 2019

The solution in that thread is indeed not implemented yet, we do need to use the types of the assembly at runtime so we can't do much else than load the assembly, which locks the assembly.

That said, there's another solution I think, which is that we shadowcopy the assembly. We'll fasttrack that for 5.7.

Thinking about it: the only thing we can do is preventing a build being blocked because a dll is in use. We can't hot-reload the new dll once it's been built again: in Netfx you can't hot reload a dll.

You can't "reload" when the user selects "Re-scan for TypeConverters and .typeimports Files"? I would think that the menu-item did something similar anyway, due to the naming (re-scan).

Then again, it probably just looks for additional things to load, not for updated versions, as the .dlls already loaded are not overwritten, as they are locked.

I considered an alternative approach, where my post-build step calls a powershell/bat file that tries to copy the dll, but silently ignores a copy error. That would remove the error message in VS, but it's ugly, and I actually don't know how well my build server setup (TeamCity) would handle it. However, it inspired me to suggest that maybe you could do something similar: Read the .typeimports and what else, and copy the relevant dlls to LLBLGens own cache folder. Maybe you could handle unload/reload-issues "internally" that way?

Btw: I changed the dll I wanted to load enumeration types from, and experienced that llblgen kept keeping the old one locked, even after updating the typeimports file and restarting the llblgen designer. Not sure if it caches dlls to load. So - more or less - the steps to reproduce:

• in typeimports, specify typeA, from A.dll
• copy A.dll to same folder
• point llblgen to the typeimports folder
• use typeA
• change your mind
• re-create the same type as typeB in a new project
• edit typeimports, specify typeB, from B.dll
• copy B.dll to the folder (next to A.dll)
• try to delete A.dll - it was locked
• re-scan, change to the new type from B.dll in the designer
• try to delete A.dll - it was still locked
• restart the llblgen designer
• verify only the new typeB is used (simple job, only used 1 place)
• try to delete A.dll - it was still locked
• shut down the llblgen designer
• try to delete A.dll - this time it worked

JanRHansen wrote:

You can't "reload" when the user selects "Re-scan for TypeConverters and .typeimports Files"? I would think that the menu-item did something similar anyway, due to the naming (re-scan).

You can't unload an assembly from an appdomain in netfx, only on netcore, so it can't replace types. It looks for new assemblies it hasn't seen before.

Then again, it probably just looks for additional things to load, not for updated versions, as the .dlls already loaded are not overwritten, as they are locked.

I considered an alternative approach, where my post-build step calls a powershell/bat file that tries to copy the dll, but silently ignores a copy error. That would remove the error message in VS, but it's ugly, and I actually don't know how well my build server setup (TeamCity) would handle it. However, it inspired me to suggest that maybe you could do something similar: Read the .typeimports and what else, and copy the relevant dlls to LLBLGens own cache folder. Maybe you could handle unload/reload-issues "internally" that way?

Yes that's what shadowcopy does and what e.g. unit testing frameworks use too: they copy everything to a temp folder and run things from there.

Btw: I changed the dll I wanted to load enumeration types from, and experienced that llblgen kept keeping the old one locked, even after updating the typeimports file and restarting the llblgen designer. Not sure if it caches dlls to load. So - more or less - the steps to reproduce:

• in typeimports, specify typeA, from A.dll
• copy A.dll to same folder
• point llblgen to the typeimports folder
• use typeA
• change your mind
• re-create the same type as typeB in a new project
• edit typeimports, specify typeB, from B.dll
• copy B.dll to the folder (next to A.dll)
• try to delete A.dll - it was locked
• re-scan, change to the new type from B.dll in the designer
• try to delete A.dll - it was still locked
• restart the llblgen designer
• verify only the new typeB is used (simple job, only used 1 place)
• try to delete A.dll - it was still locked
• shut down the llblgen designer
• try to delete A.dll - this time it worked

Once it has loaded a type from a dll, the assembly is 'loaded' by .net and thus locked on disk. This is sadly only 'solved' when we copy the dlls to a temp folder and load from there. This might have side effects so we can't quick fix this in the current build.