ViewBag

The ViewBag is a dynamic object that provides a convenient late-bound way to pass information to a view.
ASP.NET MVC also provides the ability to pass strongly typed data or objects to a view template. This strongly typed approach enables better compile-time checking of your code and richer IntelliSense in the Visual Web Developer editor. We're using this approach with the MoviesController class and Index.cshtml view template.

Test Driven Development

TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
TDD is non-visually oriented whereas AMDD is visually oriented.

Threads overview

Threads are the operating system construct used by the common language runtime to execute code. At run time, all managed code is loaded into an application domain and is run by a managed thread.
There is not a one-to-one correlation between application domains and threads. Several threads can be executing in a single application domain at any given time and a particular thread is not confined to a single application domain. That is, threads are free to cross application domain boundaries; a new thread is not created for each application domain.

At any given time, every thread is executing in an application domain. Zero, one, or more than one thread might be executing in any given application domain. The run time keeps track of which threads are running in which application domains. You can locate the domain in which a thread is executing at any time by calling the GetDomain method.
You can attach a CultureInfo object to a thread. However, to prevent malicious code from entering other application domains, the CultureInfo object is automatically set to read-only when its thread crosses an application domain boundary.

using System;
  using System.Threading;
 
  class Test
  {
      static void Main()
      {
          Thread newThread = new Thread(new ThreadStart(ThreadMethod));
          newThread.Start();
      }
 
      static void ThreadMethod()
      {
          Console.WriteLine(
              "Thread {0} started in {1} with AppDomainID = {2}.",
              AppDomain.GetCurrentThreadId().ToString(),
              Thread.GetDomain().FriendlyName,
              Thread.GetDomainID().ToString());
      }
  }

Dynamic Polymorphism

http://maxotek.net/blog/csharp-tutorial-lesson-10-polymorphism-part-i-t43.html

http://code.msdn.microsoft.com/windowsdesktop/Polymorphism-in-software-c2035a03

Application Domain

Operating systems and runtime environments typically provide some form of isolation between applications. For example, Windows uses processes to isolate applications. This isolation is necessary to ensure that code running in one application cannot adversely affect other, unrelated applications.

Application domains provide an isolation boundary for security, reliability, and versioning, and for unloading assemblies. Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run.
The isolation provided by application domains has the following benefits:

• Faults in one application cannot affect other applications. Because type-safe code cannot cause memory faults, using application domains ensures that code running in one domain cannot affect other applications in the process.
  
• Individual applications can be stopped without stopping the entire process. Using application domains enables you to unload the code running in a single application.
• Code running in one application cannot directly access code or resources from another application. The common language runtime enforces this isolation by preventing direct calls between objects in different application domains. Objects that pass between domains are either copied or accessed by proxy. If the object is copied, the call to the object is local. That is, both the caller and the object being referenced are in the same application domain. If the object is accessed through a proxy, the call to the object is remote.
• the application domain provides configuration settings such as application version policies, the location of any remote assemblies it accesses, and information about where to locate assemblies that are loaded into the domain.
• Permissions granted to code can be controlled by the application domain in which the code is running.

Global Assembly Cache

Each computer where the common language runtime is installed has a machine-wide code cache called the global assembly cache. The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.

There are two ways to deploy an assembly into the global assembly cache:

• Use an installer designed to work with the global assembly cache. This is the preferred option for installing assemblies into the global assembly cache.
  
• Use a developer tool called the Global Assembly Cache tool (Gacutil.exe), provided by the Windows Software Development Kit (SDK).

Assemblies deployed in the global assembly cache must have a strong name. When an assembly is added to the global assembly cache, integrity checks are performed on all files that make up the assembly. The cache performs these integrity checks to ensure that an assembly has not been tampered with, for example, when a file has changed but the manifest does not reflect the change.

A strong name consists of the assembly's identity—its simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. It is generated from an assembly file (the file that contains the assembly manifest, which in turn contains the names and hashes of all the files that make up the assembly), using the corresponding private key.

Constructors in C#

A constructor is a class default method that gets automatically executed whenever class’s object is created or whenever class is initialized.

Consider this example
public class demo
{
public demo ()
{
//A default Constructor
}
//Class members
}