updating an ActiveX DLL by overwriting the existing dll

[Rico]

Hello,

I have a VB6 ActiveX DLL project that I use to connect to an SQL Server
database. The front end that uses this DLL is written in Access XP / 2002.
When I modify the ActiveX code, compile it and copy the DLL to the
production machine, the Access front end complains unless I pull the old
reference out of the "References" section of the tools menu item, close the
front end, open the front end and then re-reference the same library. Is
there a setting in the VB6 project that I can set so I don't have to do
this? I recall something to the effect that the component ID changes each
time the DLL is compiled using a certain setting, and it stays the same
under another setting. I can't seem to find those settings if this is the
case.

Any help would be greatly appreciated.

Thanks!
Rick

[Larry Daugherty]

Access is the culprit. I don't believe there's a way to defeat it.
When you place your DLL where it should be, The AddIn Manager writes
a copy of it locally. That's why you'll see AddIns that you've
uninstalled still in the list of AddIns that you can install with a
click. In the AddIn Manager, uninstall the target AddIn. Then delete
the local copy. Delete the old copy from the AddIns folder and
install the new copy there. Get back into AddIn Manager, add a new
AddIn, select the updated copy. AddIn Manager copies it to the local
folder and you can then click on it to install it. I haven't tried
just deleting the old copies and adding the new copy in the AddIns
folder.

Someday when I really have nothing to do I'll create another Virtual
PC, load Access and play with it.

HTH
--
-Larry-
--

"Rico" <[e-mail] in message
news:9z6Lk.2780$fF3.781@edtnps83...

Hello,

I have a VB6 ActiveX DLL project that I use to connect to an SQL

Server

database. The front end that uses this DLL is written in Access XP

/ 2002.

When I modify the ActiveX code, compile it and copy the DLL to the
production machine, the Access front end complains unless I pull the

old

reference out of the "References" section of the tools menu item,

close the

front end, open the front end and then re-reference the same

library. Is

there a setting in the VB6 project that I can set so I don't have to

do

this? I recall something to the effect that the component ID

changes each

time the DLL is compiled using a certain setting, and it stays the

same

under another setting. I can't seem to find those settings if this

is the

case.

Any help would be greatly appreciated.

Thanks!
Rick

[Larry Daugherty]

Just re-read your post more carefully. I don't think my response
addressed your issue. Sorry about that.

--
-Larry-
--

"Rico" <[e-mail] in message
news:9z6Lk.2780$fF3.781@edtnps83...

Hello,

I have a VB6 ActiveX DLL project that I use to connect to an SQL

Server

database. The front end that uses this DLL is written in Access XP

/ 2002.

When I modify the ActiveX code, compile it and copy the DLL to the
production machine, the Access front end complains unless I pull the

old

reference out of the "References" section of the tools menu item,

close the

front end, open the front end and then re-reference the same

library. Is

there a setting in the VB6 project that I can set so I don't have to

do

this? I recall something to the effect that the component ID

changes each

time the DLL is compiled using a certain setting, and it stays the

same

under another setting. I can't seem to find those settings if this

is the

case.

Any help would be greatly appreciated.

Thanks!
Rick

[Norman Yuan]

You need to set the VB ActiveX DLL project's compatibility to "Binary
Compatibility" compatible (Default is "Project Compatibility"), once your
DLL is used in production. You do this in VB6 by click menu
"Project->[ProjectName] Properties..., and then select tab "Component"

"Binary Compatibility" means, the component's class ID remains unchanged
during compiling, as long as existing component interfaces are not changed.
When you do the compiling after modification/bug fixing, VB6 would test if
existing binary compatibility is broken or not and prompt you.

"Rico" <[e-mail] in message news:9z6Lk.2780$fF3.781@edtnps83...

Hello,

I have a VB6 ActiveX DLL project that I use to connect to an SQL Server
database. The front end that uses this DLL is written in Access XP /
2002. When I modify the ActiveX code, compile it and copy the DLL to the
production machine, the Access front end complains unless I pull the old
reference out of the "References" section of the tools menu item, close
the front end, open the front end and then re-reference the same library.
Is there a setting in the VB6 project that I can set so I don't have to do
this? I recall something to the effect that the component ID changes each
time the DLL is compiled using a certain setting, and it stays the same
under another setting. I can't seem to find those settings if this is the
case.

