vb6 command line build option(s?)

[sloan]

I think I know the answer to this question before I ask, but I'll ask.

I have one VB6 app that I'm trying to put into our Continuous Integration
(CI) environment, which is on a dedicated "build machine".

It looks like the command line way for building a vbp is like this:

"C:\Program Files\Microsoft Visual Studio\Vb98\Vb6.exe" /MAKE "C:\VB
Tools\Project1.vbp"

Which means (if I want to build on a "build machine") that I have to bust
out the CD's and install the VB6 development environment on the build
machine.

...........

Is vb6.exe /MAKE the ONLY way to compile a vbp from the command line?
(<<This is the question for which I think I know the answer).

But confirmation would be appreciated..................

My only request, please only reply if you have some knowledge about this,
and not just guesses.

Thank you....................................

[Nobody]

Post by sloan
Is vb6.exe /MAKE the ONLY way to compile a vbp from the command line?
(<<This is the question for which I think I know the answer).

You could try replacing C2.EXE with your own EXE that shows the command line
passed to it by VB6.EXE. You also need LINK.EXE. I have not tried this, so I
am not sure it will work. Even if you find out the command lines, they might
change if anything changed in the VBP file. This is undocumented and use at
your own risk approach.

[Tom Shelton]

Post by Nobody

Post by sloan
Is vb6.exe /MAKE the ONLY way to compile a vbp from the command line?
(<<This is the question for which I think I know the answer).

You could try replacing C2.EXE with your own EXE that shows the command line

Actually, it does work :) I did this a long time ago for a personal addin I
did to add some extra command line arguments to the build process. I wonder
if I still have that code somewhere :)

[sloan]

If you had it, that would rock.................

Post by Tom Shelton

Post by Nobody

Post by sloan
Is vb6.exe /MAKE the ONLY way to compile a vbp from the command line?
(<<This is the question for which I think I know the answer).

You could try replacing C2.EXE with your own EXE that shows the command line

Actually, it does work :) I did this a long time ago for a personal addin I
did to add some extra command line arguments to the build process. I wonder
if I still have that code somewhere :)
--
Tom Shelton

[unknown]

Hello,

Post by sloan
If you had it, that would rock.................

I did this a long time ago for a personal addin I did to add some extra
command line arguments to the build process.

Also telling explicitely the overall goal could help. For now my
understansding is that you would like to compile your VB project without
having to install the VB6 IDE on your build server which is not exactly the
same thing than "just" hooking into the compilation process...

I remember to have seen once :
https://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=24616&lngWId=1
(Take Control of the Compiler for VB5 and VB6)

From the companion PDF it seems that the "Generate Project Object Module" is
done by VB itself...

Similarly the Nant task for VB6
(http://nantcontrib.sourceforge.net/release/0.85-rc2/help/tasks/vb6.html)
seems to use VB6.exe. I came accross also
http://www.codeplex.com/MSBuildExtensionPack during my search but didn't
bother to install to see how the VB6 task (which seems to be mentioned on
the project home page) is done...

--
Patrice

[sloan]

Yeah, http://www.codeplex.com/MSBuildExtensionPack is just a nicely wrapper
piece for vb6.exe
http://www.msbuildextensionpack.com/help/3.5.5.0/html/5e5f513d-1347-0560-e804-6dd9c64052d7.htm

(see VB6Path property under the htm page above)........



But that is the goal. Build vbp projects without having to install the dev
environment.

I'll check the out the other items you mention as well.

Post by unknown
Hello,

Post by sloan
If you had it, that would rock.................

I did this a long time ago for a personal addin I did to add some extra
command line arguments to the build process.

Also telling explicitely the overall goal could help. For now my
understansding is that you would like to compile your VB project without
having to install the VB6 IDE on your build server which is not exactly
the same thing than "just" hooking into the compilation process...
https://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=24616&lngWId=1
(Take Control of the Compiler for VB5 and VB6)
From the companion PDF it seems that the "Generate Project Object Module"
is done by VB itself...
Similarly the Nant task for VB6
(http://nantcontrib.sourceforge.net/release/0.85-rc2/help/tasks/vb6.html)
seems to use VB6.exe. I came accross also
http://www.codeplex.com/MSBuildExtensionPack during my search but didn't
bother to install to see how the VB6 task (which seems to be mentioned on
the project home page) is done...
--
Patrice

[Tom Shelton]

Post by sloan
Yeah, http://www.codeplex.com/MSBuildExtensionPack is just a nicely wrapper
piece for vb6.exe
http://www.msbuildextensionpack.com/help/3.5.5.0/html/5e5f513d-1347-0560-e804-6dd9c64052d7.htm
(see VB6Path property under the htm page above)........
But that is the goal. Build vbp projects without having to install the dev
environment.

Like Ralph said - I don't think that's possible...

[Karl E. Peterson]

Post by Tom Shelton

Post by sloan
But that is the goal. Build vbp projects without having to install the dev
environment.

Like Ralph said - I don't think that's possible...

It may be possible, but to prove what point?

Where's the ROI in such an effort?

[Tom Shelton]

Post by Karl E. Peterson

Post by Tom Shelton

Post by sloan
But that is the goal. Build vbp projects without having to install the dev
environment.

Like Ralph said - I don't think that's possible...

It may be possible, but to prove what point?
Where's the ROI in such an effort?

I don't think there would be any return at all - you would probably be in
the negative, with all the reverse engineering etc. :)

[Karl E. Peterson]

Post by Tom Shelton

Post by Karl E. Peterson

Post by Tom Shelton

Post by sloan
But that is the goal. Build vbp projects without having to install the
dev environment.

Like Ralph said - I don't think that's possible...

It may be possible, but to prove what point?
Where's the ROI in such an effort?

I don't think there would be any return at all - you would probably be in
the negative, with all the reverse engineering etc. :)

