Response File در دات نت چیست؟

Response File فایلی است  متنی با پسوند rsp که شامل سوئیچ های کامپایلر است که کامپایلر قبل از کامپایل این فایل را باز می کند و سوئیچ های مشخص شده در فرایند کامپایل  را اعمال می کند.برای مشخص کردن نام Response File شما از علامت @ استفاده می کنید به این نکته توجه کنید که کامپایلر از چندین Response File پشتیبانی می کند.

csc.exe @MyProject.rsp CodeFile1.cs CodeFile2.cs

ما می توانیم به طور صریح بگوییم که از که از چه Response File فایلی استفاده کن علاوه بر آن خود کامپپایلر در دایرکتوری جاری به دنبال  Response File محلی و در دایرکتوری csc.exe به دنبال فایل عمومی می گردد.توجه به این نکته ضرروری است که Response File  محلی اولویت بیشتری را بر عمومی دارد.

به این ترتیب به وسیله Response File دیگر نیازی به افزودن سوئیچ های تکراری در زمان کامپایل نداریم.

یک نمونه Response file

# This file contains command­line options that the C# # command line compiler (CSC) will process as part # of every compilation, unless the “/noconfig” option # is specified.
# Reference the common Framework libraries
/r:Accessibility.dll
/r:Microsoft.CSharp.dll
/r:System.Configuration.dll
/r:System.Configuration.Install.dll
/r:System.Core.dll
/r:System.Data.dll
/r:System.Data.DataSetExtensions.dll
/r:System.Data.Linq.dll
/r:System.Data.OracleClient.dll
/r:System.Deployment.dll
/r:System.Design.dll
/r:System.DirectoryServices.dll
/r:System.dll
/r:System.Drawing.Design.dll
/r:System.Drawing.dll
/r:System.EnterpriseServices.dll
/r:System.Management.dll
/r:System.Messaging.dll
/r:System.Runtime.Remoting.dll
/r:System.Runtime.Serialization.dll
/r:System.Runtime.Serialization.Formatters.Soap.dll
/r:System.Security.dll
/r:System.ServiceModel.dll
/r:System.ServiceModel.Web.dll
/r:System.ServiceProcess.dll
/r:System.Transactions.dll
/r:System.Web.dll
/r:System.Web.Extensions.Design.dll
/r:System.Web.Extensions.dll
/r:System.Web.Mobile.dll
/r:System.Web.RegularExpressions.dll
/r:System.Web.Services.dll
/r:System.Windows.Forms.Dll
/r:System.Workflow.Activities.dll
/r:System.Workflow.ComponentModel.dll
/r:System.Workflow.Runtime.dll
/r:System.Xml.dll
/r:System.Xml.Linq.dll

کامپایل به وسیله Command line

در این قسمت به شما نشان خواهم داد که چگونه می توانید یک تایپ بسازید و آن را درون یک فایل قرار دهید که آن را بتوان Deploy کرد.کد زیر را در نظر بگیرید:

public class Program
   {
       public static void Main()
   {
       Console.WriteLine("I am shahrooz jefri");
   }
   }

این برنامه  که به نام Program است دارای یک متد public و static با خوروجی از جنس void است که درون خود از یک تایپ دیگری به نام Console استفاده می کند که توسط مایکروسافت تهیه شده است.

برای ساختن این برنامه نیاز است که کد زیر را در command line اجرا کنیم.


csc /out:program.exe /t:exe 
/r:MSCorLib.dll d:\Program.cs

سوئیچ out:program.exe به کامپایلر می گوید که خروجی باید از نوع  فایل اچرایی به نام program.exe باشد و همینطور سوئیچ /t[arget]:exe مشخص کننده نوع Win32 console application است.

اگر بخواهیم که برنامه به صورت خروجی windows formی باشد از /t[arget]:winexe استفاده می کنیم.

زمانی که کامپایلر کد را پردازش می کند نگاهی به متد WrtieLine می اندازد و در ابتدا از موجودیت آن در تایپ مورد نظر اطمینان حاصل می کند سپس از درست بودن پارامتر های پاس داده شده مطمئن می شود.

