I am struggling with the purpose of the build configuration manager in Visual Studio 2008. Specifically I am interested in knowing what it does when developing a console application and also a web application (web application project). Does setting it to Debug or Release mode make any difference when you are developing and running the application in the context of VS2008? What does it to when you want to build the solution?
Visual-studio – the purpose of the Build Configuration Manager in VS2008
visual studiovisual-studio-2008
Related Solutions
C# language version history:
These are the versions of C# known about at the time of this writing:
- C# 1.0 released with .NET 1.0 and VS2002 (January 2002)
- C# 1.2 (bizarrely enough); released with .NET 1.1 and VS2003 (April 2003). First version to call
Dispose
onIEnumerator
s which implementedIDisposable
. A few other small features. - C# 2.0 released with .NET 2.0 and VS2005 (November 2005). Major new features: generics, anonymous methods, nullable types, and iterator blocks
- C# 3.0 released with .NET 3.5 and VS2008 (November 2007). Major new features: lambda expressions, extension methods, expression trees, anonymous types, implicit typing (
var
), and query expressions - C# 4.0 released with .NET 4 and VS2010 (April 2010). Major new features: late binding (
dynamic
), delegate and interface generic variance, more COM support, named arguments, tuple data type and optional parameters - C# 5.0 released with .NET 4.5 and VS2012 (August 2012). Major features: async programming, and caller info attributes. Breaking change: loop variable closure.
- C# 6.0 released with .NET 4.6 and VS2015 (July 2015). Implemented by Roslyn. Features: initializers for automatically implemented properties, using directives to import static members, exception filters, element initializers,
await
incatch
andfinally
, extensionAdd
methods in collection initializers. - C# 7.0 released with .NET 4.7 and VS2017 (March 2017). Major new features: tuples, ref locals and ref return, pattern matching (including pattern-based switch statements), inline
out
parameter declarations, local functions, binary literals, digit separators, and arbitrary async returns. - C# 7.1 released with VS2017 v15.3 (August 2017). New features: async main, tuple member name inference, default expression, and pattern matching with generics.
- C# 7.2 released with VS2017 v15.5 (November 2017). New features: private protected access modifier, Span<T>, aka interior pointer, aka stackonly struct, and everything else.
- C# 7.3 released with VS2017 v15.7 (May 2018). New features: enum, delegate and
unmanaged
generic type constraints.ref
reassignment. Unsafe improvements:stackalloc
initialization, unpinned indexedfixed
buffers, customfixed
statements. Improved overloading resolution. Expression variables in initializers and queries.==
and!=
defined for tuples. Auto-properties' backing fields can now be targeted by attributes. - C# 8.0 released with .NET Core 3.0 and VS2019 v16.3 (September 2019). Major new features: nullable reference-types, asynchronous streams, indices and ranges, readonly members, using declarations, default interface methods, static local functions, and enhancement of interpolated verbatim strings.
- C# 9.0 released with .NET 5.0 and VS2019 v16.8 (November 2020). Major new features: init-only properties, records, with-expressions, data classes, positional records, top-level programs, improved pattern matching (simple type patterns, relational patterns, logical patterns), improved target typing (target-type
new
expressions, target typed??
and?
), and covariant returns. Minor features: relax ordering ofref
andpartial
modifiers, parameter null checking, lambda discard parameters, nativeint
s, attributes on local functions, function pointers, static lambdas, extensionGetEnumerator
, module initializers, and extending partial.
In response to the OP's question:
What are the correct version numbers for C#? What came out when? Why can't I find any answers about C# 3.5?
There is no such thing as C# 3.5 - the cause of confusion here is that the C# 3.0 is present in .NET 3.5. The language and framework are versioned independently, however - as is the CLR, which is at version 2.0 for .NET 2.0 through 3.5, .NET 4 introducing CLR 4.0, service packs notwithstanding. The CLR in .NET 4.5 has various improvements, but the versioning is unclear: in some places it may be referred to as CLR 4.5 (this MSDN page used to refer to it that way, for example), but the Environment.Version
property still reports 4.0.xxx.
As of May 3, 2017, the C# Language Team created a history of C# versions and features on their GitHub repository: Features Added in C# Language Versions. There is also a page that tracks upcoming and recently implemented language features.
Website:
The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.
If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name, which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part of SP 1 for Visual Studio 2005. The main differences are the Web Application Project was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build time. To update the project, it must be recompiled and the DLL file published for changes to occur.
Another nice feature of the Web Application project is it's much easier to exclude files from the project view. In the Web Site project, each file that you exclude is renamed with an excluded keyword in the filename. In the Web Application Project, the project just keeps track of which files to include/exclude from the project view without renaming them, making things much tidier.
The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:
- You need to migrate large Visual Studio .NET 2003 applications to VS 2005? use the Web Application project.
- You want to open and edit any directory as a Web project without creating a project file? use Web Site project.
- You need to add pre-build and post-build steps during compilation? use Web Application project.
- You need to build a Web application using multiple Web projects? use the Web Application project.
- You want to generate one assembly for each page? use the Web Site project.
- You prefer dynamic compilation and working on pages without building entire site on each page view? use Web Site project.
- You prefer single-page code model to code-behind model? use Web Site project.
Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.
Related Topic
- .net – What does the Visual Studio “Any CPU” target mean
- Visual-studio – Difference between Rebuild and Clean + Build in Visual Studio
- Visual-studio – the purpose of the Visual Studio Hosting Process
- .net – “The breakpoint will not currently be hit. The source code is different from the original version.” What does this mean
- Visual-studio – App.Config Transformation for projects which are not Web Projects in Visual Studio
- Visual-studio – Difference between Build Solution, Rebuild Solution, and Clean Solution in Visual Studio
- Wpf – The name ‘InitializeComponent’ does not exist in the current context
- .net – How to fix the Visual Studio compile error, “mismatch between processor architecture”
Best Answer
The Build Configuration Manager allows you to set different combinations of project build options for a solution. For example, say you have a solution with 4 projects, log4net, a DAL, a Business layer and the Website. Most times you'll want to run the website and business layer in debug, but the DAL and log4net in release mode. Sometimes you'll want to run the DAL in debug too, but only on a rare occurrence will you want to run everything in debug. The config manager lets you define configurations like that.
Additionally, you could define a x64 build that had some projects target x64 and others target AnyCPU depending on need. Or even a build target that excluded specific projects and included others depending on need.
So in short, the config manager lets you control the inter-process build relations at a level beyond the simplistic debug-all or release-all.
I'd also guess, that 99% of the time you won't need to mess w/the config manager anyway. :-)