locked
Interop and reflection problem

    Question

  • I have a dll (TaxEngine) that starts another dll (TaxCatalog) that determines which TaxCatalogYY (a different dll for each year) to instantiate and return a reference to the TaxEngine. I was holding hard references to the different TaxCatalogYYs (TaxCatalog10.dll, TaxCatalog11.dll etc).

    For reasons to extensive to go into here, I wanted to remove the hard references and have the TaxCatalog.dll "discover" at run time which yearly catalogs are available. I was able to accomplish this with the following code: (abbreviated)

    Dim ssb As System.Reflection.Assembly

    ssb = System.Reflection.Assembly.LoadFrom(p)

    Dim t As Type = ssb.GetType(Sname)

    Dim o As Object = Activator.CreateInstance(t)

    mCatalog = DirectCast(o, ITaxObjSelecter)

    All of the dll’s are .Net assemblies and the TaxEngine also exposes itself as a COM object.  Everything works just fine when the TaxEngine is started by a .Net exe, but when it is started by a .exe built in VB6 through its COM interface, it fails.

    In both cases, the assembly is loaded correctly, but when I try to get the type, t is still “Nothing” after the GetType statement is executed.

    This seems like a bug to me.  Anybody know a workaround?

    Thanks in advance.


    Terry

    Sunday, November 18, 2012 3:00 PM

Answers

All replies

  • Hello Terry,

    Not sure if you've followed this:http://support.microsoft.com/kb/817248?wa=wsignin1.0. and the gettype returns nothing you may need to ensure ssb is not nothing.

    I'm not in VB6, sorry for any misunderstood. BTW, Vb6 forum may help you also: http://social.msdn.microsoft.com/Forums/en-US/vblanguage/thread/aa350a38-3bb9-4919-9cc1-afaf7fed52f5.


    Think again!

    Tuesday, November 20, 2012 3:14 AM
  • Thanks for your reply. 

    ssb is not nothing and looks exactly the same in both cases.  So we have a .Net assembly calling a .Net assembly which loads a .Net assembly and the only difference is that the first assembly when called through its COM interface fails, but if called as a .Net assembly (from a .Net assembly) works.  This has to be a bug.


    Terry

    Tuesday, November 20, 2012 3:12 PM
  • Thanks for your reply. 

    ssb is not nothing and looks exactly the same in both cases.  So we have a .Net assembly calling a .Net assembly which loads a .Net assembly and the only difference is that the first assembly when called through its COM interface fails, but if called as a .Net assembly (from a .Net assembly) works.  This has to be a bug.


    Terry

    Then you may want to submit it to http://connect.microsoft.com/VisualStudio.

    Think again!

    Wednesday, November 21, 2012 2:11 AM
  • I am still waiting for my "priority support" from an MS engineer.

    Terry

    Thursday, November 29, 2012 12:43 PM
  • I am still waiting for my "priority support" from an MS engineer.

    Terry

    Hi Terry,

    Thanks for your reply. I'm trying to involving some senior engineers into this thread now.

    Best regards,


    Shanks Zen
    MSDN Community Support | Feedback to us


    Thursday, November 29, 2012 2:27 PM
    Moderator
  • Still wainting for some support ...

    Terry

    Wednesday, December 05, 2012 1:47 PM
  • Hi Terry,

    Per my experience, this should be caused because the dependencies of the assembly were not be loaded.

    When you use LoadFrom, you have to load the dependencies by yourself if the following conditions cannot be met:

    • Dependencies already loaded in this context will automatically be found.
    • Dependencies in the same dir as the requesting LoadFrom context assembly will automatically be found.

    FYI:http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx

    To understand that, you need first understand what is "load contexts". Type.GetType is in "defualt load context". The assembly you loaded in memory is in "load-form context". FYI: http://msdn.microsoft.com/en-us/library/dd153782.aspx

    Please read the following link also: Try resolve it by using AssemblyResolve event

    http://msdn.microsoft.com/en-us/library/1009fa28.aspx

    http://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve.aspx

    Hope the above info can help you.

    Thanks,


    Alan Yao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.



    Thursday, December 13, 2012 10:12 AM
    Moderator
  • Thanks - I got it.  The problem was a version conflict between the tlb that the VB6 exe was referencing and the .Net assembly dll.  That is the .Net assembly being loaded had a reference to a .Net assembly containg all the interface definitions and the exe had a reference to the tlb for that dll and they were at different version.

    Thanks again.


    Terry

    Thursday, December 13, 2012 5:24 PM
  • Hi Terry,

    Glad to know the info I provided helped you on this issue. And thanks for your sharing the exact problem here. That will be helpful for others who has the similar issue.

    Have a nice day. :)

    Regards,


    Alan Yao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, December 14, 2012 1:24 AM
    Moderator