زمانی که شما از یک تایپی استفاده می کنید که داخل کد معرفی تعریف نشده می توانید به وسیله سوئیچ r[eference]:MSCorLib.dll آن را مشخص کنید. در این مثال خاص که MSCorLib است باید به این نکته توجه کرد که کامپایلر به صورت اتوماتیک آن را اضافه خواهد کرد و می توان آن را استفاده نکرد.

MsCORLib:Common Object Runtime (cor)

اهداف دات نت برای Deployment

برای مدت ها مایکروسافت در پیچیده بودن و ناپایدار بود امتیازات بالایی کسب کرده بود این پیچیده گی ها را می توان در عوامل زیر بررسی کرد.

  1. Dll Hell .تمام برنامه ها در ساختار مایکروسافت از Dll استفاده می کنند که توسط خود مایکروسافت یا سایر شرکت ها توسعه داده شده است.زمانی که شما از این Dll ها در هر کدی استفاده کنید نمی توان صد در صد صحت عملکرد کد را در برخورد با این Dll تضمین کنید.توجه به این نکنه ضرروری است که چون برنامه قبل از استفاده بارها و بارها تست می شود از این دست مشکلات کمتر پیش می آید.ولی ر زمانیکه یک از این Dllها توسط شرکت توسعه دهنده بروز شود و ما بخواهیم از این Dll در برنامه خودمون استفاده کنیم در این صورت عملا تست مجدد برنامه براحتی ممکن نیست.
  2. فرایند نصب پیجیده.زمانی که یک برنامه را نصب می کنید تاثیر یسیار زیادی در جای جای سیستم دارد از بروزرسانی رجیستری تا کپی شدن فایل ها در قسمت های مختلف.مشکل اینجاست که به صورت ایزوله برنامه ما نصب نمی شود و ما به راحتی امکان بک آپ گیری از برنامه را با کپی کردن فولدر برنامه نخواهیم داشت و برای انتقال به سیستم دیگر نیاز به نصب مجدد خواهیم داشت. به خاطر همین است که بعد از پاک کردن برنامه باز هم یک حسی نسبت به عدم پاکسازی کامل سیستنم از برنامه خواهیم داشت.
  3. امنیت.در این واقع ما زمانی که یک برنامه را درسیستم نصب می کنیم می تواند آن برنامه کارهایی در سیستم ما انجام دهد از قبیل کار با دایرکتوری باحتی فرستادن ایمیل.پس ما نیاز مند آن هستیم که صریحا اعلام کنیم که آیا مجوز دسترسی به فلان برنامه خاص می دهیم؟

درباه مشکل اول در بخش های بعدی به طور کامل توضیح خواهم داد ولی در مورد پراکندگی در نصب باید بگویم کد این مشکل برطرق شده و برخلاف COM دیگر نیازی به دستکاری در رجیستری نیست همچنین برای مشکل امنیت نیز در دات نت مدلی از امنیت به نام Code Access Security معرفی کرده که در این مدل برخلاف مدل ویندوز که بر اساس هویت کاربر است این مدل بر اساس دسترسی هایی است که برنامه هاستی که کامپننت ها را لود  می کند می تواند داشته باشد.برای مثال در سیلورلایت کد، مجوزهای کمتری نسبت به برنامه ای که در سیستم نصب شده  دارد.

 Code Access Security (CAS), in the Microsoft .NET framework, is Microsoft‘s solution to prevent untrusted code from performing privileged actions

کامپایل کد

قبل از اینکه وارد بحث های مربرط به Packaging و Deploying بشویم لازم دیدم در این پست در باره کامپایل کردن کد براتون بنویسم.

در سی شارپ زمانی که نیاز باشد یک کلاس را کامپایل کنیم به راحتی می توان به وسیله command line این کار را انجام داد.ما تا زمانی که از ویژوال استدیو استفاده می کنیم زیاد متوجه نخواهیم شد که در پشت چه اتفاقاتی در حال رخ دادن است.فزض کنید شما به هر دلیلی نمی توانیند که از ویژوال استدیو استفاده کنید در این حالت اگر بخواهید کلاس یا کلاس های خود را کامپایل کنید نیاز به صدا زدن کامپایلر سی شارپ به طور مستقیم خواهید داشت.

