I believe what Jed meant was that the .NET framework allows you to call into unmanaged code ( code that does not use the .NET framework). This is done by making use of .NET
interop services.
Since there already exists a huge codebase that cannot all be re-written using .NET, Microsoft provides a way to be able to use that preexisting code and use it within a managed framework. If you need to call into functions that exists as dll's (such as the IMAQ API), you can make use of
platform invoke services. This is the case where you would need to explicitly define each function that you are going to invoke from the unmanaged dll. Another mechanism is COM
interop, in which the .NET framework allows you to use ActiveX and COM based components and controls from within a .NET application. This is slightly easier to use since the wrapper code ( code that basically "tricks" a .NET application into thinking the component you are calling is actually a native .NET component) is automatically generated for you by using various tools that Microsoft provides as a part of the .NET framework. If you have Visual Studio .NET installed, you probably already have those tools.
Microsoft provides certain wizards that "upgrades" a VB 6 application to a VB.NET application, but you still need to go into the code and make some hand tweaks to make everything run ( it is a wizard afterall ).
But the .NET framework and any application written using the framework is a managed application. You can use various mechanism provided to call unmanaged code (code written in C, C++, anything non .NET ). But you can�t run .NET in unmanaged mode.
In your case, I dont believe the IMAQ dll is a COM component, which means you will need to use platform invoke to call the functions in the dll. If you have the IMAQ ActiveX controls, that might make the transition to VB.NET easier. You find tons of information about this on Google ( or your favorite search engine) or on the
MSDN.
I hope this helps
Bilal Durrani
NI
Bilal Durrani
NI