I am writing what amounts to a "front-end" for XCopy to help some of
my less computer literate clients implement some sort of sensible
backup strategy. It sets up the XCopy command line in the Arguments of
a Process component, starts it, and them waits for it to finish. There
are a fair number of bells and whistles, but none of them are causing
problems.

I eventually had everything apparently running perfectly in the Debug
Build, so I created a Release Build for final testing on a second
system. I didn't get to the second system - the Release Build failed
on my development system! It appears that, in the Release Build, the
XCopy Process starts normally (no exceptions are thrown, and and an
immediate check of .HasExited returns False) but subsequently (and
very quickly) exits without doing any copying (but with an exit code
of zero). All other components of the program work in the same way in
the Release Build as they do in the Debug Build (i.e. properly!)

Has anyone seen anything like this before? Where do I start in trying
to sort it out?

Please respond to the Newsgroup, so that others may benefit from the exchange.
Peter R. Fletcher


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Are you attempting to access files/directories that are on a network
share? I have seen that cause similar issue. It is a permissions issue
if that is the case.

HTH

David

"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in
message news:(E-Mail Removed):
> I am writing what amounts to a "front-end" for XCopy to help some of
> my less computer literate clients implement some sort of sensible
> backup strategy. It sets up the XCopy command line in the Arguments of
> a Process component, starts it, and them waits for it to finish. There
> are a fair number of bells and whistles, but none of them are causing
> problems.
>
> I eventually had everything apparently running perfectly in the Debug
> Build, so I created a Release Build for final testing on a second
> system. I didn't get to the second system - the Release Build failed
> on my development system! It appears that, in the Release Build, the
> XCopy Process starts normally (no exceptions are thrown, and and an
> immediate check of .HasExited returns False) but subsequently (and
> very quickly) exits without doing any copying (but with an exit code
> of zero). All other components of the program work in the same way in
> the Release Build as they do in the Debug Build (i.e. properly!)
>
> Has anyone seen anything like this before? Where do I start in trying
> to sort it out?
>
> Please respond to the Newsgroup, so that others may benefit from the
> exchange.
> Peter R. Fletcher
>
>
> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
> News==----
> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
> Newsgroups
> ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption
> =---

I don't think this is the problem. The "source" folders are always on
local hard drives and I see the same behaviour (good and bad) when the
destination is a local floppy as when it is a logical network share (a
mapped folder on a local hard drive).

On Thu, 08 Jul 2004 14:34:38 -0700, David Williams , VB.NET MVP
<(E-Mail Removed)> wrote:

>Are you attempting to access files/directories that are on a network
>share? I have seen that cause similar issue. It is a permissions issue
>if that is the case.
>
>HTH
>
>David
>
>"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in
>message news:(E-Mail Removed):
>> I am writing what amounts to a "front-end" for XCopy to help some of
>> my less computer literate clients implement some sort of sensible
>> backup strategy. It sets up the XCopy command line in the Arguments of
>> a Process component, starts it, and them waits for it to finish. There
>> are a fair number of bells and whistles, but none of them are causing
>> problems.
>>
>> I eventually had everything apparently running perfectly in the Debug
>> Build, so I created a Release Build for final testing on a second
>> system. I didn't get to the second system - the Release Build failed
>> on my development system! It appears that, in the Release Build, the
>> XCopy Process starts normally (no exceptions are thrown, and and an
>> immediate check of .HasExited returns False) but subsequently (and
>> very quickly) exits without doing any copying (but with an exit code
>> of zero). All other components of the program work in the same way in
>> the Release Build as they do in the Debug Build (i.e. properly!)
>>
>> Has anyone seen anything like this before? Where do I start in trying
>> to sort it out?
>>
>> Please respond to the Newsgroup, so that others may benefit from the
>> exchange.
>> Peter R. Fletcher
>>
>>
>> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
>> News==----
>> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
>> Newsgroups
>> ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption
>> =---


Please respond to the Newsgroup, so that others may benefit from the exchange.
Peter R. Fletcher

