Late binding / reflection in C#

[Overridden Member]

Hi folks,

( I'm using .NET 2.0 )

I had following early binding code that worked. However, because I have no control on the version of the com object used, I have to use late binding. Correct?

Application.Engine myEngine = new Application.Engine();

myEngine.Order.Initialize();
myEngine.Order.Order_ID = 123;

OrderLineArray l_OrderLineArray = myEngine.Order.GetOrders();

foreach ( OrderLine ol in OrderLineArray )
{
	....
}

Now, when using late binding, I have 2 problems.

I can use

System.Type oType = System.Type.GetTypeFromProgID( "Application.Engine" ); 
m_AppTest =  System.Activator.CreateInstance (  oType );

but then I have to invoke .Order.Initialize() ( instead of .Initialize() ). How do I specify this?

Second,

I have to get an array from .Order.GetOrders(). The InvokeMember function only returns an object? How does one implement that?

Thanks!

[JonnyPoet]

Now, when using late binding, I have 2 problems....
I have to get an array from .Order.GetOrders(). The InvokeMember function only returns an object? How does one implement that?

IMHO you need to cast your myTest object to Application.Engine and then it should work as long as the different versions are compatible to your code in that point. I would suggest to use try-catch for the whole action.

[MadHatter]

this may help explain how to do it. http://sanity-free.org/135/dotnet_reflection.html

you have to get the PropertyInfo object from the type named Orders, then you have to get a MethodInfo from whatever Orders type is, and call Invoke passing in the instance of Orders, then cast the results to an array or however you're gonna use it.

[Overridden Member]

I tried that stuff that MadHatter suggested but when I run the line of code :

Assembly assemblyInstance = Assembly.LoadFile(@"C:\WINDOWS\system32\ApplicationEngine.dll");

I get an error it cannot load assebly manifest and that it has to be a managed asembly which ApplicationEngine.dll is not. It's a VB6.0 dll.

Any more ideas?

[nelo]

Sorry to take you back a bit. But I have a question about what you said earlier.

I had following early binding code that worked. However, because I have no control on the version of the com object used, I have to use late binding. Correct?

You don't have control of the specific version of the COM object. But if the people who have developed the com object should know that once an interface is developed and released it should never be changed. In other words if in the first release they had method called "GetOrders" and later on they decide that they want orders for a particular date "GetOrders(DateTime date)" they would have to preserve the original GetOrders. I'm not sure how much you know about COM but one of the key things it introduced was the ability to completely separate an interface from its implementation. So if I gave you a COM component and I told that there is an interface called IOrder you could write code against. If I later found a bug in my implementation and decided to release a new version of the COM component your code would be completely unaffected. The COM model relies on the system registry to maintain information about the version and the location of the COM component which meant that you could only ever have one version of the same COM component on the machine. In the example I gave you earlier provided that I did not change the methods or parameters defined in the IOrder interface I could release several versions of the COM component without affecting your code even with early binding. What matters is the interface. If i decided that i needed to enhance the component where its interface is concerned I would add a new interface IOrderEx and add any new methods there and release a new version. Again your code would remain unaffected.

Going back to your original problem, if you're consuming the object that people supplying it should be able to tell you something about the version. I would assume that there certain features that you need that would be there regardless of the version. If possible I would code against the interface and not against the class. If you look at the object browser and look at your vb6 dll it should tell you the classes and interfaces it defines. The interfaces should not change. If you see an interface that has the method that you want use that interface. That way your code should not have any side effects because of different versions. I realise I've said a lot. I hope I've made sense. Let me know If there's anything i need to clarify.

[Overridden Member]

I really appreciate your input. Perhaps I worry a bit too much here...

So...I'm confident that the interface is exactly the same across versions of the DLL. So, if I add a reference in my project to DLL version 2.0, code against that, compile and take the assembly to another machine with DLL version 1.0, it would run just fine and use the 1.0 DLL?

It's hard to believe life would be that simple... :-)

[nelo]

Yes provided that interface is the same. You would have to ensure that the version 1.0 offers the minimum functionality expected. It could be part of the minimum requirements for your software to work. In your case I would develop against version 1.0. Only you can tell what the differences are. But that would be a safer bet.

It's hard to believe life would be that simple... :-)

It is supposed to be that simple that's why COM was introduced. And now with the .NET framework you can have multiple versions of a re-usable component on the same machine.

The reason why things aren't always simple in relation to COM is that people sometimes break the rules. If a feature is available in version 1.0 it should remain available in subsequent versions. If the feature is deemed redundant or detrimental then that should be made clear to all clients involved and they should all upgrade. Normally though you keep the feature there. Any new code developed would look to use the latest version any way.