We are having problems getting VB6 to instantiate objects written in dot net.
Initial versions of the components worked fine - they were built on
development machines and shipped to test machines. There were no problems.

We have now moved to a dot net build machine. Initially, the binaries
seemed to work just fine, but then we started to get COM errors. After a lot
of puzzling, we worked out that the build machine was not building the dot
net component with COM Visibility turned on. So machines would work if they
had had the development builds on them previously, because the registry
entries were there. New components would not work.

Having sorted out this issue, we are still seeing very puzzling behaviour.
Some machines seem to work and other do not. The only machine that we have
all the objects working on only works if you log in as the user who
registered the components.

Our situation is made more complex by the structure of our application. We
live in a parent VB6 application under a different folder. Our traditional
(VB6-only) struture looks like this:
VB6 EXE lives here - Program Files\Company Name\ParentApp
Parent App COM objects live here - Program Files\Company Name\Parent
App\Components
Our components live here - Program Files\Company Name\OurApp\Components
With VB6 only, the location of the binaries does not matter. Our parent app
has introduced some dot net binaries, which live here:
Program Files\Company Name\ParentApp\Assemblies
and they told us to put our dot net components here:
Program Files\Company Name\OurApp\Assemblies

The assemblies are not signed, so we believe that the location should be the
same as the EXE which launches them. So we do not understand how this works
on any machine at this point.

We simply need to have VB6 instantiate dot net components which are COM
visible: this shouldn't be as difficult as it has turned out to be. What are
we missing here?


--
Kenny.
Systems Developer