Zactly what I was thinking... And I just don't see the downside of
doing the bare minimum install.

[sloan]

Well, when we started up our CI environment, there was a requirement

"No developer tools on the build machine".

That is when all the builds were DotNet 2.0 Framework (or later).

One of the reasons (among several), is that it forced developers to think
about dependancies and redistributables (BEFORE D-Day, where D-Day is
Deployment day).

........

This actually has benefit, not just in theory,

The most recent one was (that actually happened)

http://www.microsoft.com/downloads/details.aspx?familyid=75FEF59F-1B5E-49BC-A21A-9EF4F34DE6FC&displaylang=en
Microsoft Synchronization Services for ADO.NET
And the files:
Microsoft.Synchronization.Data.SqlServerCe.dll
Microsoft.Synchronization.Data.Server.dll
Microsoft.Synchronization.Data.dll


On a developer box, these files were "just there". On the build machine,
they were not.


So once the build broke, we were able to find the redistibutable, and also
make sure it was legal to send these files out.
Again, it is not just referencing the files, its making sure its cool to
redistribute them.

It gave us advanced warning on which dll's might be auto-referenced.

I think in this case, it was adding a "Reporting : Report" (rdlc) file.
When the rdlc was added, it auto-referenced the above dll's.

In the end, we were able to remove the references, and it did not affect our
rdlc. Aka, they were unneeded references all along.


This is the advantage of having a dedicated build box, without the dev
environment.

Which was what I was hoping for in VB6 ..... for this lone leftover project
we have.

...........

I agree, the effort it would take to write/work-out a alternative to vb6.exe
would be nutso..................(based on the information gained from this
valuable thread and feedback from others).

...........

But not having dev environment tools on the build box is
beneficial..............IMHO.

Post by Tom Shelton

Post by Karl E. Peterson

Post by Tom Shelton

Post by sloan
But that is the goal. Build vbp projects without having to install the dev
environment.

Like Ralph said - I don't think that's possible...

It may be possible, but to prove what point?
Where's the ROI in such an effort?

I don't think there would be any return at all - you would probably be in
the negative, with all the reverse engineering etc. :)
--
Tom Shelton

[Karl E. Peterson]

Post by sloan
One of the reasons (among several), is that it forced developers to think
about dependancies and redistributables (BEFORE D-Day, where D-Day is
Deployment day).

Good reason. I think that by doing the absolute bare minimum install
with VB6, you can come close. You'll get the runtime, of course, but
that shouldn't matter because, well, because. <g> And possibly a
couple of others. You could probably document them fairly well by
firing up filemon before the install. Just ruthlessly uncheck
everything you can during the setup.

[Ralph]

Post by sloan
Which was what I was hoping for in VB6 ..... for this lone leftover project
we have.
But not having dev environment tools on the build box is
beneficial..............IMHO.

Of course it is.

Including the "Visual Basic Windows Development" product doesn't preclude
being able to *build* a project from the command line from a VB Project
Source files without any "runtime" components available at compile time. You
only need a few basic components to compile. (As someone else suggested - a
'limited' install.)

