Convert from vb6 Error loading type library/DLL

[mp]

Hi
just starting to transition from vb6 to dotnet
converted a working vb6 project to start
small project very simple, got 48 errors, 113 warnings


starting at the top of the list, (i tried to google groups this question but
diddn't find anyting)
dhRichClient is a registered dll
Warning 1 Could not determine the dependencies of the COM reference
"dhRichClient". Error loading type library/DLL. (Exception from HRESULT:
0x80029C4A (TYPE_E_CANTLOADLIBRARY))

what's the solution?
is there a specific site or other place than here to find solution to all
these errors and warnings(other than obvious ones)?

Thanks
mark

 

[Armin Zingler]

Hi
just starting to transition from vb6 to dotnet
converted a working vb6 project to start
small project very simple, got 48 errors, 113 warnings


starting at the top of the list, (i tried to google groups this question but
diddn't find anyting)
dhRichClient is a registered dll
Warning 1 Could not determine the dependencies of the COM reference
"dhRichClient". Error loading type library/DLL. (Exception from HRESULT:
0x80029C4A (TYPE_E_CANTLOADLIBRARY))

Did you use the upgrade wizard? Make sure the VB6 project is compilable
with VB6 on the same machine that runs the wizard. No, you do not have
to compile it, but it would have to be compilable if you tried it.
Otherwise the wizard is at least not able to resolve external references.

Sometimes these errors are hard to resolve because the actual problems
lies somewhere else. For example, it can also be a dependent library
that cannot be loaded. Sometimes you just have to single-click on the
reference in the solution explorer. It's often unclear.

what's the solution?
is there a specific site or other place than here to find solution to all
these errors and warnings(other than obvious ones)?

Tell us some of them. I've spent a lot of time to upgrade a bigger
project (just for gaining experience...) so maybe I can help.

It depends on the project if using the wizard or rewriting is the better
solution. In the best case, you have well written VB6 dlls that require
only little additional work after the upgrade. After that it's up to you
whether and when you want to rewrite portions of the code and utilize
contemporary methods.


Armin

 

[Scott M.]

There is no substitue for learning what VB .NET is all about. You can try
to patch one error after another, but it won't make any sense until you
understand what is happening.

The first thing to know about VB .NET is that is is NOTHING like VB
(although it appears to be very similar on the surface). Most VB 6 code
that is made to *work* in .NET, is not really leveraging .NET.

Your best bet is to know what you expect to get for your troubles by
converting in the first place and, if possible rewrite the application from
scratch to get the most from what .NET has to offer.

-Scott

 

[mp]

Thanks so much Armin for responding.
see inline

snip

Did you use the upgrade wizard?

yes

Make sure the VB6 project is compilable

with VB6 on the same machine that runs the wizard.

yes i compiled before trying to convert

Sometimes these errors are hard to resolve because the actual problems
lies somewhere else. For example, it can also be a dependent library
that cannot be loaded. Sometimes you just have to single-click on the
reference in the solution explorer. It's often unclear.

what's weird is the solution explorer can look in the dll and see everything
so I would think it was loaded except for the error message

Tell us some of them. I've spent a lot of time to upgrade a bigger
project (just for gaining experience...) so maybe I can help.

you saw the other two I posted,

others include
original code line:

GetErrorTextFromResource = LoadResString(ErrorNum)

converted codeline:

GetErrorTextFromResource = My.Resources.ResourceManager.GetString("str" +
CStr(ErrorNum))

error report:

'Resources' is not a member of 'My'

(Some of these things may not even be used in this project as it's refereing
to some general util classes and modules i use in many projects)

also:
'FindFirstFile' is not a member of 'Win.WinBase'
'FindClose' is not a member of 'Win.WinBase'
'FormatMessage' is not a member of 'Win.WinBase'
'CopyFile' is not a member of Win
'GetAsyncKeyState' is not a member of 'Win.User

lots of ones like that

thanks for any guidance

Mark

 

[mp]

Thanks for the input
mark

There is no substitue for learning what VB .NET is all about. You can try
to patch one error after another, but it won't make any sense until you
understand what is happening.

The first thing to know about VB .NET is that is is NOTHING like VB
(although it appears to be very similar on the surface). Most VB 6 code
that is made to *work* in .NET, is not really leveraging .NET.

Your best bet is to know what you expect to get for your troubles by
converting in the first place and, if possible rewrite the application
from scratch to get the most from what .NET has to offer.

-Scott

 

[Armin Zingler]

what's weird is the solution explorer can look in the dll and see everything
so I would think it was loaded except for the error message

Hard to say from here. I can't recall every problem I had.
I remember it ended up in manually creating the interop wrappers for all
referenced COM dlls. (don't do it..was my personal fun )

you saw the other two I posted,

others include
original code line:

GetErrorTextFromResource = LoadResString(ErrorNum)

converted codeline:

GetErrorTextFromResource = My.Resources.ResourceManager.GetString("str" +
CStr(ErrorNum))

error report:

'Resources' is not a member of 'My'

(Some of these things may not even be used in this project as it's refereing
to some general util classes and modules i use in many projects)

That's strange.... I've just tried the same in a new project just
containg LoadResString... yes, I get the same error. Don't know if this
is a known issue. I've searched here for "loadresstring":
http://connect.microsoft.com/VisualStudio/feedback
=> not found
(I haven't used ressources so I didn't come across this problem.)

also:
'FindFirstFile' is not a member of 'Win.WinBase'
'FindClose' is not a member of 'Win.WinBase'
'FormatMessage' is not a member of 'Win.WinBase'
'CopyFile' is not a member of Win
'GetAsyncKeyState' is not a member of 'Win.User

lots of ones like that

I don't know what win.winbase is in the vb6 project.

Do your references work now? Without that, you'll keep getting these errors.


Armin

 

[Armin Zingler]

GetErrorTextFromResource = LoadResString(ErrorNum)

I've tried LoadResPicture which gets upgraded to

VB6.LoadResPicture

(full name: Microsoft.VisualBasic.Compatibility.VB6.Support.LoadResPicture)

So try replacing

My.Resources.ResourceManager.GetString("str" + CStr(ErrorNum))

by

VB6.LoadResString("str" + CStr(ErrorNum))


Armin

 

[mp]

Thanks for the info
This dll is still the first error and an important one for me to fix as I
use a class in that dll a lot
maybe there's a dotnet replacement for the object but I don't know
It's a component by Olaf Schmidt which has an awesome colllection type
object cSortedDictionary that I've gotten addicted to (with .Exists property
and .KeysByIndex etc that are very useful)

Don't know if there's an equivalent in dotnet

I saw an old post on google groups that suggested putting a copy of the dll
in the project folder but that didn't help either...
any other thoughts?


on another topic, in vb6 everyone avoided the scripting.FileSystemObject to
work with files like the plague. in dotnet is it(or is't equivalent...what
ever it's called now) unavoidable?, for instance to get files, lists of
files, FileExists, stuff like that?
eg
things that FindFirstFile api would have been used for (for speed over fso)

thanks again for all your help
mark

 

[Armin Zingler]

Thanks for the info
This dll is still the first error and an important one for me to fix as I
use a class in that dll a lot
maybe there's a dotnet replacement for the object but I don't know
It's a component by Olaf Schmidt

I know him.

which has an awesome colllection type
object cSortedDictionary that I've gotten addicted to (with .Exists property
and .KeysByIndex etc that are very useful)

Don't know if there's an equivalent in dotnet

There are many different types of collections. Have a look in the
System.Collections, System.Collections.Generic and
System.Collections.Specialized namespaces.

I saw an old post on google groups that suggested putting a copy of the dll
in the project folder but that didn't help either...
any other thoughts?

You said "class", so it seems to be a ActiveX dll. Well, if you did
register it, remove the reference and set it again. (an interop wrapper
will be created automatically, and by default it should be in the right
location)

on another topic, in vb6 everyone avoided the scripting.FileSystemObject to
work with files like the plague.

right

in dotnet is it(or is't equivalent...what
ever it's called now) unavoidable?, for instance to get files, lists of
files, FileExists, stuff like that?
eg
things that FindFirstFile api would have been used for (for speed over fso)

VB.Net offers some VB special classes/functions, also for file access.
Many of them are not required because the Framework (the VB stuff is
also a part of it) already offers everything and it is the straighter way.

Have a look at the System.IO namespace. Some spontaneous thoughts (classes):

File access:
- FileStream: An object to access a file. All file access goes through
this object. It offers only basic read/write methods. Therefore there is the

- StreamWriter/StreamReader that offers plenty of methods to read/write
from/to a file. Including String conversion from/to Unicode. Be aware
that Strings are stored as Unicode in memory and use the right character
encoding when reading/writing from/to a file. You can specify the
Encoding when creating the StreamWriter/Reader, so it automatically does
the conversion if you call, for example, the StreamWriter's WriteLine
method.


Other file system classes: (as you've asked above)
- Directory: Offers several (shared) methods. For example
CreateDirectory, Delete, Exists, GetCreationTime

- File: Similar to Directory but for files


Referring to "FindFirstFile": Now you get the information about
files/directories in "FileSystemInfo" objects. The derived classes are
DirectoryInfo and FileInfo, depending on what it is. For example, if you
want to get all files (i.e. file system entries) in a directory, create
a DirectoryInfo object and call it's GetDirectories, GetFiles or
GetFileSystemInfos (which gets both types) methods. No need to call
FindFirstFile/FindNextFile.


Well, the object browser will be most helpful for getting an overview.


Armin

 

[Armin Zingler]

You said "class", so it seems to be a ActiveX dll. Well, if you did
register it, remove the reference and set it again. (an interop wrapper
will be created automatically, and by default it should be in the right
location)

Just to be sure: We are still at the problem "Could not determine the
dependencies of the COM reference", right?
Does the dll require other additional dlls that are still not registred?


Armin

 

[mp]

Thanks a lot
I have a lot of learning to do

Mark

 

[mp]

Hi again, see inline

Armin Zingler schrieb: snip

sorry you lost me on that one
I registered it via (windows xp) Run Regsvr32.exe pathtodll
if the interop wrapper wasn't created the first time why would it work
differently after removing and re-registering?
or are you suggesting that internal to vbexpress there is a registration
method?

or from your saying "by default it should be in the right location" what is
right location?
or are you saying i have to register a copy that is in the vb.net project
folder, not the location for my standard vb6 projects common location
folder?
would that mean i have to register a copy for vb6 from one location and a
different copy for .net from a different location???

Just to be sure: We are still at the problem "Could not determine the
dependencies of the COM reference", right?
right

Does the dll require other additional dlls that are still not registred?

not on vb6, it is Olafs dhRichClient.dll

in vb6 I can register that dll and have access to all its'
"subobjects"...specifically cSortedDictionary

 

[Tom Shelton]

Hi again, see inline



sorry you lost me on that one
I registered it via (windows xp) Run Regsvr32.exe pathtodll
if the interop wrapper wasn't created the first time why would it work
differently after removing and re-registering?
or are you suggesting that internal to vbexpress there is a registration
method?

or from your saying "by default it should be in the right location" what is
right location?
or are you saying i have to register a copy that is in the vb.net project
folder, not the location for my standard vb6 projects common location
folder?
would that mean i have to register a copy for vb6 from one location and a
different copy for .net from a different location???



not on vb6, it is Olafs dhRichClient.dll

in vb6 I can register that dll and have access to all its'
"subobjects"...specifically cSortedDictionary

Have you looked at the System.Collections.Generic.SortedDictionary (Of TKey,
TValue)? You maybe better off converting to this in the long run then trying
to sort out these nasty COM issues

 

[mp]

snip
Have you looked at the System.Collections.Generic.SortedDictionary (Of
TKey,
TValue)? You maybe better off converting to this in the long run then
trying
to sort out these nasty COM issues

thanks, sounds like a possibility
I need to spend more time in the object browser, being totally new to .net i
don't know of all these things that should probably be obvious.
also I take to heart the advice to get a book on .net and rewrite everything
from ground up instead of trying to convert as the structure may be
completely inappropriate for the new .net world.
originally i just thought converting a working prograam would be a way to
get my feet wet with learning the new objects and syntax...maybe that
thought lacks merit?

thanks again
mark

 

[Armin Zingler]

sorry you lost me on that one
I registered it via (windows xp) Run Regsvr32.exe pathtodll
if the interop wrapper wasn't created the first time why would it work
differently after removing and re-registering?

You never know. "I've seen horses puking." as we say here

or are you suggesting that internal to vbexpress there is a registration
method?

No, it was just an attempt.

or from your saying "by default it should be in the right location" what is
right location?

I don't know. That's why I wrote "right location". I just meant
that, if everything is registered correctly and all depending files are
there, just setting the reference should be all you have to do.

Usually If I set a COM reference, the interop.dll is put in the
application\obj sub directory. Then it's also copied to the output
directory (the exe directory).

or are you saying i have to register a copy that is in the vb.net project
folder, not the location for my standard vb6 projects common location
folder?
would that mean i have to register a copy for vb6 from one location and a
different copy for .net from a different location???

No no, calm down it was just an attempt.

not on vb6, it is Olafs dhRichClient.dll

see below

in vb6 I can register that dll and have access to all its'
"subobjects"...specifically cSortedDictionary

Well, I've downloaded the dll but registering failed ("Loadlibrary
failed"). When I try to set a reference to it in a VB 2008 project, it
also fails. Same message as you are facing.

Then I've tried tlbimp.exe with the dll (with /verbose switch). It tells
me that a depending type library is missing. It's the type of property
"oTI" of class "cEventInfo". I didn't find it out which type it is
because the OLE/COM object viewer also only says "<GetRefTypeInfo
failed>" for this type but doesn't tell me which type it is.

Anyway, the dll does have a reference.

So, after manually importing the dll (two depending dlls have been
generated automatically: VBA.dll and VBRUN.dll. For some others like
stdole there are already PIAs existing) I can set a reference to it in a
VB 2008 project without a problem. Though, without being able to
register it, an exception will occur at runtime.


Sorry, I currently don't know what's missing. In VB6, have a look at the
type of the property cEventInfo.oTI. Maybe that's the key.


Armin

 

[Tom Shelton]

Hi again, see inline



sorry you lost me on that one
I registered it via (windows xp) Run Regsvr32.exe pathtodll
if the interop wrapper wasn't created the first time why would it work
differently after removing and re-registering?
or are you suggesting that internal to vbexpress there is a registration
method?

or from your saying "by default it should be in the right location" what is
right location?
or are you saying i have to register a copy that is in the vb.net project
folder, not the location for my standard vb6 projects common location
folder?
would that mean i have to register a copy for vb6 from one location and a
different copy for .net from a different location???



not on vb6, it is Olafs dhRichClient.dll

in vb6 I can register that dll and have access to all its'
"subobjects"...specifically cSortedDictionary

Out of curiosity... I downloaded the dhRichClient.dll and ran it's
register.bat file. I then created a simple vb.net console application,
selected add references, switched to the com tab, and added a reference to the
dhRichClient library. The ide then generated the interop assembly and i was
ready to go. It seems to work fine - here is the app:

Option Strict On
Option Explicit On

Imports dhRichClient3

Module Module1

Sub Main()
Dim d As New cSortedDictionary()
d.Add("hi", 2)
Console.WriteLine(d.Exists("hi"))
Console.WriteLine(d.Item("hi"))

Dim d2 As New SortedDictionary(Of String, Integer)
d2.Add("hi", 2)
Console.WriteLine(d2.ContainsKey("hi"))
Console.WriteLine(d2("hi"))

End Sub

End Module

for comparison, I performed the same operations on a SortedDictionary. I'd
also like to point out that, a simple benchmark is showing MUCH better
performance for the native SortedDictionary then cSortedDictionary. That
actually is what I expected for a number of reasons:

1) no com interop marshalling on every call
2) use of generics to avoid casting

 

[Tom Shelton]

thanks, sounds like a possibility
I need to spend more time in the object browser, being totally new to .net i
don't know of all these things that should probably be obvious.
also I take to heart the advice to get a book on .net and rewrite everything
from ground up instead of trying to convert as the structure may be
completely inappropriate for the new .net world.
originally i just thought converting a working prograam would be a way to
get my feet wet with learning the new objects and syntax...maybe that
thought lacks merit?

No, it doesn't lack merrit at all. It's just in this case, you will be better
of using the native class becase you:

1) avoid distribution and registration of the 3rd party com component
(ignoring reg free com)
2) much better preformance because of the use of generics and avoidance of com
marshalling overhead.

 

[Armin Zingler]

Sorry, I currently don't know what's missing. In VB6, have a look at the
type of the property cEventInfo.oTI. Maybe that's the key.

But, as Tom also says like I did before, you should better have a look
at System.Collections instead of wasting so much time to make a COM
component run.


Armin

 

[mp]

Thanks again for your time and information
mark

snip


No, it doesn't lack merrit at all. It's just in this case, you will be
better
of using the native class becase you:

1) avoid distribution and registration of the 3rd party com component
(ignoring reg free com)
2) much better preformance because of the use of generics and avoidance of
com
marshalling overhead.

 

[teezee]

Win.WinBase

i know this may be out of date, but the Win.WinBase is a type library (win.tlb, it's probably on your system somewhere). I've got a copy if it would help, but you'd have to find replacement for the function within it that your program is calling.