I've written a lot of file-copy code and I haven't run into a problem where
there was a difference between the DEBUG and RELEASE build generated code
that caused such a problem, but there are a couple of things you can do to
make your life easier.

You can sprinkle Trace.WriteLine statements in your code and then run it
while DebugView is running. You could also call Console.WriteLine to output
directly to the console window. Either method works well for viewing runtime
info about the state of your app.

You can also change the settings of the release build so that it generates
debugging information. You can add a call to Debugger.Break in Main so that
it loads up the debugger so you can step through it.

Rather then speculate about an open-ended set of possible problems you
should gather information using one of the methods here (or others).


"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
news:(E-Mail Removed)...
> I am writing what amounts to a "front-end" for XCopy to help some of
> my less computer literate clients implement some sort of sensible
> backup strategy. It sets up the XCopy command line in the Arguments of
> a Process component, starts it, and them waits for it to finish. There
> are a fair number of bells and whistles, but none of them are causing
> problems.
>
> I eventually had everything apparently running perfectly in the Debug
> Build, so I created a Release Build for final testing on a second
> system. I didn't get to the second system - the Release Build failed
> on my development system! It appears that, in the Release Build, the
> XCopy Process starts normally (no exceptions are thrown, and and an
> immediate check of .HasExited returns False) but subsequently (and
> very quickly) exits without doing any copying (but with an exit code
> of zero). All other components of the program work in the same way in
> the Release Build as they do in the Debug Build (i.e. properly!)
>
> Has anyone seen anything like this before? Where do I start in trying
> to sort it out?
>
> Please respond to the Newsgroup, so that others may benefit from the
exchange.
> Peter R. Fletcher
>
>
> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
News==----
> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
Newsgroups
> ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption
=---

Thanks for your suggestions. I have followed most of them, without
success. As far as the VB code is concerned, everything checks out as
working correctly. The arguments for the XCopy Process are exactly as
they are in the Debug Build, the Process is duly started, and
..HasExited is False a few lines later, but (in the Release Build), a
subsequent call to .WaitForExit returns immediately with an exit code
of 0 for the Process, despite the fact that nothing has been done.

On Fri, 9 Jul 2004 04:58:50 -0500, "David Levine"
<(E-Mail Removed)> wrote:

>I've written a lot of file-copy code and I haven't run into a problem where
>there was a difference between the DEBUG and RELEASE build generated code
>that caused such a problem, but there are a couple of things you can do to
>make your life easier.
>
>You can sprinkle Trace.WriteLine statements in your code and then run it
>while DebugView is running. You could also call Console.WriteLine to output
>directly to the console window. Either method works well for viewing runtime
>info about the state of your app.
>
>You can also change the settings of the release build so that it generates
>debugging information. You can add a call to Debugger.Break in Main so that
>it loads up the debugger so you can step through it.
>
>Rather then speculate about an open-ended set of possible problems you
>should gather information using one of the methods here (or others).
>
>
>"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
>news:(E-Mail Removed)...
>> I am writing what amounts to a "front-end" for XCopy to help some of
>> my less computer literate clients implement some sort of sensible
>> backup strategy. It sets up the XCopy command line in the Arguments of
>> a Process component, starts it, and them waits for it to finish. There
>> are a fair number of bells and whistles, but none of them are causing
>> problems.
>>
>> I eventually had everything apparently running perfectly in the Debug
>> Build, so I created a Release Build for final testing on a second
>> system. I didn't get to the second system - the Release Build failed
>> on my development system! It appears that, in the Release Build, the
>> XCopy Process starts normally (no exceptions are thrown, and and an
>> immediate check of .HasExited returns False) but subsequently (and
>> very quickly) exits without doing any copying (but with an exit code
>> of zero). All other components of the program work in the same way in
>> the Release Build as they do in the Debug Build (i.e. properly!)
>>
>> Has anyone seen anything like this before? Where do I start in trying
>> to sort it out?
>>
>> Please respond to the Newsgroup, so that others may benefit from the
>exchange.
>> Peter R. Fletcher
>>
>>
>> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
>News==----
>> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
>Newsgroups
>> ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption
>=---
>