Don't confusing 'running' a VB Project with 'compiling' a VB Project.

Also consider that at some point you will need to consider how you are going
to go about building "install" packages, and/or maintain component
dependancies. So eventually any CI project will include backing up the
compilers and additional components, resources, etc.

-ralph

[Nobody]

Post by sloan
One of the reasons (among several), is that it forced developers to think
about dependancies and redistributables (BEFORE D-Day, where D-Day is
Deployment day).

Off topic:

Why not use Virtual PC or VMware Server? Both are free. The advantage over a
separate PC is that you can do a clean install of any OS, then save it as a
template so you don't have to reinstall the OS again to perform a "clean
install". You can "restore" to a clean OS install in under a
minute(depending on file size) and retest your installer and software. You
can also enable "Undo Disks" so you start from the clean install, test your
software, then close the VM and choose to discard the changes. This leaves
the OS at the clean install state. You can't do that with dedicated box
easily. You can even create multiple duplicates with various service packs
installed or different configurations. Each "PC" or VM is nothing more than
2 or 3 files that you can backup or restore as you wish, or use as template.

VMware Server advantage over Virtual PC is that it supports 64 Bits guest
OS, even if the host OS is 32 Bits. Virtual PC doesn't support 64 Bits
guests, but works on 64 Bits hosts, and supports only 32/16 Bits guests.
Also, VMware Server interface is web based with browser plug-in, so you can
use a different machine and not slow down your own machine.

These two products don't come with any OS'es so you need the CD/DVD or ISO
file to install the OS that you want. Both of these products support ISO
files, so there is no need to burn CD's/DVD's first.

Links:

http://en.wikipedia.org/wiki/VMware_Server
http://en.wikipedia.org/wiki/Microsoft_Virtual_PC

[Ralph]

Post by unknown
Hello,
Also telling explicitely the overall goal could help. For now my
understansding is that you would like to compile your VB project
without having to install the VB6 IDE on your build server which is
not exactly the same thing than "just" hooking into the compilation
process...

https://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=24616&lngWId=1

Post by unknown
(Take Control of the Compiler for VB5 and VB6)
From the companion PDF it seems that the "Generate Project Object
Module" is done by VB itself...

I went looking for this link before I posted, but couldn't find it.

The author is basically correct about VB Object modules, but left out a
step - VB's conversion of 'source files' into pcode. Understandable as he
was only interested in capturing the compiling of a VB project into native
code, and it is only with native code that the Ten Tasks he listed are
possible.

This is necessary in understanding why VB6.exe is important in managing VB
source files, and especially as it pertains to a "Continous Integration"
development practice. While I wouldn't go so far as the author in calling
Visual Basic "not a true language", he is correct that what we commonly
think of as the "Visual Basic" language doesn't exists except as an
interactive device to communicate with the VB Parser/Editor.

When a 'text' source file is 'opened' in the IDE the file is immediately
parsed and converted to pcode. This pcode is cached and stored in memory
(though has a 'disk' presences in the temp folders. The characters you see
in the editor are an artifact of the source file. In fact the pcode contains
two representations of every line from the loaded source file - a pcode
representation and a 'display' line. (As well as a ton of extra lines,
tables, etc.)

Imagine for a moment a programming language with both a pcode statement
and then a comment on that statement, and an editor that merely showed the
'comments". Anytime you changed the 'comment' the editor would parse it and
create a new pcode statement/s tables updates/changes, and update the
'comment'.

That's how VB works.

Actually VB does another step as well, initial source is converted to
"opcode-pcode" which is then further massaged into "excode-pcode". It is the
"excode" type of pcode which is run when you 'debug' inside the IDE, and
opcode which is run in the intermediate mode - but I digress.)

[Note: The terms "opcode", "excode", "pcode", have all been hijacked from
other technologies, just like VB's hijacking of "object files". The all have
very different meanings elsewhere.]

When you compile to native code, VB converts its 'internal' pcode (excode)
into 'C', ie, not the source files. They are never looked at again. You can
only get pcode by loading a source file into VB6.exe.

In setting up Continous Integration you first and foremost want to set up a
Source Code repository. Having a programmer always convert his changes to an
almost unreadable (to the untrained eye) intermediate format, instead of the
'human' readable source, for checking in, is too great a burden - it is
going to go wrong. <g>

-ralph

[sloan]

Sounds like building vbp projects without vb6.exe is like trying to scratch
your back by reaching between legs.

csc.exe
msbuild.exe
javac