برای راهنمایی به این و این مقاله مراجعه کنید.

Compiles File.cs producing File.exe
csc File.cs 
Compiles File.cs producing File.dll
csc /target:library File.cs
Compiles File.cs and creates My.exe
csc /out:My.exe File.cs
Compiles all of the C# files in the current directory, with optimizations on and defines the DEBUG symbol. The output is File2.exe
csc /define:DEBUG /optimize /out:File2.exe *.cs
Compiles all of the C# files in the current directory producing a debug version of File2.dll. No logo and no warnings are displayed
csc /target:library /out:File2.dll /warn:0 /nologo /debug *.cs
Compiles all of the C# files in the current directory to Something.xyz (a DLL)
csc /target:library /out:Something.xyz *.cs

به این نکته نیز توجه کنید که مایکروسافت یک ابزاری به نام MSBuild دارد که مسئولیت کامپایل سورس کد(صدا زدن کامپایلر) packaging, testing, deployment and و ساخت documentations را دارد.

زمانی که F5 را در ویژوال استدیو می زنیم فایل پروژه به msbuild پاس داده می شود.از msbuild می توان بدون ویژوال استدیو هم استفاده کرد.

پس هم به وسیله command line و هم به وسیله MSBuild یک کد را می توان کامپایل کرد.

استفاده از Unmanaged code ها در دات نت.

ارتباط بین Unmanaged code و  managed code ها همواره از موضوعات مهم است زیرا بسیاری از کامپننت ها هستند که از قبل،شرکت های برنامه نویسی آن ها را به صورت Unmanaged code توسعه داده اند و هم اکنون نیاز است از آن ها استفاده شود.

CLR از سه سناریو برای ارتباط unmanaged code و managed code کدها پشتیبانی میکند

  1. managed code می تواند توابع موجود در  unmanaged code ها را صدا بزنند.
  2.  managed code می توانند از COM های موجود استفاده کنند.
  3.  unmanaged code کد ها می توانند از  managed code کدها استفاده کنند.

به نظر زیاد لازم نیست به طور ریز وارد این بحث شد. در صورتی که به اطلاعات بیشتر نیاز داشتید به اینجا مراجعه کنید.

Common Language Specification یا CLS

شابد برایتان جالب باشد که در CLR همه چیز به فیلد و متد تبدیل می شود! پس اگر جالب است با من همراه باشید.

COM به ما اجازه می دهد اشیا ساخته شده در زبان های مختلف باهم ارتباط داشته باشند.در CLR نیز به وسیله یک پارچه سازی که انجام می شود،باعث می شود با یک شی در  زبان برنامه نویسی متفاوت به گونه ای برخورد شود که گویی بومی آن زبان است.

این یکپارجه سازی به دلیل این است که CLR یک سری استاندارد برای تایپ ها،متادیتا ها و میحط های اجرایی کد دارد.

زبان های برنامه نویسی که برای CLR، کامپایلر درست کرده اند در عمل باهم بسیار متفاوت هستند به عنوان مثال ویژوال بیسیک به حروف بزرگ و کوچک حساس نیست این در حالی است که در سی شارپ برعکس این قضیه است.

بنابراین اگر شما نیاز دارید که یک تایپی را ایجاد کنید که در باقی زبان های برنامه نویسی دات نتی قابل دسترسی باشد نیازمند آن خواهید بود که از امکانات زبانی استفاده کنید که گارانتی می شود در باقی زبان های دات نتی قابل دسترسی باشد.

این امکانات را مایکروسافت تحت عنوان Common Language Specification یا CLS معرفی کرده که زبان های برنامه نویسی که برای CLR، کامپایلر می نویسند ملزم به رعایت آن خواهند بود.

CLR/CTS امکانات زیادی را در اختیار ما قرار می دهند پس اگر قابلیت انتقال یک تایپ در زبان های مختلف برایتان مهم نیست بنابراین نیازی ندارید خود را درCLS محدود کنید زیرا CLS دارای قوانینی است که در همه زبان های برنامه نویسی باید از آن پشتیبانی شود و استفاده از آن شما را محدود خواهد ساخت.