Please respond to the Newsgroup, so that others may benefit from the exchange.
Peter R. Fletcher

I went back to the drawing board. Since the problem seemed to be
occurring within the spawned Process, I tried changing its parameters
to see if I could get it to behave. In my original version, I had
redirected StandardInput to a StreamWriter sending a Ctrl-C so that if
XCopy prompted for terminal input (most likely because it ran out of
space on removable media), it would see the ^C and be caused to abort
(with a non-zero exit code). I had coded this "according to the book"
and, in the Debug Build, it worked "according to the book".

However, it appears that it is the Standard Input redirection that is
causing trouble in the Release Build. Leaving RedirectStandardInput
set to True and removing the StreamWriter code (I wondered if the ^C
was somehow getting there too fast and aborting the process before it
really got started) doesn't help, but setting RedirectStandardInput to
False restores normal operation in the Release Build, provided, of
course, that you don't run out of space. I can think of a few
workarounds for detecting "Media Full" problems without the Standard
Input redirection, but it should work as written. Are there any known
problems in this area?

On Fri, 9 Jul 2004 04:58:50 -0500, "David Levine"
<(E-Mail Removed)> wrote:

>I've written a lot of file-copy code and I haven't run into a problem where
>there was a difference between the DEBUG and RELEASE build generated code
>that caused such a problem, but there are a couple of things you can do to
>make your life easier.
>
>You can sprinkle Trace.WriteLine statements in your code and then run it
>while DebugView is running. You could also call Console.WriteLine to output
>directly to the console window. Either method works well for viewing runtime
>info about the state of your app.
>
>You can also change the settings of the release build so that it generates
>debugging information. You can add a call to Debugger.Break in Main so that
>it loads up the debugger so you can step through it.
>
>Rather then speculate about an open-ended set of possible problems you
>should gather information using one of the methods here (or others).
>
>
>"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
>news:(E-Mail Removed)...
>> I am writing what amounts to a "front-end" for XCopy to help some of
>> my less computer literate clients implement some sort of sensible
>> backup strategy. It sets up the XCopy command line in the Arguments of
>> a Process component, starts it, and them waits for it to finish. There
>> are a fair number of bells and whistles, but none of them are causing
>> problems.
>>
>> I eventually had everything apparently running perfectly in the Debug
>> Build, so I created a Release Build for final testing on a second
>> system. I didn't get to the second system - the Release Build failed
>> on my development system! It appears that, in the Release Build, the
>> XCopy Process starts normally (no exceptions are thrown, and and an
>> immediate check of .HasExited returns False) but subsequently (and
>> very quickly) exits without doing any copying (but with an exit code
>> of zero). All other components of the program work in the same way in
>> the Release Build as they do in the Debug Build (i.e. properly!)
>>
>> Has anyone seen anything like this before? Where do I start in trying
>> to sort it out?
>>
>> Please respond to the Newsgroup, so that others may benefit from the
>exchange.
>> Peter R. Fletcher
>>
>>
>> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
>News==----
>> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
>Newsgroups
>> ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption
>=---
>


Please respond to the Newsgroup, so that others may benefit from the exchange.
Peter R. Fletcher

Unfortunately, getting rid of Standard Input redirection doesn't seem
to be the solution either. Although it solved the problem initially,
adding code to check for the destination device filling up again
resulted in a Debug Build that worked perfectly and a Release build
that failed in the "usual" way, I think that I am going to have to
write my own directory copy code, even though using XCopy to do the
work seemed to make much more sense.

On Fri, 9 Jul 2004 04:58:50 -0500, "David Levine"
<(E-Mail Removed)> wrote:

