Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsVB SyntaxEnterprise DevelopmentDatabase AccessControlsCOMWin APICrystal ReportDeploymentGeneralGeneral 2
Related Topics
VB.NET / ASP.NETMS SQL ServerMS AccessOther Database ProductsMore Topics ...

VB Forum / COM / July 2008



Tip: Looking for answers? Try searching our database.

Experience debugging side-by-side applications in VB6

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
_Aditya_ - 24 Jul 2008 15:52 GMT
Hello All COM Developers!

I would like to know whether any of you have had experience debugging
side-by-side applications that are written in VB6?

In other words, let's say that different versions of the same product are
installed on one PC side-by-side. Both versions of the product use their own
COM types and now you would like to debug one version. Since the activation
information now lies in the manifest files for each version (instead of the
Windows registry), what is the best scenario to open the desired version in
VB6 and start debugging?

I see two scenarios of debugging here:

1. Register the COM types in the Windows registry for the application that
you want to debug and then open the application's project in VB6.

2. Add additional code to the application project to use the Activation
Context API and load the manifests for the COM types that the application
depends on.

I see scenario #2 as being more elegant but harder to implement in code.
This will keep the Windows registry clean (without COM activation entries)
allowing you to easily develop and test on the same PC.

On the other hand, Scenario 1 is the easiest way out since it uses the
traditional built-in implementation of VB6 to search the Windows registry for
the COM activation information. However, you have to remember to register the
collection of COM types that the application uses before loading the
application's project in VB6. This also pollutes the PC with COM entries in
the Windows registry, forcing you to either clean up before doing run-time
testing or test on another 'clean' PC altogether to ensure that side-by-side
is maintained.

I really would like the community's input on this and share your experiences.

Thanks.
Ralph - 29 Jul 2008 17:12 GMT
> Hello All COM Developers!
>
[quoted text clipped - 33 lines]
>
> Thanks.

The few attempts I made to debug a "side-by-side" installation with the VB6
IDE failed, because I always ran into a uncontrollable situation or
surprises.

The problem comes back to what is loosely called VB's tendancy to "highjack
the registry". ie, the IDE does not use dependancies in the same way the
finished product does. On startup it will gather all the information, then
create its own metafile/metastore and route all connections to a component
via that store through VB6Debug.dll. It is called a "highjack" because once
he has it, you will play hell getting it back. <g>

[A more concrete example of this behavior is VB's use of .oca and .dsa files
when working with OCXs and DSRs.]

Had some minimal (tho still unreliable) success with the .local hack and
popping components in and out of the project folder. But don't recommend it.
Not worth the hardship or pain, when after a couple of hours you realize you
have been chewing on the wrong animal. <g>

Your best bet is to create separate testing environments and lauch them
using a separate .reg or batch that re-registers the components. It takes
awhile to build each configuration, but you will be much happier and in
better control in the long run.

Of course your mileage may vary. ie, you might find a way. After-all,
nothing in programming is ever totally impossible - its only a matter of how
much time you're willing to invest. <g>

-ralph
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.