.NET Development Foundation | |
---|---|
Exam objective:Implementing service processes, threading, and application domains in a .NET Framework application
![]() | Wikipedia has related information atWindows service |
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.
![]() | Wikipedia has related information atThread (computer science) |
![]() | To do: |
![]() | Wikipedia has related information atApplication Domain |
![]() | To do: |
Exam objective:Implement, install, and control a service
(Refer System.ServiceProcess namespace)
Inherit from ServiceBase class -MSDN
ServiceController class and ServiceControllerPermission class
ServiceInstaller and ServiceProcessInstaller class
ServiceChangeDescription structure and ServiceChangeReason enumeration
Exam objective:Develop multithreaded .NET Framework applications
(Refer System.Threading namespace)
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]
Exam objective:Create a unit of isolation for common language runtime in a .NET Framework application by using application domains
(Refer System namespace)
SeeMSDN
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");
UseAppDomain.CurrentDomain to get the application domain the calling thread is using.
SeeMSDN
It is possible to execute an assembly by name usingAppDomain.ExecuteAssemblyByName:
AppDomain ad = AppDomain.CreateDomain("Name"); ad.ExecuteAssemblyByName("aname, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a9b8c7d6");
Or useAppDomain.ExecuteAssembly to supply a path to the assemby:
AppDomain ad = AppDomain.CreateDomain("Name"); ad.ExecuteAssembly(@"c:\path\to\file.exe");
SeeMSDN
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 staticAppDomain.Unload function:
AppDomain ad = AppDomain.CreateDomain("Name"); AppDomain.Unload(ad);
SeeMSDN
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 theInternet Zone. The Internet Zone has limited permissions. To do this create aZone 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
SeeMSDN
Use theSetupInformation 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);