bug: IDE maintains lock on external DLLs
bug: IDE maintains lock on external DLLs
When adding references to attribute-types in external DLL files, the IDE maintains a lock on the referenced DLL. Unfortunately, this means you can't rebuild the external DLL without first quitting out of ED, or closing your model project and reopening after rebuilding...
Well, yeah, that is guaranteed by the fact that you can't update the assembly!Shalex wrote:This also guarantees that the information from the assembly is up-to-date.
You may be able to load the assembly without locking it:
Code: Select all
Assembly asm = Assembly.Load(File.ReadAllBytes("path\to\some.dll"));
Probably not a quick fix to integrate, but Microsoft does provide a library (MEF) that should be capable of loading/unloading assemblies dynamically.
Either way, you would need to watch the folder for changes and reload the referenced assembly as needed, so probably not trivial and perhaps not worth the effort...
Come to think of it, how does this work when using the VS add-in rather than the stand-alone application?
If the VS add-in locks DLLs you're currently building within the same solution, that must cause worse problems - I can quit ED and rebuild my DLL in VS, then restart ED, pretty quick; but if you have a solution with an ED model in it, that's not so easy?
Perhaps better than hacks or work-arounds to avoid this problem, would be to avoid the run-time dependency on third-party modules. This would also potentially mitigate other run-time problems - since, if the attributes you're working with at design-time are actually running code in external modules, those could throw exceptions or cause other problems.
What I would suggest, is to avoid constructing instances of attribute-types to begin with.
Instead, load the user-defined module, inspect the type-hierarchy and extract what you need, then unload again at once. After all, you don't have a dependency on any functionality provided by the loaded module - your only dependency is on meta-data contained in the module.
Using the Type Descriptor architecture, you could implement a metadata-provider that can "stand in" for an external type, using a Dictionary to store property-values.
For example, here's an implementation using type-descriptors to present key/value pairs from a dictionary on a PropertyGrid - essentially "fooling" PropertyGrid into thinking it's working with a different type, which is possible because PropertyGrid only depends on type meta-data and a place to store the values; it does not depend on functionality provided by the type itself.
Anyway - just thought I'd share the idea...
If the VS add-in locks DLLs you're currently building within the same solution, that must cause worse problems - I can quit ED and rebuild my DLL in VS, then restart ED, pretty quick; but if you have a solution with an ED model in it, that's not so easy?
Perhaps better than hacks or work-arounds to avoid this problem, would be to avoid the run-time dependency on third-party modules. This would also potentially mitigate other run-time problems - since, if the attributes you're working with at design-time are actually running code in external modules, those could throw exceptions or cause other problems.
What I would suggest, is to avoid constructing instances of attribute-types to begin with.
Instead, load the user-defined module, inspect the type-hierarchy and extract what you need, then unload again at once. After all, you don't have a dependency on any functionality provided by the loaded module - your only dependency is on meta-data contained in the module.
Using the Type Descriptor architecture, you could implement a metadata-provider that can "stand in" for an external type, using a Dictionary to store property-values.
For example, here's an implementation using type-descriptors to present key/value pairs from a dictionary on a PropertyGrid - essentially "fooling" PropertyGrid into thinking it's working with a different type, which is possible because PropertyGrid only depends on type meta-data and a place to store the values; it does not depend on functionality provided by the type itself.
Anyway - just thought I'd share the idea...
Just thought of a different solution. (just throwing ideas out there...)
This approach may be much simpler to implement.
Instead of loading the external module permanently at once, you can load the external module into a separate application domain when it's needed, and unload when you're done with it; so that it remains loaded only while you need it.
So for example, when someone brings up the attribute editor, load the module - and when the attribute editor is closed, serialize the attributes, and then unload the separate application domain.
So the pattern is: load module, unserialize (or construct) object, edit object (e.g. using PropertyGrid or dialog window etc.), serialize object, unload domain.
This way, you won't be locking the DLL (except while an editor is open/active) and blocking VS - and as an extra plus, anytime you do rebuild your DLL in VS, as soon as you edit the attribute in ED, it will reflect the current build of the module without having to close and re-open the model.
This approach may be much simpler to implement.
Instead of loading the external module permanently at once, you can load the external module into a separate application domain when it's needed, and unload when you're done with it; so that it remains loaded only while you need it.
So for example, when someone brings up the attribute editor, load the module - and when the attribute editor is closed, serialize the attributes, and then unload the separate application domain.
So the pattern is: load module, unserialize (or construct) object, edit object (e.g. using PropertyGrid or dialog window etc.), serialize object, unload domain.
This way, you won't be locking the DLL (except while an editor is open/active) and blocking VS - and as an extra plus, anytime you do rebuild your DLL in VS, as soon as you edit the attribute in ED, it will reflect the current build of the module without having to close and re-open the model.
We know about the possibility to unload assemblies from the main application domain by using separate application domain.
It cannot be implemented in an easy way because of the specificity of how Entity Developer works with attributes. However, we will investigate the possibility of implementing this approach and try to modify this Entity Developer behaviour.
It cannot be implemented in an easy way because of the specificity of how Entity Developer works with attributes. However, we will investigate the possibility of implementing this approach and try to modify this Entity Developer behaviour.
Re: bug: IDE maintains lock on external DLLs
The bug with locking on external DLLs, which are loaded for obtaining a list of attribute types, is fixed. We will post here when the corresponding build of Entity Developer is available for download.
Re: bug: IDE maintains lock on external DLLs
New build of Entity Developer 4.5.240 is available for download!
It can be downloaded from http://www.devart.com/entitydeveloper/download.html (trial version) or from Registered Users' Area (for users with active subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?f=32&t=24677 .
It can be downloaded from http://www.devart.com/entitydeveloper/download.html (trial version) or from Registered Users' Area (for users with active subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?f=32&t=24677 .