G
George Copeland
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.aspx?scid=kb;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.
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.aspx?scid=kb;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.