Improvements needed in the area: References / Installation Problems

[Peter Skouhus]

References / Installation Problems


Does anybody know what Microsoft has done to address the problems we are
faced with when we compile/deploy large VB projects.

We have two projects 175,000 + lines of code each. Each project has some 20
or so DLL's and we have a "curse" hanging over us when we compile.
We must take great care in compiling the components in the right order. If
we don't, the program will not run, or objects can not be created etc.
Also, often reference goes missing or change themselves from a project file
to a DLL or visa versa during compilation for no apparent reason.

We think it would be nice if Microsoft would:

a) Make it possible to set the order of component compilation so that a
complete project can be compiled unattended.
b) Make sure that when references has been set once, then they stay until
the developer change them.
c) Automatically generate a list of all the components that are needed in a
project. (a nice list with version number etc to be used when making setup
files, maybe even include the location on the computer where the files are
that are needed)


Any way, these are my thoughts.


Peter Skouhus
Manila, Philippines

[Phil Weber]

> Does anybody know what Microsoft has done to address
> the problems we are faced with when we compile/deploy
> large VB projects?

Peter: No (no one knows, at least no one who is free to discuss it).
---
Phil Weber

[Keith Franklin, MCSD]

Peter,

There is a solution...

Use COM Interfaces....

Have your DLL's Implement Interfaces and never reference a component only
reference interface typelibs.

Works like a charm...

Just takes a little getting use to the concept...

A DLL references a typelib (or typelibs) and Implements interfaces contained
within the typelib
Another DLL or EXE references the same typelib and Dim's objects as an
interface rather then the class name

Example:

DLL A References a typlib called DataBaseAccessInterfaces.tlb

Implements IDataBaseAccess

Private Function IDataBaseAccess_GetEmployeeData(ByVal EmpID as Long) as
ADODB.Recordset
' Do stuff here
End Function

Client EXE References the same typlib DataBaseAccessInterfaces.tlb

Sub Command1_Click()
Dim oDBA as IDataBaseAccess
Dim oRS as ADODB.Recordset
set oDBA = CreateObject("ExampleDBA.DataBaseAccess")
set oRS = oDBA.GetEmployeeData(100)

' Do something with the data
End Sub

Now I can have 50 components that all implement the IDataBaseAccess
interface...They all have diffrent GUIDs and I can just register any one of
them on the machine and this will work AOK...

So I never ever reference a component only interfaces to avoid the coupling
problem...

Later

"Peter Skouhus" <skouhus@1902software.com> wrote in message
news:3962d02c@news.devx.com...
> References / Installation Problems
>
>
> Does anybody know what Microsoft has done to address the problems we are
> faced with when we compile/deploy large VB projects.
>
> We have two projects 175,000 + lines of code each. Each project has some
20
> or so DLL's and we have a "curse" hanging over us when we compile.
> We must take great care in compiling the components in the right order.
If
> we don't, the program will not run, or objects can not be created etc.
> Also, often reference goes missing or change themselves from a project
file
> to a DLL or visa versa during compilation for no apparent reason.
>
> We think it would be nice if Microsoft would:
>
> a) Make it possible to set the order of component compilation so that a
> complete project can be compiled unattended.
> b) Make sure that when references has been set once, then they stay until
> the developer change them.
> c) Automatically generate a list of all the components that are needed in
a
> project. (a nice list with version number etc to be used when making
setup
> files, maybe even include the location on the computer where the files are
> that are needed)
>
>
> Any way, these are my thoughts.
>
>
> Peter Skouhus
> Manila, Philippines
>
>

[Adam Young]

">We must take great care in compiling the components in the right order.
If
>we don't, the program will not run, or objects can not be created etc.

You're right - this is a pain, but there's an easy way out. Use late binding
for your large distributed projects. Believe me, you won't notice a performance
drop. You can keep early binding for small scale server-side projects.

[Vlad Ivanov]

>Use late binding
>for your large distributed projects. Believe me, you won't notice a performance
>drop. You can keep early binding for small scale server-side projects.

Erm.. don't say that outloud. This is REALLY not something you want to do.
I can't add anything to the usual "don't ever use this" list of reasons -
it's everywhere, in books, magazines, web. But there's a very good reason
why not. And one day you risk to discover it. Especially on large muti-component
project. Especially if you have to periodically update the "production" installation.

