I think I know what a build is. But I am not sure. My definition of a build is another word for saying compiled application. Can someone please tell me what exactly a build is. And why do people ask for 3 types of builds. Such as Debug Build, Profile Build and a Release Build. What are the differences.
[edit]
the types of builds
Have a look at Visual Studio Debug and Release Modes
Release Mode
When an assembly is built in release mode, the compiler performs all available optimisations to ensure that the outputted executables and libraries execute as efficiently as possible. This mode should be used for completed and tested software that is to be released to end-users. The drawback of release mode is that whilst the generated code is usually faster and smaller, it is not accessible to debugging tools.
Debug Mode
Debug mode is used whilst developing software. When an assembly is compiled in debug mode, additional symbolic information is embedded and the code is not optimised. This means that the output of the compiler is generally larger, slower and less efficient. However, a debugger can be attached to the running program to allow the code to be stepped through whilst monitoring the values of internal variables.
A build means basically doing a set of tasks to make your program. The main components of a typical build is compiling and linking.
More specifically a build can contain compiling, linking, setting version numbers, copying outputs to some location, creating an installer and anything else.
When people say debug or release build or etc., they may have different settings defined for each. For example in a debug build you will create program database files for debugging.
A build does not have to include only compiled and linked targets. Usually there is at least one of those, but a "build" could also include creating plain-text or binary files, moving images, sounds, and other files into the correct places to be accessed by the file, or any other operation that needs to be performed for the application to run.
The multiple types of builds are made to target different "audiences", if you will. For instance, and end-user does not need to collect information about what functions were called or how many times and exception was raised, or any other diagnostic info (though that information is valuable to developers). Usually the final "release" build is made to be fast and small, and not load the user down with extras like that.
Related
When I recompile my project (asp.net, c#) with aspnet_compiler the rebuilt binaries change (when compared to the previous build) even if no code changes have been made.
This, I understand, is due to the build generating a new Module Version ID (guid) each time it builds (to distinguish between builds), another similar question talks about this: Can i specify the module version id (MVID) when building a .net assembly?
The above linked question seems to suggest there is no way to rebuild a project and have the binaries match a previous build of the same unchanged code.. ok, fine, I understand - but why are all the binaries being rebuilt at all?
I would think, according to the documentation ( http://msdn.microsoft.com/en-us/library/ms229863(v=vs.80).aspx ), that unless -c is specified as an argument the aspnet_compiler should only rebuild those binaries that actually need to be (due to changed code). Am I misunderstanding or maybe missing something?
The aspnet_compiler arguments I'm using:
aspnet_compiler -f -u -fixednames -nologo -v / -p .\myproject\ .\mybuild\
Note that this issue occurs only with a WebSite project, not a Web Application project (they are compiled differently).
Also this issue occurs even if you create a WebSite project and page with no functionality, and never open it or change it in anyway between builds.
Decompiling the binaries that are produced shows no differences. Comparing the binaries of two "identical" builds shows small differences in the same part of the binaries each time - which I believe is probably related to the random build guid. I've found no way of avoiding this change between builds.
Check out this excellent answer by Eric Lippert on how does the C# compiler makes multi passes to compile the source code. There can me many reasons why your build was not identical to the previous one, although the functionality is same.
Compilers replace special language features such as using block with with IL equivalents
The compilers does many optimizations on your code, each iteration may produce slightly different output.
Compilers have to create materialized names for anonymous method names and they are different each time you compile
And many more reasons you could easily figure it out using a dis-assembler
Check out these dis-assemblers and decompile your library or executable to gain better understanding.
http://ilspy.net/ , http://www.telerik.com/products/decompiler.aspx
I've found in many cases using the aspnet_compiler especially in situations where my projects have references to other project in the same solution results in full rebuilds that are often hard to explain. (though the few times I've investigated there were "changes" even if they don't truly effect anything such as changes to whitespace, comments, etc)
I've also had problems with a number of plugins in visual studio that have done everything from manipulate tabulation and other white space, the actual project file, etc. While these changes have no noticeable change to us humans, the compiler takes one look and goes "I see a change! REBUILD ALL THE THINGS!!!"
Not sure my answer is any help, but I would disable your plugins, run the compiler, then run the compiler again and see what happens...
In Visual Studio for a C# project, if you go to Project Properties > Build > Advanced > Debug Info you have three options: none, full, or pdb-only.
Which setting is the most appropriate for a release build?
So, what are the differences between full and pdb-only?
If I use full will there be performance ramifications? If I use pdb-only will it be harder to debug production issues?
I would build with pdb-only. You will not be able to attach a debugger to the released product, but if you get a crash dump, you can use Visual Studio or WinDBG to examine the stack traces and memory dumps at the time of the crash.
If you go with full rather than pdb-only, you'll get the same benefits, except that the executable can be attached directly to a debugger. You'll need to determine if this is reasonable given your product & customers.
Be sure to save the PDB files somewhere so that you can reference them when a crash report comes in. If you can set up a symbol server to store those debugging symbols, so much the better.
If you opt to build with none, you will have no recourse when there's a crash in the field. You won't be able to do any sort of after-the-fact examination of the crash, which could severely hamper your ability to track down the problem.
A note about performance:
Both John Robbins and Eric Lippert have written blog posts about the /debug flag, and they both indicate that this setting has zero performance impact. There is a separate /optimize flag which dictates whether the compiler should perform optimizations.
WARNING
MSDN documentation for /debug switch (In Visual Studio it is Debug Info) seems to be out-of-date! This is what it has which is incorrect
If you use /debug:full, be aware that there is some impact on the
speed and size of JIT optimized code and a small impact on code
quality with /debug:full. We recommend /debug:pdbonly or no PDB for
generating release code.
One difference between /debug:pdbonly and /debug:full is that with
/debug:full the compiler emits a DebuggableAttribute, which is used to
tell the JIT compiler that debug information is available.
Then, what is true now?
Pdb-only – Prior to .NET 2.0, it helped to investigate the crash dumps from released product (customer machines). But it didn't let attaching the debugger. This is not the case from .NET 2.0. It is exactly same as Full.
Full – This helps us to investigate crash dumps, and also allows us to attach debugger to release build. But unlike MSDN mentions, it doesn't impact the performance (since .NET 2.0). It does exactly same as Pdb-only.
If they are exactly same, why do we have these options? John Robbins (windows debugging god) found out these are there for historical reasons.
Back in .NET 1.0 there were differences, but in .NET 2.0 there isn’t.
It looks like .NET 4.0 will follow the same pattern. After
double-checking with the CLR Debugging Team, there is no difference at
all.
What controls whether the JITter does a debug build is the /optimize
switch. <…>
The bottom line is that you want to build your release builds with
/optimize+ and any of the /debug switches so you can debug with source
code.
then he goes on to prove it.
Now the optimization is part of a separate switch /optimize (in visual studio it is called Optimize code).
In short, irrespective of DebugInfo setting pdb-only or full, we will have same results. The recommendation is to avoid None since it would deprive you of being able to analyze the crash dumps from released product or attaching debugger.
You'll want PDB only, but you won't want to give the PDB files to users. Having them for yourself though, alongside your binaries, gives you the ability to load crash dumps into a debugger like WinDbg and see where your program actually failed. This can be rather useful when your code is crashing on a machine you don't have access to.
Full debug adds the [Debuggable] attribute to your code. This has a huge impact on speed. For example, some loop optimizations may be disabled to make single stepping easier. In addition, it has a small effect on the JIT process, as it turns on tracking.
I'm in the process of writing a unhandled exception handler and the stack trace includes the line number when pdb-only is used, otherwise I just get the name of the Sub/Function when I choose None.
If I don't distribute the .pdb I don't get the line number in the stack trace even with the pdb-only build.
So, I'm distributing (XCOPY deploy on a LAN) the pdb along with the exe from my VB app.
In Visual Studio for a C# project, if you go to Project Properties > Build > Advanced > Debug Info you have three options: none, full, or pdb-only.
Which setting is the most appropriate for a release build?
So, what are the differences between full and pdb-only?
If I use full will there be performance ramifications? If I use pdb-only will it be harder to debug production issues?
I would build with pdb-only. You will not be able to attach a debugger to the released product, but if you get a crash dump, you can use Visual Studio or WinDBG to examine the stack traces and memory dumps at the time of the crash.
If you go with full rather than pdb-only, you'll get the same benefits, except that the executable can be attached directly to a debugger. You'll need to determine if this is reasonable given your product & customers.
Be sure to save the PDB files somewhere so that you can reference them when a crash report comes in. If you can set up a symbol server to store those debugging symbols, so much the better.
If you opt to build with none, you will have no recourse when there's a crash in the field. You won't be able to do any sort of after-the-fact examination of the crash, which could severely hamper your ability to track down the problem.
A note about performance:
Both John Robbins and Eric Lippert have written blog posts about the /debug flag, and they both indicate that this setting has zero performance impact. There is a separate /optimize flag which dictates whether the compiler should perform optimizations.
WARNING
MSDN documentation for /debug switch (In Visual Studio it is Debug Info) seems to be out-of-date! This is what it has which is incorrect
If you use /debug:full, be aware that there is some impact on the
speed and size of JIT optimized code and a small impact on code
quality with /debug:full. We recommend /debug:pdbonly or no PDB for
generating release code.
One difference between /debug:pdbonly and /debug:full is that with
/debug:full the compiler emits a DebuggableAttribute, which is used to
tell the JIT compiler that debug information is available.
Then, what is true now?
Pdb-only – Prior to .NET 2.0, it helped to investigate the crash dumps from released product (customer machines). But it didn't let attaching the debugger. This is not the case from .NET 2.0. It is exactly same as Full.
Full – This helps us to investigate crash dumps, and also allows us to attach debugger to release build. But unlike MSDN mentions, it doesn't impact the performance (since .NET 2.0). It does exactly same as Pdb-only.
If they are exactly same, why do we have these options? John Robbins (windows debugging god) found out these are there for historical reasons.
Back in .NET 1.0 there were differences, but in .NET 2.0 there isn’t.
It looks like .NET 4.0 will follow the same pattern. After
double-checking with the CLR Debugging Team, there is no difference at
all.
What controls whether the JITter does a debug build is the /optimize
switch. <…>
The bottom line is that you want to build your release builds with
/optimize+ and any of the /debug switches so you can debug with source
code.
then he goes on to prove it.
Now the optimization is part of a separate switch /optimize (in visual studio it is called Optimize code).
In short, irrespective of DebugInfo setting pdb-only or full, we will have same results. The recommendation is to avoid None since it would deprive you of being able to analyze the crash dumps from released product or attaching debugger.
You'll want PDB only, but you won't want to give the PDB files to users. Having them for yourself though, alongside your binaries, gives you the ability to load crash dumps into a debugger like WinDbg and see where your program actually failed. This can be rather useful when your code is crashing on a machine you don't have access to.
Full debug adds the [Debuggable] attribute to your code. This has a huge impact on speed. For example, some loop optimizations may be disabled to make single stepping easier. In addition, it has a small effect on the JIT process, as it turns on tracking.
I'm in the process of writing a unhandled exception handler and the stack trace includes the line number when pdb-only is used, otherwise I just get the name of the Sub/Function when I choose None.
If I don't distribute the .pdb I don't get the line number in the stack trace even with the pdb-only build.
So, I'm distributing (XCOPY deploy on a LAN) the pdb along with the exe from my VB app.
Does anyone have any advice about extending our SVN & Cruise Control CI process to populate a Symbol Server?
We are trying to remotely debug test environments for our ASP.NET 2.0 C# website and have been running into problems getting the correct symbols to always load.
Our build process is done in release mode not debug mode so how does this affect the creation of PDB files?
Using VS2008, we have solved several issues in connecting to remote debugging since the test environments are not in the same domain. We are now getting this message when trying to watch variables:
Cannot obtain value of local or argument 'xxxxx' as it is not available at this instruction pointer, possibly because it has been optimized away
Is this because our build and subsequent deployment process is in release mode?
This error message comes because the CLR itself has optimized out the variables. The PDB's still contain all of the information about the locals in release mode, the debugger is just simply unable to access them.
It is possible though to build in release mode and generally avoid this problem. One of the factors as to whether or not the CLR will optimize in such a way that locals are not visible is the DebuggableAttribute class.
This attribute is generally emitted by the compiler and it changes the flags based on the projects mode: Release or Debug. If the attribute already exists in your project though, the compiler will not overwrite it.
If your have a web application (vs a web site) you can just add the following line to AssemblyInfo.cs and it should fix the problem
[assembly: Debuggable(DebuggingModes.DisableOptimizations)]
Note this does disable performance optimizations so you probably don't want to actually release this way but it's helpful for debugging.
Continuing from my previous question, is there a comprehensive document that lists all available differences between debug and release modes in a C# application, and particularly in a web application?
What differences are there?
"Debug" and "Release" are just names for predefined project configurations defined by Visual Studio.
To see the differences, look at the Build Tab in Project Properties in Visual Studio.
The differences in VS2005 include:
DEBUG constant defined in Debug configuration
Optimize code enabled in Release configuration
as well as other differences you can see by clicking on the "Advanced" button
But you can:
Change the build settings for Debug and Release configurations in Project Propeties / Build
Create your own custom configurations by right-clicking on the solution in Solution Explorer and selecting Configuration Manager
I think the behaviour of the DEBUG constant is fairly clear (can be referenced in the #if preprocessor directive or in the ConditionalAttribute). But I'm not aware of any comprehensive documentation on exactly what optimizations are enabled - in fact I suspect Microsoft would want to be free to enhance their optimizer without notice
I'm not aware of one concise document, but:
Debug.Write calls are stripped out in Release
In Release, your CallStack may look a bit "strange" due to optimizations, as outlined by Scott Hanselman
There isn't one document that lists the differences. In addition to some of the differences already listed, compiling in Debug mode turns off most of the JIT compiler optimizations that are performed at runtime and also emits more complete debug information in to the symbol database file (.pdb).
Another big difference is that the GC behavior is somewhat different in that the JIT compiler will insert calls to GC.KeepAlive() as appropriate/needed in order to support debugging sessions.
Debug and Release are just labelling for different solution configurations. You can add others if you want. If you wish you can add more configurations from configuration manager–
http://msdn.microsoft.com/en-us/library/kwybya3w.aspx
Major differences –
In a debug DLL several extra instructions are added to enable you to set a breakpoint on every source code line in Visual Studio. Also, the code will not be optimized, again to enable you to debug the code.
In the release version, these extra instructions are removed.
PDB file is created in only Debug mode and not in release mode.
In release mode, code is optimized by the optimizer that's built into the JIT compiler. It makes the following optimizations:
• Method inlining - A method call is replaced by the injecting the code of the method.
• CPU register allocation - Local variables and method arguments can stay stored in a CPU register without ever (or less frequently) being stored back to the stack frame
• Array index checking elimination - An important optimization when working with arrays (all .NET collection classes use an array internally). When the JIT compiler can verify that a loop never indexes an array out of bounds then it will eliminate the index check.
• Loop unrolling - Short loops (up to 4) with small bodies are eliminated by repeating the code in the loop body.
• Dead code elimination - A statement like if (false) { /.../ } gets completely eliminated.
• Code hoisting- Code inside a loop that is not affected by the loop can be moved out of the loop.
• Common sub-expression elimination. x = y + 4; z = y + 4; becomes z = x
One major performanance area if you are using any of the ASP.NET Ajax controls: debug information is removed from the JavaScript library when running in release, and I have seen major preformance improvements on complicated pages. Other web based resources may be either cached or not cached based on this setting.
Also, remember that Debug / Release in a web application is dictated by the web.config file, not your settings within Visual Studio.
<system.web>
<compilation debug="true">
More information:
Don’t run production ASP.NET Applications with debug=”true” enabled
You can also manage some part of code that you want to run only in debug or only in release with preprocessor markups:
#if DEBUG
// Some code running only in debug
#endif
or
#if NOT DEBUG
// Some code running only in release
#endif
Drawing with GDI+ is considerably slower in Debug mode.
Release version:
is considerable faster (most important), optimized
can't be debuged (step by step)
and code written in "debug" directive is not included
See What's the difference between a Debug vs Release Build?.
I got an error message when I distribute executable file to another machine indicating that the system missed MSVCP110D.dll.
The solution to this issue is stated in Stack Overflow question Visual Studio MSVCP110D.dll is missing.
IN XXXXD.dll D means that the DLL file is a debug version of the DLL file. But MS Visual C++ Redistributable packages include only the release version of DLL files.
That means if you need to distribute a program developed by Visual C++ you need to build it in Release mode. And also you need to install MS Visual C++ Redistributable (correct version) on the target machine.
So I think this a one of key difference between debug and release mode.