.NET Development Foundation/Services

Services, threading, and application domains.
Exam objective: Implementing service processes, threading, and application domains in a .NET Framework application
Topics.
Services.
The term service stands here for a Windows service. The basic definition of a Windows service is a long-running process that does not require a user interface. Why would you need a long-running process that does not require a user interface? Essentially two reasons:
The exam objectives concerning services are very basic and touch the first problems that you will encounter when dealing with them:
The more important and complicated design issues are not covered by this exam and will be treated by the enterprise development exam.
Classes, Interfaces, and tools.
Implement, install, and control a service.
Exam objective: Implement, install, and control a service
Inherit from ServiceBase class - MSDN
ServiceController class and ServiceControllerPermission class
ServiceInstaller and ServiceProcessInstaller class
ServiceChangeDescription structure and ServiceChangeReason enumeration
Develop multithreaded applications.
Exam objective: Develop multithreaded .NET Framework applications
Thread class - MSDN
ThreadPool class - MSDN
ThreadStart delegate, ParameterizedThreadStart delegate, and SynchronizationContext class 
 Thread t1 = new Thread (new ThreadStart(LengthyLogic));
 public void LengthyLogic ()
 // Logic code
 Thread t1 = new Thread(new ParameterizedThreadStart(LengthyLogic));
 // Use the overload of the Start method that has a parameter of type Object.
 t1.Start(myData);
 static void LengthyLogic(object data)
 // Logic code
Timeout class, Timer class, TimerCallback delegate, WaitCallback delegate, WaitHandle class, and WaitOrTimerCallback delegate
ThreadExceptionEventArgs class and ThreadExceptionEventHanlder class
ThreadState enumeration and ThreadPriority enumeration
ReaderWriterLock class - MSDN
AutoResetEvent class and ManualResetEvent class
IAsyncResult interface and ICancelableAsyncResult interface 
EventWaitHandle class, RegisterWaitHandle class, SendOrPostCallback delegate, and IOCompletionCallback delegate
Interlocked class, NativeOverlapped structure, and Overlapped class
ExecutionContext class, HostExecutionContext class, HostExecutionContext manager, and ContextCallback delegate
LockCookie structure, Monitor class, Mutex class, and Semaphore class MSDN]
Using applications domains.
Exam objective: Create a unit of isolation for common language runtime in a .NET Framework application by using application domains
(Refer System namespace) 
Create an application domain.
See MSDN
An application domain is a division of a process into multiple parts. Applications running in different application domains are as isolated as they would be in different processes. So they cannot access memory in another application domain. However, if native code is run, it can gain unlimited access to the whole process, which includes other application domains.
Application domains are easier to maintain and are faster because it is easier to communicate between application domains than between processes. An application domain can hold multiple assemblies.
To create an application domain, you must at least supply a name for the new application domain:
 AppDomain ad = AppDomain.CreateDomain("Name");
Use "AppDomain.CurrentDomain" to get the application domain the calling thread is using.
Load assemblies into an application domain.
See MSDN
It is possible to execute an assembly by name using "AppDomain.ExecuteAssemblyByName":
 AppDomain ad = AppDomain.CreateDomain("Name");
 ad.ExecuteAssemblyByName("aname, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a9b8c7d6");
Or use "AppDomain.ExecuteAssembly" to supply a path to the assemby:
 AppDomain ad = AppDomain.CreateDomain("Name");
 ad.ExecuteAssembly(@"c:\path\to\file.exe");
Unload an application domain.
See MSDN
It is not possible to unload assemblies from the default application domain. However if an assembly is loaded in a different application domain, you can unload the whole application domain which includes all assemblies in that application domain.
To unload an application domain, use the static "AppDomain.Unload" function:
 AppDomain ad = AppDomain.CreateDomain("Name");
 AppDomain.Unload(ad); 
Configure an application domain.
See MSDN
The most likely reason to modify the application domain configuration, is to restrict certain permissions to limit the damage if an attacker exploits vulnerabilities in an assembly.
An example is to run an assembly in the "Internet Zone". The Internet Zone has limited permissions. To do this create a "Zone Evidence" and supply it as a parameter when creating the Application Domain:
 object [] myEvidenceTypes = {new Zone (SecurityZone.Internet)};
 Evidence myEvidence = new Evidence(myEvidenceTypes, null);
 AppDomain ad = AppDomain.CreateDomain("Name", myEvidence); // Pass the Evidence when creating the App. Domain
 ad.ExecuteAssembly(@"c:\path\to\file.exe");
It is also possible to execute only one assembly in an Application Domain with different permissions;
 object [] myEvidenceTypes = {new Zone (SecurityZone.Internet)};
 Evidence myEvidence = new Evidence(myEvidenceTypes, null);
 AppDomain ad = AppDomain.CreateDomain("Name");
 ad.ExecuteAssembly(@"c:\path\to\file.exe", myEvidence); // Pass the Evidence in the ExecuteAssembly function
Except Evidence, you can also use the AppDomainSetup class to set other properties.
 AppDomainSetup ads = new AppDomainSetup();
 ads.ApplicationBase = @"c:\Test";
 ads.DisallowCodeDownload = true;
 AppDomain ad = AppDomain.CreateDomain("Name", null, ads); // use null as second parameter for default Evidence
Retrieve setup information from an application domain.
See MSDN
Use the "SetupInformation" property of an AppDomain to read the settings from that application domain;
 AppDomainSetup ads = AppDomain.CurrentDomain.SetupInformation;
 Console.WriteLine(ads.ConfigurationFile);
 Console.WriteLine(ads.ApplicationName);