شکل زیر برای شما روشن کننده خواهد بود:

cls

حالا برای نوشتن کد قابل حمل چه کاری باید انجام داد؟


namespace Sample
{ // Warnings appear because the class is public
 public sealed class SomeLibraryType
 {
 // Warning: Return type of 'SomeLibrary.SomeLibraryType.Abc()'
 // is not CLS-compliant
 public UInt32 Abc()
 {
 return 0;
 }

// Warning: Identifier 'SomeLibrary.SomeLibraryType.abc()'
 // differing only in case is not CLS-compliant
 public void abc()
 {
 }

// No warning: this method is private
 private UInt32 ABC()
 {
 return 0;
 }
 }
}

در کد بالا ما از [assembly: CLSCompliant(true)] به جهت فهماندن به کامپایلر که کد ما قرار از در قالب CLS باشد استفاده کردیم.

کامپایلر دو warning به ما می دهد یکی برای استفاده از unsigned integer چون بعضی از زبان ها قادر به تغییر در مقدار آن نخواهند بود.warning بعدی به جهت استفاده از دو متد کاملا همنام  است که فقط در کوچک و بززگی حرف باهم تفاوت دارند بنابراین ویژول بیسیک برای استفاده از این تایپ به مشکل خواهد خورد.

به این نکته توجه کنید که قوانین CLS برای تایپ هایی که به بیرون از اسمبلی منتشر نمی شود نیست.

در زبان های مختلف برنامه نویسی به جهت استفاده راحت تر و همچنین به کار بردن الگوهای برنامه نویسی مفاهیمی به مانند Enum ,Array ,indexer,delegate,event,properties و … به وجود آمده که در CLR همه اینها باید به فیلد ها و متدهای مناسب تبدیل بشوند.تا CLR یا هر زبان برنامه نویسی دیگری بتواند به آن دسترسی داشته باشد.

به کد زیر دقت کنید:


internal sealed class Test
 { // Constructor
 public Test() { }
 // Finalizer
 ~Test() { }
 // Operator overload
 public static Boolean operator ==(Test t1, Test t2)
 { return true; }
 public static Boolean operator !=(Test t1, Test t2)
 { return false; }
 // An operator overload
 public static Test operator +(Test t1, Test t2) { return null; }
 // A property
 public String AProperty { get { return null; } set { } }
 // An indexer
 public String this[Int32 x] { get { return null; } set { } }
 // An event
 public event EventHandler AnEvent;
 }

اگر کامپایل شده کد بالا را به وسیله ildasm.exe باز کنید:

ildasmهمانطور که مشاهده می کنید به فیلد ها و متدهای معادل در CLR تبدیل شده.

Type member type description
AnEvent Field Event
.ctore Method Counstructor
Finalize Method Filnalizer
add_Event Methos Accessor Method
get_AProperty Method Property Accessor for get
get_Item method Indexer get Accessor
op_Addition Method + operator
op_Equality Method ==Operator
op_Inquality Method != Operator
remove_AnEvent Method Remove Accessor Method
set_Aproperty Method Property set Accessor method
set_Item Method Indexer set accessor method

Common Type System یا CTS چیست؟

تا به اینجا اگر مطالب قبلی ما را خوانده باشید متوجه شده اید که CLR تماما با تایپ ها کار می کند.این تایپ ها هستند که به برنامه ما عملکرد خاص می دهند.تایپ ها در واقع ریشه CLR هستند.

CTS

از این رو  مایکروسافت یک Specification رسمی ایجاد کرده که در آن نشان داده می شود که تایپ ها چگونه تعریف می شوند و چگونه رفتار می کنند.

مایکروسافت این Specification را به مانند سایر  اعضای دات نت برای ECMA ارسال کرده و به نام Common Language Infrastructure باشناسه   ECMA -335 استاندارد سازی شده.

