"partybo***@hotmail.com" wrote:

> Hi everyone.
>
> I have a very strange problem and I have no idea how to correct it.
>
> I created a VB.NET DLL that is used by several different apps for
> password file encryption/decryption.  I have the original .NET DLL and
> I also built the DLL with a COM wrapper (the COM interop box checked in
> the project...) so it can be used with VB6 apps (or any other language
> for that matter).  In order for a VB6 app to use this DLL, this control
> must be registered on the local operating system using REGASM.
>
> The user has an icon that points to the vb6 app on a mapped network
> drive.  When the application starts, the app will access the .NET DLL
> (packaged in the COM wrapper) locally on the operating system.  It does
> NOT try to look the the local path of the .exe to access the DLL as
> this is not how vb6 works when accessing DLLs.
>
> This approach works great on 2300 + machines with no issues.
>
> Recently we added a VB.NET application that uses this same DLL.
> However, in this case, the DLL is stored in the same folder as the
> VB.NET application along with the VB6 app decribed above.  For 2300
> machines this approach also works great.  However, we have one machine,
> running Windows 2000 server that is causing problems.  If we copy the
> VB6 application on the network locally to the server's C: drive, it
> will start up prefectly.  However, if we try to run the application
> from an icon to the mapped network drive, the app comes back with a
> "ERROR 430 " "Class does not support Automation or does not support
> expected interface".  BUT, if i rename or remove the vb.NET DLL that is
> in the same path as the VB6 application we are trying to run, it starts
> up and works great.
>
> It appears that, for one reason or another, the VB6 application is
> trying to open the vb.net DLL that is located in the same folder
> instead of loading the DLL registered with the local operating system.
> However, this condition occurs on only ONE server.  With all other PCs,
> the vb6 app can be started from the network drive, the DLL is started
> normally and it does not matter if the VB.NET is in the same path as
> the vb6 app or not.
>
> I have never seen anything like this before.  Any help would be
> appreciated.
>
> Thanks in advance.
>
>

> Hello Bob ( ?)
>
> The Location of a COM capable automation object is stored in  the registry
> by Class ID   , the easies way to solve this problem is by unregestring the
> dll and then reregister it the problem should then be solved
>
> REGASM has an unregister switch      REGASM /u MyAssembly.dll
>
> Regards
>
> Michel Posseth [MCP]
>
>
>
>
>
>

> Hi, thanks for responding..  I already tried this.  And after I ran
> REGASM with /unregister, I noticed there were still a few registry
> entries left over so I did a manual lookup of the DLL in the registry
> and deleted every key that referred to the DLL as well.  That way I
> know the system is clean.  And I've done the same procedure before on
> my own machine so I know it works.
>
> The vb6 works great as long as the dll is not in the same path..  when
> it's there, it bombs with error 430.  all other pcs in the enterprise
> (over 2300) have reported no problems when the .net dll is in the same
> path as the vb6 app.
>
> Yes, I'm literally scoured every source I could think of and i've never
> seen anything like this.  I think it has to do with security somehow
> with the server but I have no idea as to what it could be however.
>
>
> M. Posseth wrote:
>> Hello Bob ( ?)
>>
>> The Location of a COM capable automation object is stored in  the registry
>> by Class ID   , the easies way to solve this problem is by unregestring the
>> dll and then reregister it the problem should then be solved
>>
>> REGASM has an unregister switch      REGASM /u MyAssembly.dll
>>
>> Regards
>>
>> Michel Posseth [MCP]
>>
>>
>>
>>
>>
>>
>