>I've written a lot of file-copy code and I haven't run into a problem where
>there was a difference between the DEBUG and RELEASE build generated code
>that caused such a problem, but there are a couple of things you can do to
>make your life easier.
>
>You can sprinkle Trace.WriteLine statements in your code and then run it
>while DebugView is running. You could also call Console.WriteLine to output
>directly to the console window. Either method works well for viewing runtime
>info about the state of your app.
>
>You can also change the settings of the release build so that it generates
>debugging information. You can add a call to Debugger.Break in Main so that
>it loads up the debugger so you can step through it.
>
>Rather then speculate about an open-ended set of possible problems you
>should gather information using one of the methods here (or others).
>
>
>"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
>news:(E-Mail Removed)...
>> I am writing what amounts to a "front-end" for XCopy to help some of
>> my less computer literate clients implement some sort of sensible
>> backup strategy. It sets up the XCopy command line in the Arguments of
>> a Process component, starts it, and them waits for it to finish. There
>> are a fair number of bells and whistles, but none of them are causing
>> problems.
>>
>> I eventually had everything apparently running perfectly in the Debug
>> Build, so I created a Release Build for final testing on a second
>> system. I didn't get to the second system - the Release Build failed
>> on my development system! It appears that, in the Release Build, the
>> XCopy Process starts normally (no exceptions are thrown, and and an
>> immediate check of .HasExited returns False) but subsequently (and
>> very quickly) exits without doing any copying (but with an exit code
>> of zero). All other components of the program work in the same way in
>> the Release Build as they do in the Debug Build (i.e. properly!)
>>
>> Has anyone seen anything like this before? Where do I start in trying
>> to sort it out?
>>
>> Please respond to the Newsgroup, so that others may benefit from the
>exchange.
>> Peter R. Fletcher
>>
>>
>> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
>News==----
>> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
>Newsgroups
>> ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption
>=---
>


Please respond to the Newsgroup, so that others may benefit from the exchange.
Peter R. Fletcher

It's actually trivial to do. Most of the work is done in a single method
supplied by the framework.

"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
news:(E-Mail Removed)...
> Unfortunately, getting rid of Standard Input redirection doesn't seem
> to be the solution either. Although it solved the problem initially,
> adding code to check for the destination device filling up again
> resulted in a Debug Build that worked perfectly and a Release build
> that failed in the "usual" way, I think that I am going to have to
> write my own directory copy code, even though using XCopy to do the
> work seemed to make much more sense.
>
> On Fri, 9 Jul 2004 04:58:50 -0500, "David Levine"
> <(E-Mail Removed)> wrote:
>
> >I've written a lot of file-copy code and I haven't run into a problem
where
> >there was a difference between the DEBUG and RELEASE build generated code
> >that caused such a problem, but there are a couple of things you can do
to
> >make your life easier.
> >
> >You can sprinkle Trace.WriteLine statements in your code and then run it
> >while DebugView is running. You could also call Console.WriteLine to
output
> >directly to the console window. Either method works well for viewing
runtime
> >info about the state of your app.
> >
> >You can also change the settings of the release build so that it
generates
> >debugging information. You can add a call to Debugger.Break in Main so
that
> >it loads up the debugger so you can step through it.
> >
> >Rather then speculate about an open-ended set of possible problems you
> >should gather information using one of the methods here (or others).
> >
> >
> >"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
> >news:(E-Mail Removed)...
> >> I am writing what amounts to a "front-end" for XCopy to help some of
> >> my less computer literate clients implement some sort of sensible
> >> backup strategy. It sets up the XCopy command line in the Arguments of
> >> a Process component, starts it, and them waits for it to finish. There
> >> are a fair number of bells and whistles, but none of them are causing
> >> problems.
> >>
> >> I eventually had everything apparently running perfectly in the Debug
> >> Build, so I created a Release Build for final testing on a second
> >> system. I didn't get to the second system - the Release Build failed
> >> on my development system! It appears that, in the Release Build, the
> >> XCopy Process starts normally (no exceptions are thrown, and and an
> >> immediate check of .HasExited returns False) but subsequently (and
> >> very quickly) exits without doing any copying (but with an exit code
> >> of zero). All other components of the program work in the same way in
> >> the Release Build as they do in the Debug Build (i.e. properly!)
> >>
> >> Has anyone seen anything like this before? Where do I start in trying
> >> to sort it out?
> >>
> >> Please respond to the Newsgroup, so that others may benefit from the
> >exchange.
> >> Peter R. Fletcher
> >>
> >>
> >> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
> >News==----
> >> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
> >Newsgroups
> >> ---= 19 East/West-Coast Specialized Servers - Total Privacy via
Encryption
> >=---
> >
>
>
> Please respond to the Newsgroup, so that others may benefit from the
exchange.
> Peter R. Fletcher