در این استاندارد آمده که شما می توانید یک تایپ داشته باشید که خود آن تایپ باید یک یا صفر member داشته باشد.در پستهای بعدی به بررسی دقیق تر این member ها خواهم پرداخت ولی در زیر مختصر آن ها را شرح خواهم داد.

  • Field:یک متغیر که بخشی از stateیک شئ را نگهداری می کند.
  • Method:متدها عملیاتی برای ما انجام می دهند و اغلب اوقات state یک شئ را برای ما تغییر می دهند.متدها شامل signature و modfire و در صورت بازگشت شامل نوع بازگشتی هستند.
  • Property:این member شبیه به فیلد است ولی با این تفاوت که دارای یک یا دو متد است و  قبل از دسترسی به آن امکان اعتبار سنجی وجود دارد
int _number;
public int Number
{
get
{
return this._number;
}
set
{
this._number = value;
}
}
  • Event:برای notify کردن  از وقوع عملیاتی خاص .

CTS همچنین داردی قوانین حدود دسترسی های اشیا با یکدیگر است.از این رو دسترسی های زیر در CTS آمده است.

  • Private:اعضای یک کلاس فقط و به آن دسترسی دارند.
  • Family:همان protected است و کلاس هایی که از تایپ به ارث برده اند به protected ها دسترسی دارند.بدون در نظر گرفتن اسمبلی.
  • Family and Assembly:در C# از این دسترسی پشتیبانی نمی شود ولی در ILچرا.یعنی member در تمام تایپ های وارث در دسترس است اگر در یک اسمبلی باشد.
  • Assembly:همان internal در c# به این معنی که در دسترس فقط در اسمبلی ها مشترک.
  • Family or Assembly:همان protected internal در C#  به این معنی که در دسترس برای تایپ های وارث و تمام تایپ های یک اسمبلی.
  • Public:در دسترس برای هر کدی در هر اسمبلی

اگر برای تایپی access modifier قرار ندهیم به مانند زیر با آن رفتار می شود:

top level class: internal
method: private
members (unless an interface or enum): private (including nested classes)
members (of interface or enum): public
constructor: private (note that if no constructor is explicitly defined, a public default constructor will be automatically defined)
delegate: internal
interface: internal
explicitly implemented interface member: public

در واقع علاوه بر موضوعات بالا CTS یک سری قوانین برای ارث بری و متد های virtual یا طول عمر یک شی دارد.

به طور مثال می گوید که یک شی باید از یک کلاس یا هیچ کلاس به ارث ببرد و ما نمی توانیم از آن تخطی کینم زیرا clr جلوی ما را میگیرد.

یا باید تمام تایپ ها از یک تایپ به اسم object با واسط با به طور مستقیم به ارث ببرند در این صورت تمامی object یک سری رفتارهای مشخص علاوه بر رفتار خود خواهند داشت.

ما نیازی به یادگیری CTS  و خواندن آن نداریم فقط در همین حد بدانیم که type های استاندارد  و قوانین  کار با آن ها ست کافی است.

Framework class Library

دات نت شامل Framework class Library یا FCL است.FCL  شامل هزاران تایپ است که هر کدام از آن ها امکانی را برای ما فراهم می کند.این مجموعه شامل تایپ های بی نظیر که برای ساخت برنامه هایی از قبیل:

  • Web service
  • Web Site
  • Rich windows GUI application
  • Rich Internet Application
  • Windows Console Application
  • Windows Service
  • Database Stored procedure
  • Component Library

است که می توان از آنها استفاده کرد. به خاطر وجود داشتن تایپ های زیاد مایکروسافت این تایپ ها را در namespace های مختلف دسته بندی کرده.به عنوان مثال namespace به اسم System.

شما برای استفاده از امکانات فریمورک نیاز دارید که از انواع تایپ های آن مطلع باشید در ضمن در صورت نیاز می تواند از آن ها استفاده کرده و تایپ خودتان را بسازید یا رفتار آن ها را تغییر دهید. در لیست پایین تعدادی از نوع های معروف FCL آمده که برای هر کدام توضیح مختصری داده ام.