Any help would be greatly appreciated.

Thanks!
Rick

[Rico]

Excellent! Thanks Norman!

Rick

"Norman Yuan" <Fa******@FakeEmail.Notwrote in message
news:uo**************@TK2MSFTNGP02.phx.gbl...

You need to set the VB ActiveX DLL project's compatibility to "Binary
Compatibility" compatible (Default is "Project Compatibility"), once your
DLL is used in production. You do this in VB6 by click menu
"Project->[ProjectName] Properties..., and then select tab "Component"

"Binary Compatibility" means, the component's class ID remains unchanged
during compiling, as long as existing component interfaces are not
changed. When you do the compiling after modification/bug fixing, VB6
would test if existing binary compatibility is broken or not and prompt
you.

"Rico" <[e-mail] in message news:9z6Lk.2780$fF3.781@edtnps83...

>Hello,

I have a VB6 ActiveX DLL project that I use to connect to an SQL Server
database. The front end that uses this DLL is written in Access XP /
2002. When I modify the ActiveX code, compile it and copy the DLL to the
production machine, the Access front end complains unless I pull the old
reference out of the "References" section of the tools menu item, close
the front end, open the front end and then re-reference the same library.
Is there a setting in the VB6 project that I can set so I don't have to
do this? I recall something to the effect that the component ID changes
each time the DLL is compiled using a certain setting, and it stays the
same under another setting. I can't seem to find those settings if this
is the case.

Any help would be greatly appreciated.

Thanks!
Rick

[Tony Toews [MVP]]

"Norman Yuan" <Fa******@FakeEmail.Notwrote:

>You need to set the VB ActiveX DLL project's compatibility to "Binary
Compatibility" compatible (Default is "Project Compatibility"), once your
DLL is used in production. You do this in VB6 by click menu
"Project->[ProjectName] Properties..., and then select tab "Component"

"Binary Compatibility" means, the component's class ID remains unchanged
during compiling, as long as existing component interfaces are not changed.
When you do the compiling after modification/bug fixing, VB6 would test if
existing binary compatibility is broken or not and prompt you.

Thanks for that explanation.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[MikeD]

"Larry Daugherty" <La********************@verizon.netwrote in message
news:uf**************@TK2MSFTNGP06.phx.gbl...

Just re-read your post more carefully. I don't think my response
addressed your issue. Sorry about that.

Nope. Doesn't really have anything to do with Access at all (therefore, it's
actually off-topic for an Access newsgroup). As Norman said, binary
compatibility needs to be set for the VB6 DLL. If binary compatibility is
ever broken in the DLL, then this same problem will re-occur. Generally, you
can ADD new public properties, methods, and events to the DLL without
breaking binary compatbility. However, you cannot change or delete anything
exposed in the public interface. You can change the code for any of those,
but you can't change the procedure header (for example, parameters passed to
methods, any data types, etc.).

--
Mike

[Ken Halter]

"Rico" <[e-mail] in message news:fw9Lk.2816$fF3.431@edtnps83...

Excellent! Thanks Norman!

Rick

"Norman Yuan" <Fa******@FakeEmail.Notwrote in message
news:uo**************@TK2MSFTNGP02.phx.gbl...

>You need to set the VB ActiveX DLL project's compatibility to "Binary
Compatibility" compatible (Default is "Project Compatibility"), once your
DLL is used in production. You do this in VB6 by click menu
"Project->[ProjectName] Properties..., and then select tab "Component"

"Binary Compatibility" means, the component's class ID remains unchanged
during compiling, as long as existing component interfaces are not
changed. When you do the compiling after modification/bug fixing, VB6
would test if existing binary compatibility is broken or not and prompt
you.

There's a few "gotchas" involved, though... always remember the file you're
relying on for compatibility *must* include all publics. If you add
something new, you need to updated the file you're using for compatibility.
http://www.vbsight.com/BinaryComp.htm

--
Ken Halter
Part time groupie