.typeimports file locks my assembly

Posts   
 
    
fpdave100
User
Posts: 97
Joined: 06-Feb-2012
# Posted on: 06-May-2014 18:32:31   

Hi

if I use a .typeimports file to import an enum, then it locks my assembly so that I can't build my VS project unless I close LLBLGEN.

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 06-May-2014 22:10:56   

Which version of LLBLGen Pro are you using? Which Designer's release date? (hint: always try the latest build).

To which .NET version have you built the enum dll?

fpdave100
User
Posts: 97
Joined: 06-Feb-2012
# Posted on: 07-May-2014 09:36:30   

LLBLGEN Pro: 4.1 Final .NET 4.0

the enum lives in the same assembly/project/dll as the EF POCO entity classes

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 07-May-2014 09:51:58   

This is unavoidable unfortunately in v4.1. The designer works with real type objects and therefore has to load the type in the appdomain. The consequence of this is that the assembly the types come from is locked by fusion (the CLR assembly loader).

We'll investigate whether we can create a shadowcopy of the assembly to load the types from there and will try to include this in v4.2.

Frans Bouma | Lead developer LLBLGen Pro
fpdave100
User
Posts: 97
Joined: 06-Feb-2012
# Posted on: 07-May-2014 10:20:26   

or try loading in a separate appdomain, which can be unloaded when it is finished with

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 07-May-2014 11:34:08   

fpdave100 wrote:

or try loading in a separate appdomain, which can be unloaded when it is finished with

But then the type can't be used in the appdomain of the designer: for reflection based purposes that indeed would solve it, but the type object itself is used in the object model in v4.x, so the assembly itself is loaded into the appdomain. I now realize that fixing with shadowcopy won't work: reloading it won't work, as unloading the older version won't work. disappointed

The only thing that would solve it is that the designer uses strings as type names, not type objects. We then could load the assembly in another appdomain, inspect the types there, and unload it after marshalling back the type strings to the current appdomain. This is planned in a future update, but not in v4.x

Frans Bouma | Lead developer LLBLGen Pro