Click to See Complete Forum and Search --> : Command line compiling problem


Johnny101
March 13th, 2001, 02:49 PM
I've been working on an auto-build application. Everything's been going fine until
recently. I've been testing my auto-build process with an app that is fairly
complicated. Here's the layout:

DLL
Data Access - No Transaction Support
DLL
Data Access - With Transaction Support
DLL
Business Process and Data Validation - uses the two data access DLL's
DLL
Reporting Procedures - uses the business processes DLL
EXE
Uses the reporting procedures and business processes DLL's



All the DLL's are being compiled just fine, but when i come to the EXE it fails,
saying "No Public Createble Object Found". But, when i open the vbp with the VBIDE
and compile - it works just fine. All the GUID's are managed correctly and they are
updated in the VBP if they changed with the latest compile. So, i dont think it's a
reference problem.

In a nutshell - compiling with the UI works, but when called from the command line
it doesn't.

Any and all ideas are welcome.

Thanks,

John


John Pirkey
MCSD
http://www.ShallowWaterSystems.com
http://www.stlvbug.org

Dave Sell
May 30th, 2001, 05:15 PM
Jonny,

I am glad to see I am not the only one in the world trying this!

I also am required to compile a complicated project via command-line, no gui.

I am having problems with my reference line for a .ocx.

While I don't have an answer to your problem, answer me this: are you MOVING the files AFTER you created them in the gui?

I ask because I am baffled by this line in my DllProject.vbp:

Reference=*\G{98D52180-D01C-11CF-BA98-444553540000}#1.0#0#..\..\..\WINNT.0\Vbcostar.ocx#CoSTAR OLE Control module

which references a relative path that is actually invalid after I move it.

Have you found any refernces (online) regarding manually editing the project file?

Keep in mind my whole project compiles without a hitch on my gui machine.

My actual error is a bit different than yours (right now). Mine is:

Compile Error in File 'C:\Work\Dll\cPFWCI.cls', Line 8 : Can't find project or library

Let me know what you have found and I will keep posting my successes here.

Thanks,

Dave

Note the 'recent' new prefix standards for Information Technology Experts.
http://helios.augustana.edu/~dr/kibibytes.html

Johnny101
May 30th, 2001, 05:31 PM
Well, i did get past that point, but i cheated. I was informed of a third party product that did this sort of thing. It's called VB-Build (http://www.vb-build.com). It's pretty cheap (on a company's budget anyway - like $150). But it did everything and more than we needed. For example, it integrates with Microsoft Visual SourceSafe (Getting latest version, check in, checkout). It can determine the build order automatically and if it doesn't, then you set it manually. It is very easy to use and it works well.

Your error happens because that line in the vbp that references something that has been recompiled and the vbp hasn't been updated with the latest GUID for that object. I found an article in the VBPJ archives that i was using as a roadmap (before i found VB Build) that talked about doing automatic builds. The author found an object that allows you to get these new GUIDs from registry (the TypeLib Information reference). I can give you the month and column of the article if you want. But to get at it you have to be a member of the DevX Premier Club (like $3/mo). Anyway, his approach worked fairly well. But for some reason, i was having problems with it correctly updating the GUID. Although, if you're not changing the interface and you have binary compatibility set these GUID shouldn't change so the existing VBP should be okay (theoretically).

good luck,

john

John Pirkey
MCSD
http://www.ShallowWaterSystems.com
http://www.stlvbug.org

Dave Sell
May 31st, 2001, 08:54 AM
Hi John,


I have gotten past referencing .dll's in a .vbp, but now the.ocx's won't load. I feel like I cheated also. Here's what I did:

I changed this line:
Reference=*\G{420B2830-E718-11CF-893D-00A0C9054228}#1.0#0#C:\WINNT\System32\scrrun.dll#Microsoft Scripting Runtime

To this line:
Reference=C:\WINNT\System32\scrrun.dll

I am able to compile my .dll now, but I am now trying to compile my .ocx's. They have a line like this:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX

Which I change to this:
Object=MSCOMCTL.OCX

I basically just dropped the MSCOMCTL.OCX file in the same dir as the .vbp. The compilation process will reference any .dll's (when I chop off the GUID), but I get an error when referencing an object in the same way. This is my new error:
'MSCOMCTL.OCX' could not be loaded

If I can get my .ocx to build I am pretty much done, so I would rather not use a 3rd party system, although it does sound very nice.

Could you send me more information about the article which you mention 'in the VBPJ archives', (whatever that is ;)?

I am sure I could swing the DevX Premier Club (at $3/mo).

Thanks and best of luck to you!

Dave

Note the 'recent' new prefix standards for Information Technology Experts.
http://helios.augustana.edu/~dr/kibibytes.html

Johnny101
May 31st, 2001, 09:20 AM
The article was in the December 2000 VBPJ - it was a Feature entitled "Take Control of the Build Cycle". so, no specific column. This is recent enough that its possible one of your coworkers may still have it lying around. As for the DevX.com's premier club, I think it's a good idea to join. Having access, from anywhere, to the entire history of the magazine is great. Their search engine for specific articles could be a little better though.

Hope this helps - and good luck.

john

John Pirkey
MCSD
http://www.ShallowWaterSystems.com
http://www.stlvbug.org