I assume that you are talking about File.Copy - I couldn't find
anything that would copy a Directory, with included files.

On Sat, 10 Jul 2004 15:24:36 -0500, "David Levine"
<(E-Mail Removed)> wrote:

>It's actually trivial to do. Most of the work is done in a single method
>supplied by the framework.
>
>"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
>news:(E-Mail Removed)...
>> Unfortunately, getting rid of Standard Input redirection doesn't seem
>> to be the solution either. Although it solved the problem initially,
>> adding code to check for the destination device filling up again
>> resulted in a Debug Build that worked perfectly and a Release build
>> that failed in the "usual" way, I think that I am going to have to
>> write my own directory copy code, even though using XCopy to do the
>> work seemed to make much more sense.
>>
>> On Fri, 9 Jul 2004 04:58:50 -0500, "David Levine"
>> <(E-Mail Removed)> wrote:
>>
>> >I've written a lot of file-copy code and I haven't run into a problem
>where
>> >there was a difference between the DEBUG and RELEASE build generated code
>> >that caused such a problem, but there are a couple of things you can do
>to
>> >make your life easier.
>> >
>> >You can sprinkle Trace.WriteLine statements in your code and then run it
>> >while DebugView is running. You could also call Console.WriteLine to
>output
>> >directly to the console window. Either method works well for viewing
>runtime
>> >info about the state of your app.
>> >
>> >You can also change the settings of the release build so that it
>generates
>> >debugging information. You can add a call to Debugger.Break in Main so
>that
>> >it loads up the debugger so you can step through it.
>> >
>> >Rather then speculate about an open-ended set of possible problems you
>> >should gather information using one of the methods here (or others).
>> >
>> >
>> >"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
>> >news:(E-Mail Removed)...
>> >> I am writing what amounts to a "front-end" for XCopy to help some of
>> >> my less computer literate clients implement some sort of sensible
>> >> backup strategy. It sets up the XCopy command line in the Arguments of
>> >> a Process component, starts it, and them waits for it to finish. There
>> >> are a fair number of bells and whistles, but none of them are causing
>> >> problems.
>> >>
>> >> I eventually had everything apparently running perfectly in the Debug
>> >> Build, so I created a Release Build for final testing on a second
>> >> system. I didn't get to the second system - the Release Build failed
>> >> on my development system! It appears that, in the Release Build, the
>> >> XCopy Process starts normally (no exceptions are thrown, and and an
>> >> immediate check of .HasExited returns False) but subsequently (and
>> >> very quickly) exits without doing any copying (but with an exit code
>> >> of zero). All other components of the program work in the same way in
>> >> the Release Build as they do in the Debug Build (i.e. properly!)
>> >>
>> >> Has anyone seen anything like this before? Where do I start in trying
>> >> to sort it out?
>> >>
>> >> Please respond to the Newsgroup, so that others may benefit from the
>> >exchange.
>> >> Peter R. Fletcher
>> >>
>> >>
>> >> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
>> >News==----
>> >> http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
>> >Newsgroups
>> >> ---= 19 East/West-Coast Specialized Servers - Total Privacy via
>Encryption
>> >=---
>> >
>>
>>
>> Please respond to the Newsgroup, so that others may benefit from the
>exchange.
>> Peter R. Fletcher
>


Please respond to the Newsgroup, so that others may benefit from the exchange.
Peter R. Fletcher

