AFAIK debug builds are unoptimized and larger in size.

In my own experience it's not that difficult to find out where it fails even
without line numbers. Make sure to keep your procedures to a minimal size
(good practice anyway). You could also perhaps store some data from your
general layers to help (things like say the name of the last stored proc you
sent to the DB or similar info).

--
Patrice

Others have pointed out some typical differences between a "debug" and  
"release" build.  Though one must be careful to keep in mind that they are  
just generalizations.  For example, an "optimized" build could in some  
cases be larger than the "non-optimized" build, depending on what the  
optimization goals are.

That said, it seems to me that you are really only interested in one  
aspect of the "debug" build: the inclusion of symbols (the .pdb file)  
allowing for the stack trace to include line numbers in the exceptions.  
The ability to attach to the process is a red herring.  You can attach the  
debugger to any process; the only question is whether you get useful  
symbol information when you do so.

While I haven't done this in .NET yet, I would be surprised if it's that  
different from non-managed code.  In particular, with non-managed code you  
can still generate a PDB for an optimized build, and you can still debug  
the code using that PDB (as well as do things like use the various debug  
helper DLLs to map code addreses to source code line numbers, which is  
esssentially the behavior you're looking for with respect to the stack  
trace).  Of course, because an optimized build often rearranges code,  
removes code, etc. there is not always a one-to-one correspondence between  
the executing code and your original source code.  But that is likely to  
be an insignificant issue with respect to the goals you're stating.  With  
the correct symbols, you can still debug an optimized build even if you  
may get disoriented once in awhile, and you can still get reasonably  
useful stack trace information.

So, if you are at all concerned about the downside of using a debug build  
for your released version (and frankly, you probably should be if your  
application is even a little bit performance-bound), it would be better to  
go ahead and release an optimized build, but make sure that symbols are  
included so that you can get the debugging information you want.

Pete