Basically, there is no VB6 equivalent of these type of executables. And
installing the dev environment is the only practical method.

:<

Thanks for all the information (from everyone).

Mainly I wanted to confirm my suspicion, which I have done.

Post by unknown

Post by unknown
Hello,
Also telling explicitely the overall goal could help. For now my
understansding is that you would like to compile your VB project
without having to install the VB6 IDE on your build server which is
not exactly the same thing than "just" hooking into the compilation
process...

https://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=24616&lngWId=1

Post by unknown
(Take Control of the Compiler for VB5 and VB6)
From the companion PDF it seems that the "Generate Project Object
Module" is done by VB itself...

I went looking for this link before I posted, but couldn't find it.
The author is basically correct about VB Object modules, but left out a
step - VB's conversion of 'source files' into pcode. Understandable as he
was only interested in capturing the compiling of a VB project into native
code, and it is only with native code that the Ten Tasks he listed are
possible.
This is necessary in understanding why VB6.exe is important in managing VB
source files, and especially as it pertains to a "Continous Integration"
development practice. While I wouldn't go so far as the author in calling
Visual Basic "not a true language", he is correct that what we commonly
think of as the "Visual Basic" language doesn't exists except as an
interactive device to communicate with the VB Parser/Editor.
When a 'text' source file is 'opened' in the IDE the file is immediately
parsed and converted to pcode. This pcode is cached and stored in memory
(though has a 'disk' presences in the temp folders. The characters you see
in the editor are an artifact of the source file. In fact the pcode contains
two representations of every line from the loaded source file - a pcode
representation and a 'display' line. (As well as a ton of extra lines,
tables, etc.)
Imagine for a moment a programming language with both a pcode statement
and then a comment on that statement, and an editor that merely showed the
'comments". Anytime you changed the 'comment' the editor would parse it and
create a new pcode statement/s tables updates/changes, and update the
'comment'.
That's how VB works.
Actually VB does another step as well, initial source is converted to
"opcode-pcode" which is then further massaged into "excode-pcode". It is the
"excode" type of pcode which is run when you 'debug' inside the IDE, and
opcode which is run in the intermediate mode - but I digress.)
[Note: The terms "opcode", "excode", "pcode", have all been hijacked from
other technologies, just like VB's hijacking of "object files". The all have
very different meanings elsewhere.]
When you compile to native code, VB converts its 'internal' pcode (excode)
into 'C', ie, not the source files. They are never looked at again. You can
only get pcode by loading a source file into VB6.exe.
In setting up Continous Integration you first and foremost want to set up a
Source Code repository. Having a programmer always convert his changes to an
almost unreadable (to the untrained eye) intermediate format, instead of the
'human' readable source, for checking in, is too great a burden - it is
going to go wrong. <g>
-ralph

[mayayana]

Post by sloan
If you had it, that would rock.................

Like Patrice, I'm not clear on which you
want to do...and I see that you take
a dim view of guesses. :)

If you want to hook into compilation
see here:
http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html

It's an article about building a standard DLL
in VB, including a method to set up a dummy
link.exe so that one can edit the command line
before compiling.

[Ralph]

Post by Nobody

Post by sloan
Is vb6.exe /MAKE the ONLY way to compile a vbp from the command line?
(<<This is the question for which I think I know the answer).

You could try replacing C2.EXE with your own EXE that shows the command line
passed to it by VB6.EXE. You also need LINK.EXE. I have not tried this, so I
am not sure it will work. Even if you find out the command lines, they might
change if anything changed in the VBP file. This is undocumented and use at
your own risk approach.

It won't work. (At least without a ton of major effort*. <g>)

In the 'compile' cycle c2.exe is passed ".obj" files which are created by
VB6.exe (and its components). Note: these ".obj" files are not the same as
those created by other platforms - ie, they are not compiled computer
instructions in a machine code format that can be later linked together to
create a finnished product, rather they are highly proprietory preprocessed
'C' source files.

You would have to have each VB Programmer that made changes to any modules
to then compile against a fake C2.exe as NoBody suggested. This fake C2
would then capture the command line and halt - allowing the programmer to
also capture the generated VB .obj files. The VB programmer could then store
these .obj files and the command line to a SCCS or other storage to be built
later. Exiting the fake C2 may or may not invoke VB6.exe to delete the .obj
files. In any case you have to insure they are not there when you run VB6
again.

The only practical solution is to install the VB6 development platform on
the build box.

-ralph