| Author |
How can I abort a lengthy compile?
|
|
| Brad Ashforth 2005-11-22, 6:55 pm |
| We have a project that can take upwards of 10 minutes to compile (yes, a LOT
of large modules). Is there a way to abort the compile once it has started?
I've tried CTRL-Break and CTRL-C with no success.
Thanks
--
Brad Ashforth
| |
| Michael C 2005-11-22, 6:55 pm |
| "Brad Ashforth" <banospam@nospam.nospam> wrote in message
news:89969D29-CF2A-4F95-89D3-BD1D7D98FABD@microsoft.com...
> We have a project that can take upwards of 10 minutes to compile (yes, a
> LOT
> of large modules). Is there a way to abort the compile once it has
> started?
> I've tried CTRL-Break and CTRL-C with no success.
> Thanks
Go to task manager and terminate the C2 task, vb will report an error. The
more elegant option is rename C2.exe to, say, C3.exe. Then write a very
small vb exe with no forms that when run will run C3.exe (passing on command
line args) and call this exe c2.exe. Have this exe check for a certain
unusual key combination and terminate. You might have to work out how to
return a non zero retrurn code from vb but I'm pretty sure that's possible.
The reason we did this with C2 was to work out why our app was taking so
long to compile so we had our app write a log file of the command line args
sent to C2 and the time it took to call C2 for each module. It turned out to
be an overuse of UDTs or very large modules (or was it large functions?) was
causing the problem. Maybe you should move some of your code to a dll so
it's not compiled each time.
Regards,
Michael
| |
| Brad Ashforth 2005-11-22, 6:55 pm |
| Believe it or not, we have already moved most of our "reusable" or generic
code to DLLs ... several of them. I am sure that we could move more, I'll
present this suggestion to the System Architect.
Thank you ...
--
Brad Ashforth
"Michael C" wrote:
> "Brad Ashforth" <banospam@nospam.nospam> wrote in message
> news:89969D29-CF2A-4F95-89D3-BD1D7D98FABD@microsoft.com...
>
> Go to task manager and terminate the C2 task, vb will report an error. The
> more elegant option is rename C2.exe to, say, C3.exe. Then write a very
> small vb exe with no forms that when run will run C3.exe (passing on command
> line args) and call this exe c2.exe. Have this exe check for a certain
> unusual key combination and terminate. You might have to work out how to
> return a non zero retrurn code from vb but I'm pretty sure that's possible.
>
> The reason we did this with C2 was to work out why our app was taking so
> long to compile so we had our app write a log file of the command line args
> sent to C2 and the time it took to call C2 for each module. It turned out to
> be an overuse of UDTs or very large modules (or was it large functions?) was
> causing the problem. Maybe you should move some of your code to a dll so
> it's not compiled each time.
>
> Regards,
> Michael
>
>
>
| |
| Peter Huang [MSFT] 2005-11-23, 3:55 am |
| Hi
Thanks for your knowledge sharing.
Also I think it is a good practice to divide a large project into a few
smaller projects(dll projects), because it is not proper to rebuild all the
large project even when you do tiny change.
Best regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
| |
| Michael C 2005-11-23, 3:55 am |
| "Brad Ashforth" <banospam@nospam.nospam> wrote in message
news:F5F84980-D026-4BEF-8FAA-5BB14EE34CC1@microsoft.com...
> Believe it or not, we have already moved most of our "reusable" or generic
> code to DLLs ... several of them. I am sure that we could move more, I'll
> present this suggestion to the System Architect.
I just did a count with my app and was suprised to find it's seperated into
24 projects. I would have guessed at 10 :-)
Michael
| |
| Brad Ashforth 2005-11-23, 6:55 pm |
| Our app also comprises of itself (of course) and 20 other projects (DLL). At
this point the "main" app is just very large and really doesn't have any
logical separations. But thanks for the input. If you have suggestions how to
break such a large project (without logical separations) into smaller
projects please let me know.
Thanks
--
Brad Ashforth
"Michael C" wrote:
> "Brad Ashforth" <banospam@nospam.nospam> wrote in message
> news:F5F84980-D026-4BEF-8FAA-5BB14EE34CC1@microsoft.com...
>
> I just did a count with my app and was suprised to find it's seperated into
> 24 projects. I would have guessed at 10 :-)
>
> Michael
>
>
>
| |
|
|
"Brad Ashforth" <banospam@nospam.nospam> wrote in message
news:1E000AB2-D906-4941-A0EA-BC5DF6E96270@microsoft.com...
> Our app also comprises of itself (of course) and 20 other projects (DLL).
At
> this point the "main" app is just very large and really doesn't have any
> logical separations. But thanks for the input. If you have suggestions how
to[color=darkred]
> break such a large project (without logical separations) into smaller
> projects please let me know.
>
> Thanks
> --
> Brad Ashforth
>
>
> "Michael C" wrote:
>
generic[color=darkred]
I'll[color=darkred]
into[color=darkred]
"Refactoring: Improving the Design of Existing Code", Martin Fowler
| |
| J French 2005-11-23, 6:55 pm |
| On Wed, 23 Nov 2005 06:26:13 GMT, v-phuang@online.microsoft.com
("Peter Huang" [MSFT]) wrote:
>Hi
>
>Thanks for your knowledge sharing.
>Also I think it is a good practice to divide a large project into a few
>smaller projects(dll projects), because it is not proper to rebuild all the
>large project even when you do tiny change.
Hmm...
DLLs are very useful
- their original purpose was to share code space
A nice by product was 'plugins'
- not a new concept
AX DLLs are the spawn of the Devil
We would be a lot better off working with .OBJ and .LIB files
- or perhaps the CBASIC linking of OVLs
| |
| Brad Ashforth 2005-11-23, 6:55 pm |
| Thanks Ralph! Looks like good reading.
--
Brad Ashforth
"Ralph" wrote:
>
> "Brad Ashforth" <banospam@nospam.nospam> wrote in message
> news:1E000AB2-D906-4941-A0EA-BC5DF6E96270@microsoft.com...
> At
> to
> generic
> I'll
> into
>
>
> "Refactoring: Improving the Design of Existing Code", Martin Fowler
>
>
>
>
| |
|
|
"Brad Ashforth" <banospam@nospam.nospam> wrote in message
news:9586CA3E-4636-47E9-9500-0F99CA88199C@microsoft.com...[color=darkred]
> Thanks Ralph! Looks like good reading.
> --
> Brad Ashforth
>
>
> "Ralph" wrote:
>
(DLL).[color=darkred]
any[color=darkred]
how[color=darkred]
more,[color=darkred]
seperated[color=darkred]
As a plus (or minus depending on view), when it comes to porting a VBc
application to .net, you will find that in most cases it is *easier* to
refactor VBc code to something more portable, than mangling .net code to fit
VBc.
-ralph
[*easier* is a very relative term when it comes to VBc to VB.net
conversions. <g>]
| |
| Michael C 2005-11-23, 6:55 pm |
| "Brad Ashforth" <banospam@nospam.nospam> wrote in message
news:1E000AB2-D906-4941-A0EA-BC5DF6E96270@microsoft.com...
> Our app also comprises of itself (of course) and 20 other projects (DLL).
> At
> this point the "main" app is just very large and really doesn't have any
> logical separations. But thanks for the input. If you have suggestions how
> to
> break such a large project (without logical separations) into smaller
> projects please let me know.
Unfortunately I don't have any suggestions as I've got the same problem.
While lots of code is seperated into different projects I still put all the
forms into the one. VB6 doesn't work well with forms in dlls so there's not
a lot of alternative I don't think.
Michael
| |
| Schmidt 2005-11-27, 7:55 am |
|
"Michael C" <nospam@nospam.com> schrieb im Newsbeitrag
news:evtLUTI8FHA.3660@TK2MSFTNGP09.phx.gbl...
> "Brad Ashforth" <banospam@nospam.nospam> wrote in message
> news:1E000AB2-D906-4941-A0EA-BC5DF6E96270@microsoft.com...
(DLL).[color=darkred]
how[color=darkred]
>
> Unfortunately I don't have any suggestions as I've got the same problem.
> While lots of code is seperated into different projects I still put all
the
> forms into the one. VB6 doesn't work well with forms in dlls so there's
not
> a lot of alternative I don't think.
In our larger projects we put our GUI-Logic into OCX-Control-"Forms" and
load them at runtime into generic Standard- or MDI-Child-Forms.
So the "Main-Project" is only a universal "Container-App" with Code for
Auto-Updates and with Instantiation-Mechanisms (Factory-Classes) for visual
(OCX) and non-visual (AX-Dll) Components.
Olaf
|
|
|
|