Results 1 to 6 of 6

Thread: Referencing A Remote Assembly (Codebase? AssemblyBinding? ???)

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    Jan 2008
    Location
    Tennessee
    Posts
    130

    Referencing A Remote Assembly (Codebase? AssemblyBinding? ???)

    Currently I have a need to reference a class library dll that is not located in the same directory as the exe nor its subdirectories. Can anyone point me in the right direction on this? Are there any good articles or tutorials on it? I have been looking through my .Net books and some go into details in a different direction and none that I have seem to cover it. To be honest, if there’s a nice tutorial or article on this topic with sample code to look at, that would be ideal at this point in my project (I’m literally presenting on it twice tomorrow).

    I have to admit that I’m fairly ignorant of this topic, but it’s my understanding that I should be able to accomplish this using the assemblyBinding elements in the application configuration. If I do use a codebase approach with the app config, am I suppose to do something in the exe code to read the config and load? The class library that I’m refrencing… am I supposed to have any special methods or classes in it to make this work? I think I have more questions than answers.

    If you want more of the nitty-gritty details on the current scenario, here it is:

    I have an executable I’ve developed (we’ll call this myApp.exe). I also have a centralized data-accessing class library (we’ll call this appData.dll). This exe actually utilizes a framework I’ve designed to run from within a third-party company’s application. To ensure the myApp.exe is more maintainable and accessible, it will be located separately from the framework.dll and the appData.dll. The framework.dll will most likely reside in the same directory as the third-party exe, but separate from the appData.dll and myApp.exe. So I was considering applying the assemblyBinding elements in the application configuration files for the myApp.exe pointing toward the framework.dll and the appData.dll while that for the framework.dll will be pointing toward the appData.dll (this is why the data access library file is central between the two). My problem is that I don’t have a clue as to how this should work or be accomplished. Any help would be much appreciated.

  2. #2
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Referencing A Remote Assembly (Codebase? AssemblyBinding? ???)

    It sounds like the dlls are all written in .NET, is that right? If they are managed assemblies, the answer is somewhat different from what it would be if they are not.
    My usual boring signature: Nothing

  3. #3

    Thread Starter
    Addicted Member
    Join Date
    Jan 2008
    Location
    Tennessee
    Posts
    130

    Re: Referencing A Remote Assembly (Codebase? AssemblyBinding? ???)

    Yes, they are .net assemblies. The framework.dll does reference a mix-managed api so that it can interact with the third-party application.

  4. #4
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Referencing A Remote Assembly (Codebase? AssemblyBinding? ???)

    Then let me offer you up an example from some code I have. It may not be quite relevant, but may also be useful:

    Code:
     If IO.Directory.Exists("your directory here") Then
                For Each fl As String In IO.Directory.GetFiles("your directory here", "*.dll")
                    Try
                        Dim aDLL As System.Reflection.Assembly = System.Reflection.Assembly.LoadFile(fl)
    
                        If aDLL IsNot Nothing Then
                            Dim tArr As Type() = aDLL.GetExportedTypes
    
                            For Each t As Type In tArr
                                If t.GetInterface("HISInCommon.IHISGeneral") IsNot Nothing Then
    This code is used to peruse all the dlls in a certain directory, and find any object in any of those dlls that implements a certain interface (noted in the last line). What you are doing is somewhat easier than this, in that you know not just the directory where the dll is located, but exactly which dll to look at. Therefore, you don't have to look through all dlls in the directory, but can focus on just the right one.

    These lines:
    Code:
     Dim aDLL As System.Reflection.Assembly = System.Reflection.Assembly.LoadFile(fl)
    
                        If aDLL IsNot Nothing Then
                            Dim tArr As Type() = aDLL.GetExportedTypes
    give you some idea of what you can do with that dll using reflection, though there is much more. What I am doing is loading all of the types exported from the dll (everything that is public), and wandering through each of those. In your case, you probably know the exact type you need. However, at that point it gets a bit trickier for you.

    In my case, all parts of the project reference the same dll where I have a series of interfaces defined. Therefore, both the main project and the dlls reference that same common dll, and so both the main project and the dlls know about the same types. This allows me to talk about a specific interface. The main app doesn't know about the types declared in the dll, but it does know about that specific interface. Since any object that implements an interface can be instantiated and used via that interface, the main app doesn't need to know which type it is actually dealing with, it only needs to know about the interface it implements. This is one alternative you might consider.

    I believe that the alternative is probably to use Late Binding for all objects in the remote dll. The reason is that the main app won't know about the types defined in the remote dll, but so what. If you use Late Binding, then all of those types will be used in the main application as type Object. The drawback to this approach is that you lose all intellisense help for those objects, and you have to turn Option Strict OFF on all code pages that use any of this Late Binding code. It would work, because the types actually ARE in the dll, and when the code gets into execution, when it tries to find method M, it will really be there. However, during design time, the compiler won't know about method M, because it won't even know about the type that contains method M, so with Late Binding, you are effectively telling the compiler, "trust me, M will be there when it is needed."

    So those are a couple approaches that are possible.
    My usual boring signature: Nothing

  5. #5

    Thread Starter
    Addicted Member
    Join Date
    Jan 2008
    Location
    Tennessee
    Posts
    130

    Re: Referencing A Remote Assembly (Codebase? AssemblyBinding? ???)

    Okay... now that I'm through fighting fires for the day, I finally got a chance to look online. I like what you say about the interface, but I'm afraid I may be too far along for that now without redoing quite a bit of work. I did find this article: http://support.microsoft.com/kb/837908 and was curious what your thoughts are on the Method 2 approach?

  6. #6
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Referencing A Remote Assembly (Codebase? AssemblyBinding? ???)

    At a glance, I would say that you should give it a try, as it looks like a viable solution and so easy to try that even if it doesn't work out it won't have cost you much.

    The one concern I would have would be that this appears likely to work best if you can say that the dll will be at location X, and that it will remain at location X. That sounds like what you are doing, so that may not be a concern at all. After all, you are talking about a file located on a server, not one that is located at 'wherever somebody chose to put it'. So, you are doing what I would expect to work well for this approach.
    My usual boring signature: Nothing

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width