The interface method mentioned before is the one i ally with. Very effective
and in many cases problem free. The only thing it requires knowledge of IDL
(which i for example don't have). But you can use pure interface classes.
Just create a DLL with each class containing only defintions of methods.
Compile it to binary compatibility, and you're set. Also never modify your
interfaces (even though help says that you can and certain cases). You're
better off creating a new interface class and defining a secondary interface
that you can implement.

Follow this - and you won't have problems.

[Peter Skouhus]

Hi,

Thanks for the answers. Now, I'm sure that there are work around for the
problems I described. The point is that many times when one do things the
way Microsoft explains it in the manual / online help it leads to nowhere.
One can easily loos many valuable working horus becaus of this.

One gets the impressions that Microsoft, or at least the people at MS
writing manuals doesn't know how it works themselves sometimes. Why doesn't
Microsoft explain things the way it will work? I have programmed VB for
about 3 years, and especially in the beginning I was faced with an armada of
problems because things did not work the way it was explained in the
documentation, or it was explained in a manner that a PHD was required to
understand it.

Here is a suggestion to Microsoft:

Teach your documentation authors how things works in VB, but don't use a
"clean test lab" for that. Get them to write programs using the technology
they are about to document so they really understands it 100%.

Then:
a) Explain things right in your help.
or
b) Fix the problem(s) in the software so that it works the way you explained
it in your help.

I have a small software company with 7 employees, and we have wasted
considerably resources on these and other problems because the documentation
was extremely poor or even non existing. We had to at times use trail and
error to figure out how things really works. More documentation with easy
examples THAT WORKS EVERY TIME you try to use them would help many
developers in their day to day work. Especially when learning a new
technology. Remember, that the principles behind the technologies are
usually easy to understand and apply, but if one can not find somethings
that explains it well, then these technologies can be very difficult to
understand.

Beside that, what is the point of having a feature like "Make Project Group"
if that feature doesn't work, or only work in a clean test lab under the
best conditions.


Are there others who see things the way I do?


Peter

[Mark Burns]

Peter, I do.

I have a favorite example of exactly that kind of MS-F***up you are
describing.
In Office 97 if you wished to programatically manipulate a shape objects in
a Word/Excel document, you had to manipulate the node objects. There was
even a nifty example on the online docs on how to do this.
There was only SEVERAL problems with this:
If you did not follow PRECISELY the onlne docs, you could NOT get a return
from the nodes object without generating a type error! Why? Because unless
you disregarded all such "safe" programming conventions as "option explicit"
or if you declared your variables before using them, the object property
failed to work - because it took advantage of the (then-undocumented)
VB6-era ability to return an array from a function and assign it to a
variant *but only if the variant variable was previously undeclared*. I
pulled my hair out for almost two days before somebody pointed out that it
worked for them when they did EXACTLY what the docs showed and NOTHING MORE
in their code.
<GRrrrrrr!>

"Peter Skouhus" <skouhus@1902software.com> wrote in message
news:39642640@news.devx.com...
> Hi,
>
> Thanks for the answers. Now, I'm sure that there are work around for the
> problems I described. The point is that many times when one do things the
> way Microsoft explains it in the manual / online help it leads to nowhere.
> One can easily loos many valuable working horus becaus of this.
>
> One gets the impressions that Microsoft, or at least the people at MS
> writing manuals doesn't know how it works themselves sometimes. Why
doesn't
> Microsoft explain things the way it will work? I have programmed VB for
> about 3 years, and especially in the beginning I was faced with an armada
of
> problems because things did not work the way it was explained in the
> documentation, or it was explained in a manner that a PHD was required to
> understand it.
>
> Here is a suggestion to Microsoft:
>
> Teach your documentation authors how things works in VB, but don't use a
> "clean test lab" for that. Get them to write programs using the
technology
> they are about to document so they really understands it 100%.
>
> Then:
> a) Explain things right in your help.
> or
> b) Fix the problem(s) in the software so that it works the way you
explained
> it in your help.
>
> I have a small software company with 7 employees, and we have wasted
> considerably resources on these and other problems because the
documentation
> was extremely poor or even non existing. We had to at times use trail and
> error to figure out how things really works. More documentation with easy
> examples THAT WORKS EVERY TIME you try to use them would help many
> developers in their day to day work. Especially when learning a new
> technology. Remember, that the principles behind the technologies are
> usually easy to understand and apply, but if one can not find somethings
> that explains it well, then these technologies can be very difficult to
> understand.
>
> Beside that, what is the point of having a feature like "Make Project
Group"
> if that feature doesn't work, or only work in a clean test lab under the
> best conditions.
>
>
> Are there others who see things the way I do?
>
>
> Peter
>
>