Hmmm, I haven't tried copy a directory in a single call, I've always copied
the file(s) in a loop, recursing into subdirectories as needed. I've been
doing it that way for so long that I don't consider it to be a burden.

"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
news:(E-Mail Removed)...
> I assume that you are talking about File.Copy - I couldn't find
> anything that would copy a Directory, with included files.
>
> On Sat, 10 Jul 2004 15:24:36 -0500, "David Levine"
> <(E-Mail Removed)> wrote:
>
> >It's actually trivial to do. Most of the work is done in a single method
> >supplied by the framework.
> >
> >"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in message
> >news:(E-Mail Removed)...
> >> Unfortunately, getting rid of Standard Input redirection doesn't seem
> >> to be the solution either. Although it solved the problem initially,
> >> adding code to check for the destination device filling up again
> >> resulted in a Debug Build that worked perfectly and a Release build
> >> that failed in the "usual" way, I think that I am going to have to
> >> write my own directory copy code, even though using XCopy to do the
> >> work seemed to make much more sense.
> >>
> >> On Fri, 9 Jul 2004 04:58:50 -0500, "David Levine"
> >> <(E-Mail Removed)> wrote:
> >>
> >> >I've written a lot of file-copy code and I haven't run into a problem
> >where
> >> >there was a difference between the DEBUG and RELEASE build generated
code
> >> >that caused such a problem, but there are a couple of things you can
do
> >to
> >> >make your life easier.
> >> >
> >> >You can sprinkle Trace.WriteLine statements in your code and then run
it
> >> >while DebugView is running. You could also call Console.WriteLine to
> >output
> >> >directly to the console window. Either method works well for viewing
> >runtime
> >> >info about the state of your app.
> >> >
> >> >You can also change the settings of the release build so that it
> >generates
> >> >debugging information. You can add a call to Debugger.Break in Main so
> >that
> >> >it loads up the debugger so you can step through it.
> >> >
> >> >Rather then speculate about an open-ended set of possible problems you
> >> >should gather information using one of the methods here (or others).
> >> >
> >> >
> >> >"Peter R. Fletcher" <pfletch(at)fletchers(hyphen)uk.com> wrote in
message
> >> >news:(E-Mail Removed)...
> >> >> I am writing what amounts to a "front-end" for XCopy to help some of
> >> >> my less computer literate clients implement some sort of sensible
> >> >> backup strategy. It sets up the XCopy command line in the Arguments
of
> >> >> a Process component, starts it, and them waits for it to finish.
There
> >> >> are a fair number of bells and whistles, but none of them are
causing
> >> >> problems.
> >> >>
> >> >> I eventually had everything apparently running perfectly in the
Debug
> >> >> Build, so I created a Release Build for final testing on a second
> >> >> system. I didn't get to the second system - the Release Build failed
> >> >> on my development system! It appears that, in the Release Build, the
> >> >> XCopy Process starts normally (no exceptions are thrown, and and an
> >> >> immediate check of .HasExited returns False) but subsequently (and
> >> >> very quickly) exits without doing any copying (but with an exit code
> >> >> of zero). All other components of the program work in the same way
in
> >> >> the Release Build as they do in the Debug Build (i.e. properly!)
> >> >>
> >> >> Has anyone seen anything like this before? Where do I start in
trying
> >> >> to sort it out?
> >> >>
> >> >> Please respond to the Newsgroup, so that others may benefit from the
> >> >exchange.
> >> >> Peter R. Fletcher
> >> >>
> >> >>
> >> >> ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet
> >> >News==----
> >> >> http://www.newsfeed.com The #1 Newsgroup Service in the World!
>100,000
> >> >Newsgroups
> >> >> ---= 19 East/West-Coast Specialized Servers - Total Privacy via
> >Encryption
> >> >=---
> >> >
> >>
> >>
> >> Please respond to the Newsgroup, so that others may benefit from the
> >exchange.
> >> Peter R. Fletcher
> >
>
>
> Please respond to the Newsgroup, so that others may benefit from the
exchange.
> Peter R. Fletcher