Debug Build works perfectly; Release Build fails silently!

[Peter R. Fletcher]

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

 

[David Williams , VB.NET MVP]

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]

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).

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

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

 

[David Levine]

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).

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

=---

 

[Peter R. Fletcher]

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.

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).



=---

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

 

[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?

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).



=---

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

 

[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.

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).



=---

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

 

[David Levine]

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

 

[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.

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

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

 

[David Levine]

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.

 

[mikeb]

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.

Could you post a small sample that compiles to a console program that
shows the problem? I, for one, would be interested in finding out what
the real problem is.

 

[Peter R. Fletcher]

The misbehaviour seemed to be sensitive enough to what was "going on
around it" that I would not be sure of producing a small sample
program without wasting more time than I am prepared to. I have now
rewritten the program without external processes.

Could you post a small sample that compiles to a console program that
shows the problem? I, for one, would be interested in finding out what
the real problem is.

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