| Groups | Blog | Home |
dotnet clr : Debug vs. Release code.
debug build vs. a Release build? Either way, the IL can be disassembled back into native source, so I don't understand the difference in the two types of builds. Why shouldn't a debugger be able to debug release code just as easily as debug code? Is it purely based on optimizations or is there more to it? -- ----------------------------------- Ken Varn Senior Software Engineer Diebold Inc. EmailID = varnk Domain = Diebold.com -----------------------------------
Debug mode means that the debugger and it's symbols will be loaded during
run time so that run-time debugging can take place. Release mode does not do this and will "sometimes" result in a smaller assembly size. That said, that's the difference. [quoted text, click to view] "Ken Varn" <nospam> wrote in message news:Othvk3HDGHA.3692@TK2MSFTNGP10.phx.gbl... > If compiling a C# .NET application, what is the main difference between a > debug build vs. a Release build? Either way, the IL can be disassembled > back into native source, so I don't understand the difference in the two > types of builds. Why shouldn't a debugger be able to debug release code > just as easily as debug code? Is it purely based on optimizations or is > there more to it? > > -- > ----------------------------------- > Ken Varn > Senior Software Engineer > Diebold Inc. > > EmailID = varnk > Domain = Diebold.com > ----------------------------------- > >
[quoted text, click to view]
Scott M. wrote: > Debug mode means that the debugger and it's symbols will be loaded during > run time so that run-time debugging can take place. Release mode does not > do this and will "sometimes" result in a smaller assembly size. > > That said, that's the difference. > > > "Ken Varn" <nospam> wrote in message > news:Othvk3HDGHA.3692@TK2MSFTNGP10.phx.gbl... >> If compiling a C# .NET application, what is the main difference between a >> debug build vs. a Release build? Either way, the IL can be disassembled >> back into native source, so I don't understand the difference in the two >> types of builds. Why shouldn't a debugger be able to debug release code >> just as easily as debug code? Is it purely based on optimizations or is >> there more to it? >> >> -- >> ----------------------------------- >> Ken Varn >> Senior Software Engineer >> Diebold Inc. >> >> EmailID = varnk >> Domain = Diebold.com >> ----------------------------------- >> >> > > Untrue. The debugger is not explicitly loaded for a debug build. If you run a debug build outside a debugger, it will run as a normal application, without optimizations that a release build employs, so it will potentially not perform as well. Cheers,
[quoted text, click to view]
Scott M. wrote: Scott,> Ken, > > That is the same thing as what I said. Your comments just refer to running > the assembly as a stand-alone assembly and mine were based on the assumption > that the OP was talking about running the assembly from within VS.NET. I > didn't say anything that was untrue. > > -Scott > > "Stuart Carnie" <stuart.carnie@nospam.nospam> wrote in message > news:exoOBCWDGHA.528@TK2MSFTNGP09.phx.gbl... >> Scott M. wrote: >>> Debug mode means that the debugger and it's symbols will be loaded during >>> run time so that run-time debugging can take place. Release mode does >>> not do this and will "sometimes" result in a smaller assembly size. >>> >>> That said, that's the difference. >>> >>> >>> "Ken Varn" <nospam> wrote in message >>> news:Othvk3HDGHA.3692@TK2MSFTNGP10.phx.gbl... >>>> If compiling a C# .NET application, what is the main difference between >>>> a >>>> debug build vs. a Release build? Either way, the IL can be disassembled >>>> back into native source, so I don't understand the difference in the two >>>> types of builds. Why shouldn't a debugger be able to debug release code >>>> just as easily as debug code? Is it purely based on optimizations or is >>>> there more to it? >>>> >>>> -- >>>> ----------------------------------- >>>> Ken Varn >>>> Senior Software Engineer >>>> Diebold Inc. >>>> >>>> EmailID = varnk >>>> Domain = Diebold.com >>>> ----------------------------------- >>>> >>>> >>> >> Untrue. The debugger is not explicitly loaded for a debug build. If you >> run a debug build outside a debugger, it will run as a normal application, >> without optimizations that a release build employs, so it will potentially >> not perform as well. >> >> Cheers, >> >> Stu > > What I said is very different to your statement. Your original statement is very confusing. You state : "Debug mode means that the debugger and it's symbols will be loaded during run time so that run-time debugging can take place." Your most recent statement is still not quite correct. If a Release build is run in VS.NET, assuming symbols have been generated, it can be debugged, much the same as a debug build. Problems arise when trying to view certain symbols that the optimizer has removed or step through code that has been reorganized during compiler optimization. Reorganization of code is much more apparent in C++ builds than what I have seen in C#, but I believe it still exists. Cheers,
Ken,
That is the same thing as what I said. Your comments just refer to running the assembly as a stand-alone assembly and mine were based on the assumption that the OP was talking about running the assembly from within VS.NET. I didn't say anything that was untrue. -Scott [quoted text, click to view] "Stuart Carnie" <stuart.carnie@nospam.nospam> wrote in message news:exoOBCWDGHA.528@TK2MSFTNGP09.phx.gbl... > Scott M. wrote: >> Debug mode means that the debugger and it's symbols will be loaded during >> run time so that run-time debugging can take place. Release mode does >> not do this and will "sometimes" result in a smaller assembly size. >> >> That said, that's the difference. >> >> >> "Ken Varn" <nospam> wrote in message >> news:Othvk3HDGHA.3692@TK2MSFTNGP10.phx.gbl... >>> If compiling a C# .NET application, what is the main difference between >>> a >>> debug build vs. a Release build? Either way, the IL can be disassembled >>> back into native source, so I don't understand the difference in the two >>> types of builds. Why shouldn't a debugger be able to debug release code >>> just as easily as debug code? Is it purely based on optimizations or is >>> there more to it? >>> >>> -- >>> ----------------------------------- >>> Ken Varn >>> Senior Software Engineer >>> Diebold Inc. >>> >>> EmailID = varnk >>> Domain = Diebold.com >>> ----------------------------------- >>> >>> >> >> > > Untrue. The debugger is not explicitly loaded for a debug build. If you > run a debug build outside a debugger, it will run as a normal application, > without optimizations that a release build employs, so it will potentially > not perform as well. > > Cheers, > > Stu
[quoted text, click to view]
> Your most recent statement is still not quite correct. If a Release build > is run in VS.NET, assuming symbols have been generated, it can be > debugged, much the same as a debug build. Not true. 1) Create an ASP.NET project in VB.NET. 2) Switch to release mode. 3) Set a breakpoint. 4) Run the project. It will not stop on your breakpoint.
[quoted text, click to view]
Scott M. <s-mar@nospam.nospam> wrote: > > Your most recent statement is still not quite correct. If a Release build > > is run in VS.NET, assuming symbols have been generated, it can be > > debugged, much the same as a debug build. > > Not true. > > 1) Create an ASP.NET project in VB.NET. > 2) Switch to release mode. > 3) Set a breakpoint. > 4) Run the project. > > It will not stop on your breakpoint. Is that true even if you change the settings so that the debug symbols are generated (which they're not by default)? -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
I can't say. I'm not even sure how to change the setting so that debugging
symbols are geneterated if you are in release mode. I thought the way you "change the settings" is to switch to Debug mode, hence my point. [quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:MPG.1e204b34c9471ca898cc35@msnews.microsoft.com... > Scott M. <s-mar@nospam.nospam> wrote: >> > Your most recent statement is still not quite correct. If a Release >> > build >> > is run in VS.NET, assuming symbols have been generated, it can be >> > debugged, much the same as a debug build. >> >> Not true. >> >> 1) Create an ASP.NET project in VB.NET. >> 2) Switch to release mode. >> 3) Set a breakpoint. >> 4) Run the project. >> >> It will not stop on your breakpoint. > > Is that true even if you change the settings so that the debug symbols > are generated (which they're not by default)? > > -- > Jon Skeet - <skeet@pobox.com> > http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet > If replying to the group, please do not mail me too
[quoted text, click to view]
"Richard Grimes" wrote: > Symbols are used to 'link' source code to the run time code. You can still > attach a debugger to a process even if it is in release mode. You can > still set breakpoints (they will be breakpoints on x86) and run the code > until the breakpoint is hit. What you cannot do is single step through > *source code* in the debugger in a release mode app. Source code debugging should also work if you enable JIT tracking info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmakingimageeasiertodebug.asp -- This posting is provided "AS IS" with no warranties, and confers no rights.
My point was simply that, although it is possible to attach a debugger
manually, that is not the default action. And, that although it is possible to generate symbols via a manual setting, it is also not the default. The OP wanted to know what the difference between Debug and Release mode was and what I told him/her is correct (assuming we aren't talking about overriding default behaviors in VS.NET). [quoted text, click to view] "Richard Grimes" <richardg@mvps.org> wrote in message news:u0WoAcjDGHA.1816@TK2MSFTNGP11.phx.gbl... > Scott M. wrote: >>> Your most recent statement is still not quite correct. If a Release >>> build is run in VS.NET, assuming symbols have been generated, it can >>> be debugged, much the same as a debug build. >> >> Not true. >> >> 1) Create an ASP.NET project in VB.NET. >> 2) Switch to release mode. >> 3) Set a breakpoint. >> 4) Run the project. >> >> It will not stop on your breakpoint. > > So what? > > Symbols are used to 'link' source code to the run time code. You can still > attach a debugger to a process even if it is in release mode. You can > still set breakpoints (they will be breakpoints on x86) and run the code > until the breakpoint is hit. What you cannot do is single step through > *source code* in the debugger in a release mode app. > > Try this. In your release code call Debugger.Break(). Run the code. You'll > find that the debugger will be attached at the point where Break is > called. > > Richard > -- > Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm > Security Tutorial: > http://www.grimes.demon.co.uk/workshops/securityWS.htm >
[quoted text, click to view]
Scott M. <s-mar@nospam.nospam> wrote: > I can't say. I'm not even sure how to change the setting so that debugging > symbols are geneterated if you are in release mode. I thought the way you > "change the settings" is to switch to Debug mode, hence my point. No - you go to the configuration, the "Build" part of configuration properties, and set "Generate Debugging Information" to True. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
Scott M. wrote: >> Your most recent statement is still not quite correct. If a Release >> build is run in VS.NET, assuming symbols have been generated, it can >> be debugged, much the same as a debug build. > > Not true. > > 1) Create an ASP.NET project in VB.NET. > 2) Switch to release mode. > 3) Set a breakpoint. > 4) Run the project. > > It will not stop on your breakpoint. So what? Symbols are used to 'link' source code to the run time code. You can still attach a debugger to a process even if it is in release mode. You can still set breakpoints (they will be breakpoints on x86) and run the code until the breakpoint is hit. What you cannot do is single step through *source code* in the debugger in a release mode app. Try this. In your release code call Debugger.Break(). Run the code. You'll find that the debugger will be attached at the point where Break is called. Richard -- Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm Security Tutorial: http://www.grimes.demon.co.uk/workshops/securityWS.htm
[quoted text, click to view]
Pavel Lebedinsky [MSFT] wrote: > "Richard Grimes" wrote: > >> Symbols are used to 'link' source code to the run time code. You can >> still attach a debugger to a process even if it is in release mode. >> You can still set breakpoints (they will be breakpoints on x86) and >> run the code until the breakpoint is hit. What you cannot do is >> single step through *source code* in the debugger in a release mode >> app. > > Source code debugging should also work if you enable JIT > tracking info: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmakingimageeasiertodebug.asp Hmmm, if that is 100% the case, then there would be no point in symbols, would there? The .NET module, even compiled with /debug, does not contain information about the name of the source file, nor file numbers. That information is held in the symbols file. Generating tracking information, with no knowledge of the location of the local variable, is not much use. The debugger requires symbol files to be able to single step through source code. If you can show me how to do this using GenerateTrackingInfo on a release build executable without symbols files, then I would be very interested. Richard -- Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm Security Tutorial: http://www.grimes.demon.co.uk/workshops/securityWS.htm
Yes, symbols are also necessary for source level debugging.
It's possible (and I would say, strongly recommended) to generate symbols for release code, even though VS used to make it difficult (I think VS 2003 didn't expose the /debug:pdbonly option; I haven't checked 2005). -- This posting is provided "AS IS" with no warranties, and confers no rights. [quoted text, click to view] "Richard Grimes" wrote: >>> You can still set breakpoints (they will be breakpoints on x86) and >>> run the code until the breakpoint is hit. What you cannot do is >>> single step through *source code* in the debugger in a release mode >>> app. >> >> Source code debugging should also work if you enable JIT >> tracking info: > > Hmmm, if that is 100% the case, then there would be no point in symbols, > would there? > > The .NET module, even compiled with /debug, does not contain information > about the name of the source file, nor file numbers. That information is > held in the symbols file. Generating tracking information, with no > knowledge of the location of the local variable, is not much use. The > debugger requires symbol files to be able to single step through source > code. If you can show me how to do this using GenerateTrackingInfo on a > release build executable without symbols files, then I would be very > interested.
I had no idea I would create such a debate on this.
The main point of confusion that I was having with the issue is that of disassembly of .net code and its relationship to debugging. If a .net disassebler can reconstruct the code from the assembly, then what is the need for debug vs. release code? In particular, I have a problem with having to build in debug mode so that I can get stack trace logs to work in my application to obtain line number and function of errors. -- ----------------------------------- Ken Varn Senior Software Engineer Diebold Inc. EmailID = varnk Domain = Diebold.com ----------------------------------- [quoted text, click to view] "Scott M." <s-mar@nospam.nospam> wrote in message news:evh%23QZIDGHA.528@TK2MSFTNGP09.phx.gbl... > Debug mode means that the debugger and it's symbols will be loaded during > run time so that run-time debugging can take place. Release mode does not > do this and will "sometimes" result in a smaller assembly size. > > That said, that's the difference. > > > "Ken Varn" <nospam> wrote in message > news:Othvk3HDGHA.3692@TK2MSFTNGP10.phx.gbl... > > If compiling a C# .NET application, what is the main difference between a > > debug build vs. a Release build? Either way, the IL can be disassembled > > back into native source, so I don't understand the difference in the two > > types of builds. Why shouldn't a debugger be able to debug release code > > just as easily as debug code? Is it purely based on optimizations or is > > there more to it? > > > > -- > > ----------------------------------- > > Ken Varn > > Senior Software Engineer > > Diebold Inc. > > > > EmailID = varnk > > Domain = Diebold.com > > ----------------------------------- > > > > > >
My simple answer is:
Debug version has some compilation/assembly parameters turned on in the build set that permits easier debugging. In some cases, people write code with #if DEBUG statements that provide additional checks. In this case the DEBUG compilation parameter would be on in the DEBUG build, and not present in the Release build. In this particular case, the IL would be different because some IL code would be suppressed (not generated) in the Release build. As noted earlier, the default settings in Debug builds typically turn on the ..PDB (symbol tables) etc. and the Release builds leave them off. I build release versions with symbols turned on (so I can debug the release version in event of a customer problem). The symbol files are not shipped with the release, but they do exist for our use [quoted text, click to view] "Ken Varn" wrote:
> I had no idea I would create such a debate on this. > > The main point of confusion that I was having with the issue is that of > disassembly of .net code and its relationship to debugging. If a .net > disassebler can reconstruct the code from the assembly, then what is the > need for debug vs. release code? > > In particular, I have a problem with having to build in debug mode so that I > can get stack trace logs to work in my application to obtain line number and > function of errors. > > -- > ----------------------------------- > Ken Varn > Senior Software Engineer > Diebold Inc. > > EmailID = varnk > Domain = Diebold.com > ----------------------------------- > "Scott M." <s-mar@nospam.nospam> wrote in message > news:evh%23QZIDGHA.528@TK2MSFTNGP09.phx.gbl... > > Debug mode means that the debugger and it's symbols will be loaded during > > run time so that run-time debugging can take place. Release mode does not > > do this and will "sometimes" result in a smaller assembly size. > > > > That said, that's the difference. > > > > > > "Ken Varn" <nospam> wrote in message > > news:Othvk3HDGHA.3692@TK2MSFTNGP10.phx.gbl... > > > If compiling a C# .NET application, what is the main difference between > a > > > debug build vs. a Release build? Either way, the IL can be disassembled > > > back into native source, so I don't understand the difference in the two > > > types of builds. Why shouldn't a debugger be able to debug release code > > > just as easily as debug code? Is it purely based on optimizations or is > > > there more to it? > > > > > > -- > > > ----------------------------------- > > > Ken Varn > > > Senior Software Engineer > > > Diebold Inc. > > > > > > EmailID = varnk > > > Domain = Diebold.com > > > ----------------------------------- > > > > > > > > > > > >
Thanks. This is very helpful.
In regards to being able to log a stack trace. I am using the StackTrace class. I have noticed that if I do not have the PDB files on the target system, that I cannot get function and line number information in my stack trace. Yet, the standard CLR assemblies can be walked for the same information. Is there anyway that I can have my code build so that I can get useful stack trace info into a log file without having to provide the PDB files? So far having a Debug build seems to be the only way that I know of. -- ----------------------------------- Ken Varn Senior Software Engineer Diebold Inc. EmailID = varnk Domain = Diebold.com ----------------------------------- [quoted text, click to view] "Keith Dorken" <kadorken@nospam.nospam> wrote in message news:FDB9D468-B772-46F4-9AF3-ABF4DBC10F2E@microsoft.com... > My simple answer is: > Debug version has some compilation/assembly parameters turned on in the > build set that permits easier debugging. In some cases, people write code > with #if DEBUG statements that provide additional checks. In this case the > DEBUG compilation parameter would be on in the DEBUG build, and not present > in the Release build. In this particular case, the IL would be different > because some IL code would be suppressed (not generated) in the Release build. > > As noted earlier, the default settings in Debug builds typically turn on the > .PDB (symbol tables) etc. and the Release builds leave them off. I build > release versions with symbols turned on (so I can debug the release version > in event of a customer problem). The symbol files are not shipped with the > release, but they do exist for our use > > "Ken Varn" wrote: > > > I had no idea I would create such a debate on this. > > > > The main point of confusion that I was having with the issue is that of > > disassembly of .net code and its relationship to debugging. If a .net > > disassebler can reconstruct the code from the assembly, then what is the > > need for debug vs. release code? > > > > In particular, I have a problem with having to build in debug mode so that I > > can get stack trace logs to work in my application to obtain line number and > > function of errors. > > > > -- > > ----------------------------------- > > Ken Varn > > Senior Software Engineer > > Diebold Inc. > > > > EmailID = varnk > > Domain = Diebold.com > > ----------------------------------- > > "Scott M." <s-mar@nospam.nospam> wrote in message > > news:evh%23QZIDGHA.528@TK2MSFTNGP09.phx.gbl... > > > Debug mode means that the debugger and it's symbols will be loaded during > > > run time so that run-time debugging can take place. Release mode does not > > > do this and will "sometimes" result in a smaller assembly size. > > > > > > That said, that's the difference. > > > > > > > > > "Ken Varn" <nospam> wrote in message > > > news:Othvk3HDGHA.3692@TK2MSFTNGP10.phx.gbl... > > > > If compiling a C# .NET application, what is the main difference between > > a > > > > debug build vs. a Release build? Either way, the IL can be disassembled > > > > back into native source, so I don't understand the difference in the two > > > > types of builds. Why shouldn't a debugger be able to debug release code > > > > just as easily as debug code? Is it purely based on optimizations or is > > > > there more to it? > > > > > > > > -- > > > > ----------------------------------- > > > > Ken Varn > > > > Senior Software Engineer > > > > Diebold Inc. > > > > > > > > EmailID = varnk > > > > Domain = Diebold.com > > > > ----------------------------------- > > > > > > > > > > > > > > > > > > > >
[quoted text, click to view]
Scott M. wrote: We are talking about two different things. You are referring to an >> Your most recent statement is still not quite correct. If a Release build >> is run in VS.NET, assuming symbols have been generated, it can be >> debugged, much the same as a debug build. > > Not true. > > 1) Create an ASP.NET project in VB.NET. > 2) Switch to release mode. > 3) Set a breakpoint. > 4) Run the project. > > It will not stop on your breakpoint. > > ASP.NET application, I'm referring to a regular Windows application. Cheers,
[quoted text, click to view]
Scott M. wrote: > My point was simply that, although it is possible to attach a debugger > manually, that is not the default action. And, that although it is possible > to generate symbols via a manual setting, it is also not the default. > > The OP wanted to know what the difference between Debug and Release mode was > and what I told him/her is correct (assuming we aren't talking about > overriding default behaviors in VS.NET). > > Scott - depends what version of VS.NET the OP is referring to - something they do not state. In VS.NET 2005, a Release build of a C# project (by *default*) does generate debug symbols, so I am able to debug a project just fine. For 2003, the default Release build does no generate debug symbols, which I suspect is what you are referring to. In your original reply, the following statement: "Debug mode means that the debugger and it's symbols will be loaded during run time so that run-time debugging can take place." is not fully qualified, and therefore ambiguous. "Run-time" could easily be interpreted by the uninitiated as "a debug build, regardless of how it is started (e.g. in VS.NET or from Windows Explorer), will load the debug symbols and debugger". This is obviously not correct. Again, the OP did not state they were running the project from within VS.NET - they asked "What is the difference between a debug build and a release build". I simply wanted to ensure the original poster was not misinformed. Cheers, Stu [quoted text, click to view] > "Richard Grimes" <richardg@mvps.org> wrote in message
> news:u0WoAcjDGHA.1816@TK2MSFTNGP11.phx.gbl... >> Scott M. wrote: >>>> Your most recent statement is still not quite correct. If a Release >>>> build is run in VS.NET, assuming symbols have been generated, it can >>>> be debugged, much the same as a debug build. >>> Not true. >>> >>> 1) Create an ASP.NET project in VB.NET. >>> 2) Switch to release mode. >>> 3) Set a breakpoint. >>> 4) Run the project. >>> >>> It will not stop on your breakpoint. >> So what? >> >> Symbols are used to 'link' source code to the run time code. You can still >> attach a debugger to a process even if it is in release mode. You can >> still set breakpoints (they will be breakpoints on x86) and run the code >> until the breakpoint is hit. What you cannot do is single step through >> *source code* in the debugger in a release mode app. >> >> Try this. In your release code call Debugger.Break(). Run the code. You'll >> find that the debugger will be attached at the point where Break is >> called. >> >> Richard >> -- >> Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm >> Security Tutorial: >> http://www.grimes.demon.co.uk/workshops/securityWS.htm >> >
In the debug mode the optimizations are not enabled. Example the JIT
method inlining is not enabled.
[quoted text, click to view]
Naveen wrote:
> In the debug mode the optimizations are not enabled. Example the JIT > method inlining is not enabled. >
[quoted text, click to view]
> > Untrue. The debugger is not explicitly loaded for a debug build. If you > run a debug build outside a debugger, it will run as a normal application, > without optimizations that a release build employs, so it will potentially > not perform as well. > This is the default behavior. It is possible to change the project settings (if using the IDE) so that DEBUG builds also optimise. Thus, the statement "it will run as a normal application, without optimizations that a release build employs" is only the default behavior and can be changed. Thanks, Shawn
Yes, it is possible to have a debug build with optimize code using
Visual Studio settings.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |