none
Preload Assembly RRS feed

  • Question

  • Hello,

    afaik every referenced assembly is loaded on demand (delayed load).
    I would like to preload all assemblies to avoid delays during runtime.
    I've checked Assembly.GetReferencedAssemblies(), but the method retuns only the currently loaded/required assemblies. If i use other libraries later, they will be loaded then.

    What i could do is browse the application directory for assemblies and laod those, but i am looking for a more generic way, preferly based on the meta informations of the executing/entry assembly.

    Any suggestions?
    Thursday, March 11, 2010 6:16 PM

Answers

  • corflags is native application, so you cannot "just" reference it.
    Good library - you could use CCI (http://ccimetadata.codeplex.com/) or you can write your own PE header decoder in managed. That shouldn't be that difficult.

    Re: Annoying and slow exceptions
    First in this context the slow part is reading the file, that is by far slower operation than throwing exception(s).
    Second, I would catch just second-chance exceptions in debugger and ignore first-chance. In other words you can safely ignore caught exceptions (unless your app does nasty stuff like catch-all and swallow, which it should avoid at the first place).

    -Karel
    • Marked as answer by Jaster Thursday, March 25, 2010 1:54 PM
    Thursday, March 18, 2010 11:01 PM
    Moderator

All replies

  • Thursday, March 11, 2010 6:51 PM
    Moderator
  • As i mentioned Assembly.GetReferencedAssemblies() does not return all the assemblies. I am using a component driven architecture, therefore some assemblies referenced in the startup project won't ever be used by that project itself. The compiler/fusion seem to remove that reference!
    To provide some more details: i use the unity framework and connect the used components via reference to a project that is used to launch the application.
    Friday, March 12, 2010 11:15 AM
  • If you're loading assemblies based on configuration values (which I'm assuming are fully qualified type names), how do you expect to know at runtime which assemblies are to be preloaded? Do you have a way of knowing which ones are to be loaded (for instance, are all the referenced assemblies placed on a "Components" directory)?

    If you have a way to know this, then I guess you could perform an Assembly.Load on each of them, or try to instantiate a type in each of those assemblies (this instantiation will then trigger the assembly loading). This types should obviously be "cheap" to load or have a lazy loading behavior.



    -- Blog: http://geeklyeverafter.blogspot.com/
    Friday, March 12, 2010 11:51 AM
  • As i mentioned Assembly.GetReferencedAssemblies() does not return all the assemblies.
    Argh, I totally overlooked that part of your original message. Sorry for that.

    -Karel
    Friday, March 12, 2010 4:50 PM
    Moderator
  • Well my idea was to use the references i set in visual studio, but those are removed after the app was compiled, cuz they are loaded delayed. So i guess it has to be done filewise.

    However i know the directory of all the assemblies, but it contains a huge load of dll files, just some of those are assemblies. Is there a way to decide if a file is an assembly or not without trying to load it as an assembly (i don't want exceptions here)?
    Wednesday, March 17, 2010 6:08 PM
  • You could walk all your assembly references and their references and references of references of references, etc. (walk the graph). That will give you all dependencies. Isn't that easier than to look at all assemblies in one directory?
    Note that there are circular references between these 5 assemblies: System.dll, System.Configuration.dll, System.Xml.dll, System.Data.SqlXml.dll and System.Security.dll.

    You are right that Visual Studio reference list is lost after compilation. It is indeed captured only in the transitive closure of all your referenced assemblies. However note that some references are not listed even in Visual Sutio - for example System.dll depends on System.Configuration.dll and System.Xml.dll while you can have just System.dll in your VS dependencies.

    Anyway, if you want to find out if a DLL is managed or not, trying to load it is the simpliest thing. Why don't you want exceptions here?
    Alternatively you can parse the PE file yourself, or use other library which will do that for you. Or you can run external command like corflags.exe which will give you the answer.

    -Karel
    Wednesday, March 17, 2010 7:59 PM
    Moderator
  • Well my Issue is about those lost references, not about the linked once.

    The point about exceptions is quite simple. I work usually with an enabled break for thrown clr exceptions, so i would have to it on and off every time i start the solution with a debugger.  Further any team will execute you, if your component starts with a hundred exceptions - also if they are handled ;)

    OK lets see where we end up so far: 
    - References are removed by VS, so i can't relay on those.
    - I have to work file-based here.
    - The "easiest" way to determinate weather a file is managed or not is to load it and catch the exception -> annoying and slow.
    - Additional Software is needed to detect manged Code.


    Is there a way to use corflags as a reference instead of starting processes?
    Do you actually know any "good" library - preferly .NET - to detect managed code without exceptions? 
    Thursday, March 18, 2010 3:54 PM
  • corflags is native application, so you cannot "just" reference it.
    Good library - you could use CCI (http://ccimetadata.codeplex.com/) or you can write your own PE header decoder in managed. That shouldn't be that difficult.

    Re: Annoying and slow exceptions
    First in this context the slow part is reading the file, that is by far slower operation than throwing exception(s).
    Second, I would catch just second-chance exceptions in debugger and ignore first-chance. In other words you can safely ignore caught exceptions (unless your app does nasty stuff like catch-all and swallow, which it should avoid at the first place).

    -Karel
    • Marked as answer by Jaster Thursday, March 25, 2010 1:54 PM
    Thursday, March 18, 2010 11:01 PM
    Moderator
  • First chance is an indicator for a failure in user code. I refuse to use exceptions for control flow purposes.

    CCI looks good, thanks.

    Thursday, March 25, 2010 1:53 PM