467,145 Members | 1,053 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,145 developers. It's quick & easy.

VB6 project group load problem

This is a request for assistance analyzing a problem we are experiencing in
our VB6 development environment. All our code is developed in VB6, and our
persistance layer is SQL Server. We are planning to convert this project to
dot net sometime in the future.

Our architecture is an exe project with references to four business object
dlls. Also, each one of our tables is encapsulated in a data object dll.
The data objects are referenced by the exe and the business object dlls as
needed.

This project is currently in production with installs at over 300 customer
sites. The project has been in development for over three years, and has
steadily gotten larger as additional functionality is added.

In our development environment, we load the exe project in the VB IDE with
whichever business objects we happen to be working on at the time. We load
these in a project group in a single instance of the VB6 IDE.

Recently, we have started running into a problem where when we load the
project group containing the exe project and a business dll, we start taking
numerous errors that look like this:

"Could not create reference '<path to dll>'."

The number and order of the errors depends on the order in which projects
are loaded in the project group. It does not matter what else is running on
the machine, nor does it matter what system resources are available.

We already have a workaround for this problem. Instead of loading the exe
and the business objects in a single project group, we have started loading
the exe in one VB6 instance and the business objects in another VB6
instance. This workaround is fine for our development purposes, and we are
continuing using this technique.

However, since I am not certain precisely what limitation is causing this
problem, I am concerned that our current architecture is not supportable and
we are going to run into this limitation again sometime in the future and
will be unable to continue with our development.

Note that we plan to migrate the application to dot net in the future, as we
have customer demand and develop the customer support that we will need to
support it in the field.

Analysis of our exe vbp shows references to the following code modules:
- 18 class modules
- 87 forms
- 25 bas modules
- 1 resource file

In addition, the exe vbp has references to the following:
- 23 ocx modules, 21 of which are 3rd party, two are in-house
- 131 dll references, 126 are in-house, one is 3rd party, and four are
Microsoft:
* Microsoft ActiveX Data Objects 2.7 Library
* Microsoft Data Formatting Object Library 6.0 (SP4)
* Microsoft Data Report Designer 6.0 (SP4)
* OLE Automation

This number of references does not seem particularly large to me, and I have
worked on much larger projects in the past.

Research on MSDN shows plenty of information on VB limitations, specifically
Microsoft Knowledge Base Article 229756:
http://support.microsoft.com/default...b;en-us;229756

After analyzing these limitations, these are the ones that concern me with
regard to my project, which I quote here from the KB article:

1. Project-Name Table - The entire application uses a single table that
contains all names. These include: Constant names; Variable names;
User-defined - type definition names; Module names.

2. DLL-procedure declaration names - The project name table is unlimited in
total size, but is limited to a total of 32K case-sensitive unique entries.
If the limit is reached, reuse private identifiers in different modules to
limit the number of unique entries to 32K.

3. Import Table - Every reference to an identifier in a different module
creates an entry in the Import Table. Each such entry is a minimum of 24
bytes and is restricted to 64K, resulting in roughly 2,000 references per
module.

These limitation descriptions may be technically correct, but they do not
give me the information that I need to analyze the problem we are currently
experiencing in our development environment. Also note that these quotes do
not specify whether they refer to a single project or a project group.

My questions are these:
1. Do the "Could not create reference" errors that we take when loading our
project group indicate a problem with our project architeture?
2. If there is a problem with our architecture, what changes should we make?
3. Will our planned dot net conversion affect this arcitecture problem
positively or negatively?

I would be grateful for any information anyone has to offer. Thank you very
much for your time.
Nov 20 '05 #1
  • viewed: 5423
Share:
7 Replies
* "George Copeland" <vb***@DELETETHIStechie.com> scripsit:
[...]

Your question is not related to VB.NET programming, so please don't post
to groups that are not related to the question.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #2
George Copeland wrote:

"Could not create reference '<path to dll>'."


About the only thing I can suggest is to open the VBG file in notepad
and make sure the EXE project gets loaded last. At least that way, all
dll projects should be loaded by the time the EXE starts looking for
references. I've never tried debugging DLLs from 2 separate instances of
VB. btw... make sure you're registry is kept clean! Run RegClean if you
don't have commercial cleaners available.

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..
Nov 20 '05 #3
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:ec**************@TK2MSFTNGP09.phx.gbl...
About the only thing I can suggest is to open the VBG file in notepad
and make sure the EXE project gets loaded last. At least that way, all
dll projects should be loaded by the time the EXE starts looking for
references. I've never tried debugging DLLs from 2 separate instances of
VB. btw... make sure you're registry is kept clean! Run RegClean if you
don't have commercial cleaners available.


Thanks, I already know I can change the behavior by loading the projects in
different orders. I'm not sure about the reg cleaner idea: MS no longer
supports regclean so it worries me, and I have yet to find a commercial one
that is worth a flip.
Nov 20 '05 #4
George Copeland wrote:

Thanks, I already know I can change the behavior by loading the projects in
different orders. I'm not sure about the reg cleaner idea: MS no longer
That's why I usually add my 'RegClean Disclaimer' stuff when suggesting
RegClean... fwiw, I only know of one combination of OS/Office that
causes problems after RegClean's done it's work (listed in my disclaimer)

Subject: Re: DLL showing on the Project/reference in Visual Basic
http://groups.google.com/groups?selm...&output=gplain
supports regclean so it worries me, and I have yet to find a

commercial one that is worth a flip.

I like (and use) this one... I have their 'pro' version (with all of the
add-on's) but the registry cleaner part is identical to the "non-pro"
version. I still use RegClean for quick cleans though. It targets only
the part of the registry that deals with activeX components so it's quick.

System Mechanic
http://www.iolo.com/sm/4/index.cfm

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..
Nov 20 '05 #5
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:uM**************@TK2MSFTNGP12.phx.gbl...
I like (and use) this one... I have their 'pro' version (with all of the
add-on's) but the registry cleaner part is identical to the "non-pro"
version. I still use RegClean for quick cleans though. It targets only
the part of the registry that deals with activeX components so it's quick.

System Mechanic
http://www.iolo.com/sm/4/index.cfm


Thanks a million for the info and reference.
Nov 20 '05 #6
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:c6************@ID-208219.news.uni-berlin.de...
Your question is not related to VB.NET programming, so please don't post
to groups that are not related to the question.


Apparently you didn't read my post. Try again.
Nov 20 '05 #7
* "George Copeland" <vb***@DELETETHIStechie.com> scripsit:
Your question is not related to VB.NET programming, so please don't post
to groups that are not related to the question.


Apparently you didn't read my post. Try again.


Sure, I read it.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Jones | last post: by
49 posts views Thread by Martin Unsal | last post: by
2 posts views Thread by suneelid2000@gmail.com | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.