نوع توضیح
System  ﺗﻤﺎم ﻧﻮعﻫﺎي ﭘﺎﯾﻪ ﮐﻪ ﺗﻮﺳﻂ ﻫﺮ ﺑﺮﻧﺎﻣﻪاي اﺳﺘﻔﺎده ﻣﯽﺷﻮد
System.Data  ﻧﻮعﻫﺎﯾﯽ ﺑﺮاي ﺑﺮﻗﺮاري ارﺗﺒﺎط ﺑﺎ ﭘﺎﯾﮕﺎه داده و ﭘﺮدازش داده
System.IO ﻧﻮعﻫﺎﯾﯽ ﺑﺮاي ورودي ﺧﺮوﺟﯽ و ﮐﺎر ﺑﺎ داﯾﺮﮐﺘﻮريﻫﺎ و ﻓﺎﯾﻞﻫﺎ
System.Net  ﻧﻮعﻫﺎﯾﯽ ﺑﺮاي ارﺗﺒﺎﻃﺎت ﺳﻄﺢ ﭘﺎﯾﯿﻦ ﺷﺒﮑﻪ و ﮐﺎر ﺑﺎ ﭘﺮوﺗﮑﻞﻫﺎي اﯾﻨﺘﺮﻧﺘﯽ
System.Runtime.InteropServices  نﻮعﻫﺎﯾﯽ ﮐﻪ اﺟﺎزه ﻣﯽدﻫﻨﺪ ﮐﺪ ﻣﺪﯾﺮﯾﺖﺷﺪه ﺑﻪ اﻣﮑﺎﻧﺎت ﮐﺪ ﻣﺪﯾﺮﯾﺖﻧﺸﺪهي ﺳﯿﺴﺘﻢ ﻋﺎﻣﻞ ﻣﺜﻞ System.Runtime.InteropServices ﻫﺎي ﺳﻔﺎرﺷﯽ، دﺳﺘﺮﺳﯽ داﺷﺘﻪ ﺑﺎﺷﺪDLLﯾﺎ Win32و ﺗﻮاﺑﻊ COMﮐﺎﻣﭙﻮﻧﻨﺖﻫﺎي
System.Security  ﻧﻮعﻫﺎﯾﯽ ﺑﺮاي ﻣﺤﺎﻓﻈﺖ از دادهﻫﺎ و ﻣﻨﺎﺑﻊ
System.Text  ﻧﻮعﻫﺎﯾﯽ ﺑﺮاي ﮐﺎر ﺑﺎ ﻣﺘﻦ در اﯾﻨﮑﺪﯾﻨﮓﻫﺎي ﻣﺨﺘﻠﻒ
System.Threading ﻧﻮعﻫﺎﯾﯽ ﺑﺮاي ﻋﻤﻠﯿﺎت ﻏﯿﺮ ﻫﻤﺰﻣﺎن و ﻫﻤﺰﻣﺎن ﮐﺮدن دﺳﺘﺮﺳﯽ ﺑﻪ ﻣﻨﺎﺑﻊ
System.Xml ﻧﻮعﻫﺎﯾﯽ ﺑﺮاي ﻋﻤﻠﯿﺎت Extensible Markup Language (XML)</p>

پس FCL  شامل چندین کتابخانه است که در دات نت برای نوشتن برنامه های گوناگون دراختیار ما است.

Memory-Mapped Files چیست؟

شامل محتوای یک فایل در virtual memory است.که این mapping بین فایل و آدرس حافظه است و به برنامه هایی که دارای چند پروسس هستند امکان تغییر در فایل را مسقیما در memory فراهم می کند.

ما دارای دونوع memory-mapped files هستیم:

  • Persisted memory-mapped files:در این حالت فایل داخل memory یا یک فایل روی دیسک ارتباط دارد و در صورتی که آخرین پروسس کارش با با فایل داخل memory  تمام شود داده داخل فایل روی دیسک ذخیره می شود.این حالت برای زمانی مناسب است که ما با فایل ها بزرگ سرو کار داریم.
  • Non-persisted memory-mapped files:در این حالت فایل داخل memory یا یک فایل روی دیسک ارتباط ندارد.و در صورتی که آخرین پروسس کارش با با فایل داخل memory  تمام شود داده داخل فایل روی دیسک ذخیره نمی شود و به فایل به وسیله garbage collection اصلاح می شود وبرای  inter-process communications مناسب هستند.

NGEN.EXE در دات نت

