ActiveX component can't create object

[Steven McGarva]

A question about VB DLL's.

We have a web site on an NT server which uses ASP, ORACLE and a VB DLL. I have made some changes to the guts of a few methods in the DLL, and recompiled it. No new methods, but 2 new Global Constants. I also made some minor changes to the ASP pages.

I have unregistered the old DLL and re-registered the new one.

Now I get the following error mesage on the web page:

Billing.CPartners error 800a01ad
ActiveX component can't create object
/getcust.asp, line 119

Line 1 'Billing' is the dll, cPartners is a method that has not been changed but is the first method called by the ASP page.

Line 2 I don't understand.

Line 3 is the first ASP page accessed.

I am sure the newly compiled DLL is valid in terms of it's code, and it is properly registered (yes, the service was stopped/started also).

Anybody any ideas?

[Shrog]

When you create a DLL, each public function, method, etc. gets a unique ID to identify it. The client program that uses that DLL relies on those ID's to make sure that it has the correct method.

When you recompile the DLL, the ID's are recreated, that is they don't match the ID's in the client. You have to recompile the client applications to pull in the new ID's.

To overcome this problem, you have to set the compatibility of the DLL component. Go to the Project's properties, and under the Component tab, you will find Version Compatibility.

In your case, you would want to use Binary compatibility, because it allows you to compile the DLL using the old ID's. This means that you don't have to recompile the client apps each time you recompile the DLL.

Hope this helps.
Shrog

[Steven McGarva]

Thanks Shrog, it certainly makes sense. But I now recompile on a new development environment and ftp it to the Live server. The original DLL was compiled on this Live server ages ago. Does this create a problem as the original ID's will be on the original server (where it was first compiled), and new ones on the development machine.

Ideally I would like to be in a position to compile a DLL on my development environment and send it to the live server, register it, and lo and behold its available to the ASP pages.

An added complication might be that it was originally VB5, now its VB6, but I tried VB5 also and it did'nt work(as I still have access to it), again on Dev, sending the DLL to Live. Obviously this is due to the ID issues you mentioned.

Any tips would be really helpfull.

[Shrog]

You don't have to worry yet. All you need is a copy of the original DLL, the one before the recompile.

When you look at the project compatibility options, you see:
No Compatibility
Project Compatibility
Binary Compatibility
and then a textbox and a button with a "..." in it.

In this textbox, you can enter the DLL that you want to be compatible with. Click the command button to browse for the original DLL. Now the compiler will know which DLL's IDs to use.

Make sure that each time you break the compatibility, i.e. each time you compile with new IDs, that you keep a copy of that DLL in a safe place for compatibility purposes. As long as you have the original, you can be compatible.

Regards
Shrog

[Steven McGarva]

Yes Shrog its all becoming clear to me, you explain this well. Can I ask you more?

It seems there are several versions on the Live server, say Ver1.0, Ver1.2, Ver 1.3. Folders exist with all the source code and compiled DLL. I am sure I can find out which one is currently registered and working.

If I were to zip and remove off-line all previous versions and source code, only keeping the current live DLL (Ver 1.3) in a folder, say C:\Original\Keep\my.DLL.

Should I then get one copy of the source code in say C:\New\ver4\my.DLL (and compile Ver 1.4 there).

Then whenever I recompile in C:\New\ver4\my.DLL I save a copy of the new DLL to C:\Original\Keep\my.DLL.

What bothers me is the continuation of the compatability, I mean if I use Ver 1.3 and it is based on Ver 1.2, do I only need Ver 1.3 when compiling Ver 1.4?

Second question for you Shrog, I hope I'm not wearing your patience thin.

I want to get away from source code on the Server and develop on an other machine. How can I do this if the original ID's are on the Server (as it was previously compiled there). I want to just create/compile on a Development box, FTP to the Server and register it. My boss is not to happy with me accessing the Server for any development work.

[Shrog]

The ID's that are created are compiled into the DLL and is machine independant. That means it does not matter where you compile it, ig goes with the DLL itself, not the machine. You can take your sourcecode anywhere you want. The important thing is that the compiler has acces to a copy of the DLL that you want to be compatable with.

The question about which version(s) to keep and which version(s) to be compatable with is a very common question, and an important issue. Think about it this way:

Version 1 has a function A.
Now you come out with a version 2, that includes a function B.
Now you want to create a third version. Do you remain compatable with version 1 or 2?
If you use Version 1, your new DLL needs only to be compatable with function A and not B, so a new ID will be created for function B and you'll have problems again.
If you use version 2 for compatability, bot A and B will keep their original ID's.

Another aspect to remember is who has your DLL. If you release version 3 with function C, and it turns out that it wasn't so good, you would like to make changes to C, you can revert back to version 2 compatability and recreate a new version 3. But if millions of users are already using version 3, you're stuck. In such a case you may want to create a new function C1 to fix the problem. My point is, don't throw away past releases - you never know when you might want to go back to an older compatability.

C:\Compatability\Version1.0\my.dll
C:\Compatability\Version1.3\my.dll
C:\Compatability\Version2.0\my.dll

Regards
Shrog

p.s. I don't mind answering questions.