I've got an annoying issue here... I'm doing late-binding to a VB6
DLL which references a third-party OCX (for Graphics Server
Workstation). The OCX exists in system32, however we also keep a
local copy of it in our program's directory to avoid version
mismatches by other programs overwriting the file. The VB6 program
has a .local file for its EXE, which tells Windows to look for local
versions of any referenced files before searching in system32, and
that works fine for the VB6 app. However when I late-bind to the VB6
DLL from my .NET application, it is not honoring the .local file and
is creating another instance of Graphics Server Workstation using the
OCX in system32, even though the VB6 DLL is early bound to our
program's local copy of the OCX.

I should also point out that this .NET program was working perfectly
fine in .NET 1.1, but this issue popped up when I upgraded it to .NET
2.0.

Any ideas as to why this is happening and how I can fix it? Thanks in
advance.

By the way I'm doing the late binding like this:
Type MyObjectType = Type.GetTypeFromProgID
("MyDLL.ObjectToInstantiate", true);
object MyObject = Activator.CreateInstance(MyObjectType);
MyObjectType.InvokeMember("MethodToCall", BindingFlags.InvokeMethod,
null, MyObject, null);

The only thing that changed from the .NET 1.1 to .NET 2.0 versions was
adding the second argument in Type.GetTypeFromProgID, sending true to
throw any errors.

Thanks.


On Apr 27, 4:52*pm, Stu <stumor... (AT) gmail (DOT) com> wrote:

"Stu" <stumorgan (AT) gmail (DOT) com> wrote

If you use the ProgID, which is stored in the registry, you get the coclass
GUID and InProcServer path stored in the registry.

Maybe you want to configure Registration-Free COM Activation for this object
for your application:
http://msdn.microsoft.com/en-us/library/ms973913.aspx#rfacomwalk_topic6

On Apr 27, 6:56*pm, "Ben Voigt [C++ MVP]" <r... (AT) nospam (DOT) nospam> wrote:

That article is really rather confusing.... Firstly it just tells me
to copy and paste manifest information, without ever explaining what
that information is and what it does. In the SideBySide.X.manifest
file, it looks like I need to declare each and every class from the
SideBySide.dll that I want to reference, is that true? Is there no
easier way to just tell my program to use a specific DLL (and all
classes and functions contained within it) without having to list
every class I want to use in the manifest file? The DLL I'm
referencing has literally hundreds of classes, this would be a tedious
task to say the least. Also, I've done some further testing and the
problem is definitely caused by moving my EXE from .NET 1.1 to .NET
2.0. Why would that cause this to suddenly be a problem when it
worked just fine before?

Thanks,
Stu

It is a problem because you're not using the versioning mechanism designed
for COM objects. The object is supposed to provide both version-specific
and version-independent ProgID and you're supposed to use the specific one
if you're afraid of newer versions breaking compatibility.

I think you should only need to list the classes you create with Activator,
not all the classes in the object model.

Another option would be to set up registry redirection for your application
so you operate with a private registry that puts the path to your copy of
the DLL in InProcServer.

On Apr 28, 1:26*pm, "Ben Voigt [C++ MVP]" <r... (AT) nospam (DOT) nospam> wrote:

The thing is, it's not the version of the COM DLL that is giving me
problems. It's that the COM DLL is referencing the system32 copy of
the 3rd party OCX when being called from my .NET stuff, and I need it
to use the copy it has in its local program directory. So I don't
think having the manifest file specify version information for the COM
DLL is going to help me. And as I'm not referencing the 3rd party OCX
directly, I don't think putting its information in the manifest will
help either (or will it?)

The registry redirection sounds like it might help if I can figure it
out. I'll have to do some research into that.

Thanks again.

Stu wrote:
ActiveX is built on COM, so it uses the same versioning rules.

You might be able to put the OCX information in the manifest, I really
haven't done this before so I don't know. It's a good idea and worth a try
anyway.

This is probably what you need:
http://msdn.microsoft.com/en-us/library/ms724901(VS.85).aspx