همانطور که در مطلب های پیشین گفته بودم  از NGEN.EXE برای ساخت کد محلی (native code) استفاده می شود در این صورت دیگر نیازی به کامپایل دوباره در زمان اجرا توسط کامپایلر JIT وجود ندارد.

دلایلی که از NGEN.EXE استفاده می شود:

سرعت اجرای برنامه:به دلیل آن که برنامه دیگر نیازی به کامپایل توسط کامپایلر JIT  در زمان اجرا ندارد.

کم شدن حجم کاری برنامه:اگر یک اسمبلی دارید که در چتد پروسس به طور همزمان بارگزاری می شود با NGEN کردن می توان کد محلی آن را  تولید و یک فایل خروجی ساخته و در آدرسی مشخص ذخیره شود.در این حالت فایل ذخیره شده می تواند در Memory-Mapped Files که چند پروسس به آن به طور همزمان دسترسی دارند لود شود و بین پروسس ها یه اشتراک گذاشته شود در این حالت ذیگر نیازی به داشتن یک کپی ازکد به ازای هر پروسس نیست.(در پست بعدی درباره  Memory-Mapped Files توضیح  خواهم داد)

زمانی که یک اسمبلی را به کد محلی تبدیل می کنیم در این حالت یک فایل اسمبلی تولید می کند که آن فایل فقط دارای کد محلی است و در آدرس C:\Windows\Assembly\NativeImages_v4.0.######_64 ذخیره می کند.

در زمانی که CLR می خواهد یک اسمبلی را لود کند نگاه می کند که آیا اسمبلی ngen شده ای هماهنگ با اسمبلی مورد نظر پیدا می کند یا خیر در این صورت اگر پیدا کرد از همان کد استفاده می کند در غیر این صورت این دوباره توسظ  JIT کد کامپایل خواهد شد.

تا به اینجا استفاده از NGEN.EXE به نظر عالی است ولی برخی تصورات اشتباه نیز در استفاده از آن وجود دارد.

  • عدم محافظت از مالکیت معنوی:بسیازی بر این باورند که چون با NGEN می توان کد محلی را ساخت در این حالت می توان اسمبلی اصلی که دارای کد IL است را به مشتری نداد در حالی که آن ها به اشتباه این تصور را دارند زیرا CLR در زمان اجرا نیاز دارد که به متادیتای اسمبلی دسترسی داشته باشد که باید شاملی کد IL نیز باشد از طرفی نمی توان در صورتی که به هر عنوان نتوان کد NGEN شده را مورد استفاده قرار داد JIT کامپایلر باید کد را به زبان محلی تبدیل کند.
  • بروز نبودن فایل ها NGEN شده:زمانی که CLR کد NGEN شده را لود می کند با یک سری فاکتورها کد کامپایل شده را با محیط مقایسه می کند از قبیل:
  1. ورژن CLR
  2. نوع CPU. که با آپگرید سخت افزاری تغییر می کند.
  3. ورژن ویندوز که با سرویس پک تغییر می کند.
  4. ورژن اسمبلی
  5. ورژن اسمبلی های reference داده شده.
  6. امنیت.مثل تغییراتی که روی یکی اسمبلی برای پذیرش کد ناامن انجام شده باشد.

هر کدام از موارد بالا متفاوت باشد  JIT کامپایلر باید کد را به زبان محلی تبدیل کند.

  • کارایی پایین:به دلیل اینکه در زمان کامپایل NGEN هیچ تصوری از محیط اجرا ندارد با کمترین حالت ممکن بهینه سازی کد را کامپایل می کند که در بسیاری از موارد تا ۵ درصد کند تر اجرا می شوند.

توجه کنید که فایل های NGEN شده را نمی توان بین AppDomin های مختلف به اشتراک گذاشت و بنابراین NGEN کردن کاری غیر مفید است.دربرنامه های کلاینت در صورتی که یک اسمبلی توسط چندین برنامه استفاده می شود NGEN  کردن می تواندمفید باشد.

اگر تمام اسمبلی های یک برنامه NGEN  شود دراین حالت CLR دیگر نیازی ندارد تا JIT کامپایلر را لود کند ولی اگر حتی یکی از آن هاNGEN نشده باشند JIT کامپایلر را لود می کند.