نظرات اشتراک‌ها
معرفی کتابخانه‌ی DNTCaptcha.Core
- بسته‌ی coreCompat.Drawing برای NETStandard 1.3. کامپایل شده‌است. یعنی با NET 4.5.1. سازگار است (چون دات نت 4.5.1 هم استاندارد 1.3 را پیاده سازی می‌کند).
+ آیا منظور شما استفاده از برنامه‌های ASP.NET Core ایی است که از Full .NET Framework استفاده می‌کنند؟ یا منظور ASP.NET MVC 5.x است؟
اگر مورد اول مدنظر است، بله، می‌توان با کمی تغییر در نحوه‌ی کامپایل آن، بسته‌ی نیوگت مخصوص آن‌را تولید کرد که از coreCompat.Drawing استفاده نکند و از این لحاظ مشکلی نیست. ولی اگر مورد دوم مدنظر شما است، coreCompat.Drawing فقط یکی از موارد استفاده شده‌است. برای مثال قسمت رمزنگاری آن از IDataProtector استفاده می‌کند که مختص NET Core. است و معادلی در MVC 5.x ندارد و یا نحوه‌ی نمایش آن توسط یک Tag Helper سفارشی ASP.NET Core است.
در کل برای MVC 5.x از مواردی مانند « نحوه ایجاد یک تصویر امنیتی (Captcha) با حروف فارسی در ASP.Net MVC » استفاده کنید.
مطالب
باگ Directory Traversal در سایت
من فایل‌های سایت جاری رو در مسیر استاندارد app_data ذخیره سازی می‌کنم. علت هم این است که این پوشه، جزو پوشه‌های محافظت شده‌ی ASP.NET است و کسی نمی‌تواند فایلی را مستقیما از آن دریافت و یا سبب اجرای آن با فراخوانی مسیر مرتبط در مرورگر شود.
این مساله تا به اینجا یک مزیت مهم را به همراه دارد: اگر شخصی مثلا فایل shell.aspx را در این پوشه ارسال کند، از طریق مرورگر قابل اجرا و دسترسی نخواهد بود و کسی نخواهد توانست به این طریق به سایت و سرور دسترسی پیدا کند.
برای ارائه این نوع فایل‌ها به کاربر، معمولا از روش خواندن محتوای آن‌ها و سپس flush این محتوا در مرورگر کاربر استفاده می‌شود. برای نمونه اگر به لینک‌های سایت دقت کرده باشید مثلا لینک‌های تصاویر آن به این شکل است:
http://site/file?name=image.png
Image.png نام فایلی است در یکی از پوشه‌های قرار گرفته شده در مسیر app_data.
File هم در اینجا کنترلر فایل است که نام فایل را دریافت کرده و سپس به کمک FilePathResult و return File آن‌را به کاربر ارائه خواهد داد.
تا اینجا همه چیز طبیعی به نظر می‌رسد. اما ... مورد ذیل چطور؟!


لاگ خطاهای فوق مرتبط است به سعی و خطای شب گذشته یکی از دوستان جهت دریافت فایل web.config برنامه!
متدهای Server.MapPath یا متد return File و امثال آن تمامی به کاراکتر ویژه ~ (اشاره‌گر به ریشه سایت) به خوبی پاسخ می‌دهند. به عبارتی اگر این بررسی امنیتی انجام نشده باشد که کاربر چه مسیری را درخواست می‌کند، محتوای کامل فایل web.config برنامه به سادگی قابل دریافت خواهد بود (به علاوه هر آنچه که در سرور موجود است).

چطور می‌شود با این نوع حملات مقابله کرد؟
دو کار الزامی ذیل حتما باید انجام شوند:
الف) با استفاده از متد Path.GetFileName نام فایل را از کاربر دریافت کنید. به این ترتیب تمام زواید وارد شده حذف گردیده و فقط نام فایل به متدهای مرتبط ارسال می‌شود.
ب) بررسی کنید مسیری که قرار است به کاربر ارائه شود به کجا ختم شده. آیا به c:\windows اشاره می‌کند یا مثلا به c:\myapp\app_data ؟
اگر به لاگ فوق دقت کرده باشید تا چند سطح بالاتر از ریشه سایت هم جستجو شده.


نتیجه گیری:
اگر در برنامه‌های وب خود (فرقی نمی‌کند مرتبط به چه فناوری است)، نام فایلی را از کاربر جهت ارائه محتوایی به او دریافت و از این نام فایل بدون هیچ نوع بررسی خاصی، مستقیما در برنامه استفاده می‌کنید، برنامه شما به مشکل امنیتی Directory Traversal مبتلا است.


پ.ن.
1- این باگ امنیتی در سایت وجود داشت که توسط یکی از دوستان در روزهای اول آن گزارش شد؛ ضمن تشکر!
2- از این نوع اسکن‌ها در لاگ‌های خطاهای سایت جاری زیاد است. برای مثال به دنبال فایل‌هایی مانند DynamicStyle.aspx و css.ashx یا theme.ashx می‌گردند. حدس من این است که در یکی از پرتال‌های معروف یا افزونه‌های این نوع پرتال‌ها فایل‌های یاد شده دارای باگ فوق هستند. فایل‌های ashx عموما برای flush یک فایل یا محتوا به درون مرورگر کاربر در برنامه‌های ASP.NET Web forms مورد استفاده قرار می‌گیرند.
 
مطالب
آشنایی با ساختار IIS قسمت سیزدهم
در مبحث قبلی گفتیم که ویرایش تنظیمات لاگ‌ها از طریق IIS یا ویرایش مستقیم فایل‌های کانفیگ میسر است. در این مقاله که قسمت پایانی مبحث لاگ هاست، در مورد ویرایش فایلهای کانفیگ صحبت می‌کنیم؛ همچنین استفاده از دستورات appcmd برای ویرایش و نهایتا کد نویسی در زبان سی شارپ و جاوااسکریپت.
تنظیمات لاگ سایت‌ها در فایل applicationhost در آدرس زیر قرار دارد:
C:\Windows\System32\inetsrv\config\applicationHost.config
برای هر تگ سایت، یک تگ <logfile> وجود دارد که ویژگی‌های Attributes آن، نوع ثبت لاگ را مشخص می‌کنند و می‌توانید مستقیما در اینجا به ویرایش بپردازید. البته ویرایش فایل کانفیگ از طریق IIS به طور مستقیم هم امکان پذیر است. برای این منظور در IIS سرور را انتخاب و از بین ماژول‌های قسمت management گزینه‌ی Configuration Editor را انتخاب کنید. در قسمت Section گزینه‌ی System.applicationhost را باز کرده و از زیر مجموعه‌های آن گزینه‌ی Site را برگزینید. در تنظیمات باز شده، گزینه collection را انتخاب کنید تا در انتهای سطر، دکمه‌ی ... پدیدار گردد. روی آن کلیک کنید تا محیطی ویرایشی باز گردد که به شما اجازه‌ی افزودن و ویرایش خصوصیت‌ها را می‌دهد. برای ویرایش لاگ‌ها باید خصوصیت logfile را باز کنید. اگر قسمت قبلی را مطالعه کرده باشید، باید بسیاری از این خصوصیت‌ها و مقادیر را بشناسید.
خصوصیات دیگری را هم مشاهده خواهید کرد که شاید قبلا ندیده‌اید که البته بستگی به ورژن IIS  شما دارد؛ مثلا خصوصیت‌های maxLogLineLength و flushByEntryCountW3Clog از IIS8.5 اضافه شده اند.

جدول خصوصیت ها
 خصوصیت توضیح 
 customLogPluginClsid   یک پارامتر رشته‌ای اختیاری که در آن، آی دی کلاس یا کلاس‌هایی نوشته می‌شود که برای custom logging نوشته شده‌اند و این گزینه ترتیب اجرای آن‌ها را تعیین می‌کند.
 directory   اختیاری است. محل ذخیره‌ی لاگ فایل‌ها را مشخص می‌کند و در صورتیکه ذکر نشود، همان مسیر پیش فرض است.
 enabled   اختیاری است. فعال بودن سیستم لاگ برای آن سایت را مشخص می‌کند. مقدار پیش فرض آن true است.
 flushByEntryCountW3CLog   این مقدار مشخص می‌کند چند رخداد باید اتفاق بیفتد تا عمل ذخیره سازی لاگ صورت گیرد. اگر بعد از هر رخداد عمل ثبت لاگ انجام شود، سرعت ثبت لاگ‌ها بالا می‌رود؛ ولی باعث استفاده‌ی مداوم از منابع و همچنین درخواست ثبت اطلاعات را روی دیسک خواهد داد و تاوان آن با زیاد شدن عملیات روی دیسک، پرداخته خواهد شد. ولی در حالتیکه چند رخداد را نگهداری  سپس دسته‌ای ثبت کند، باعث افزایش کارآیی و راندمان سرور خواهد شد. در صورتیکه سرور به مشکلات لحظه‌ای برخورد می‌کند مقدار آن را کاهش دهید. مقدار پیش فرض 0 است. یعنی اینکه ثبت، بعد از 64000 لاگ خواهد بود.
 localTimeRollover   نحوه‌ی نامگذاری فایل‌های لاگ را مشخص می‌کند که مقدار بولین گرفته و اختیاری است. به طور پیش فرض مقدار false دارد.
 logExtFileFlags   این گزینه در حالتی به کارتان می‌آید که فرمت W3C را برای ثبت لاگ‌ها انتخاب کرده باشید و در اینجا مشخص می‌کنید که چه فیلدهایی باید در لاگ باشند و اگر بیش از یکی بود میتوان با ، (کاما) از هم جدایشان کرد.
 logFormat  نوع فرمت ذخیره سازی لاگ‌ها
 logSiteId  اختیاری است و مقدار پیش فرض آن true است. بدین معنا که کد یا شماره‌ی سایت هم در لاگ خواهد بود و این در حالتی است که گزارش در سطح سرور باشد. در غیر این صورت اگر هر سایت، جداگانه لاگی برای خود داشته باشد، ذکر نمی‌گردد.
 logTargetW3C   اختیاری است و و مقدار file و *ETW را می‌گیرد که به طور پیش فرض روی File تنظیم است. در این حالت فایل لاگ‌ها در یک فایل متنی توسط http.sys ذخیره می‌شود. ولی موقعیکه از ETW استفاده می‌شود، http.sys با استفاده از iislogprovider داده‌ها را به سمت ETW ارسال میکند که منجر به اجرای سرویس Logsvc شده که از داده‌ها کوئری گرفته و آن‌ها را مستقیما از پروسه‌های کارگر جمع آوری و به سمت فایل لاگ ارسال می‌کند. همچنین انتخاب این دو گزینه نیز ممکن است.
 maxLogLineLength  حداکثر تعداد خطی که یک لاگ میتواند داشته باشد تا اینکه بتوانید در مصرف دیسک سخت صرفه جویی کنید و بیشتر کاربرد آن برای لاگ‌های کاستوم است. این عدد باید از نوع Uint باشد و اختیاری است و از 2 تا 65536 مقدار میپذیرد که مقدار پیش فرض آن 65536 می‌باشد.
 period   همان مبحث زمان بندی در مورد ایجاد فایل‌های لاگ است که در مقاله‌ی پیشین برسی کردیم و مقادیر Dialy,Hourly,monthlyو weekly را می‌پذیرد. همچنین maxsize هم هست؛ موقعی که لاگ به نهایت حجمی که برای آن تعیین کردیم میرسد.
 truncateSize   اختیاری است و مقدار آن از نوع int64 است. حداکثر حجم یک فایل لاگ را مشخص می‌کند تا اگر period روی maxsize تنظیم شده بود، حداکثر حجم را میتوان از اینجا تعیین نمود. در مقاله پیشین در این باره صحبت کردیم؛ حداقل عدد برای آن 1,048,576 است و اگر کمتر از آن بنویسید، سیستم همین عدد 1,048,576 را در نظر خواهد گرفت. مقدار پیش فرض آن 20971520 می باشد.
* ETW یا  Event Tracing Windows، سیستم و یا نرم افزاری برای عیب یابی و نظارت برای کامپوننت‌های ویندوزی است و یکی از استفاده کننده‌هایش IIS است  که از ویندوز 2000 به بعد اضافه شده‌است. برای قطع کردن این ماژول در IIS هم میتوانید  قسمت هفتم  را بررسی نمایید و دنیال ماژول TracingModule  بگردید. این ماژول به صورت Real time به ثبت رخدادهای IIS می‌پردازد.

به غیر از خصوصات بالا، خصوصیت customFields نیز از IIS 8.5 (به بعد) در دسترس است. اگر قصد دارید به غیر از فیلدهای W3c فیلدهای اختصاصی دیگری نیز داشته باشید، میتوان از این گزینه استفاده کرد. این فیلدهای کاستوم می‌توانند اطلاعاتشان را از request header ، response header و server variables دریافت کنند. این ویژگی تنها در فرمت W3C و در سطح سایت قابل انجام است. موقعی که یک فایل لاگ شامل فیلدهای اختصاصی شود، به انتها نام فایل X_ اضافه میگردد تا نشان دهد شامل یک فیلد اختصاصی یا کاستوم است. نحوه تعریف آن در فایل applicationhost به شکل زیر است:
<system.applicationHost>
   <sites>
      <siteDefaults>
         <logFile logFormat="W3C"
            directory="%SystemDrive%\inetpub\logs\LogFiles"
            enabled="true">
            <customFields>
               <clear/>
               <add logFieldName="ContosoField" sourceName="ContosoSource"
                  sourceType="ServerVariable" />
            </customFields>
         </logFile>
      </siteDefaults>
   </sites>
</system.applicationHost>

تغییر تنظمیات لاگ با Appcmd
appcmd.exe set config -section:system.applicationHost/sites /siteDefaults.logFile.enabled:"True" /commit:apphost
appcmd.exe set config -section:system.applicationHost/sites /siteDefaults.logFile.logFormat:"W3C" /commit:apphost
appcmd.exe set config -section:system.applicationHost/sites /siteDefaults.logFile.directory:"%SystemDrive%\inetpub\logs\LogFiles" /commit:apphost

تنظمیات تگ لاگ با برنامه نویسی و اسکریپت نویسی
هچنین با رفرنس Microsoft.web.administration در پروژه‌های دات نتی خود میتوانید امکان ویرایش تنظیمات را در برنامه‌های خود نیز داشته باشید:
using System;
using System.Text;
using Microsoft.Web.Administration;

internal static class Sample
{
   private static void Main()
   {
      using (ServerManager serverManager = new ServerManager())
      {
         Configuration config = serverManager.GetApplicationHostConfiguration();
         ConfigurationSection sitesSection = config.GetSection("system.applicationHost/sites");
         ConfigurationElement siteDefaultsElement = sitesSection.GetChildElement("siteDefaults");

         ConfigurationElement logFileElement = siteDefaultsElement.GetChildElement("logFile");
         logFileElement["logFormat"] = @"W3C";
         logFileElement["directory"] = @"%SystemDrive%\inetpub\logs\LogFiles";
         logFileElement["enabled"] = true;

         serverManager.CommitChanges();
      }
   }
}

با استفاده از اسکریپت نویسی توسط جاوااسکریپت و وی بی اسکریپت هم نیز این امکان مهیاست:
var adminManager = new ActiveXObject('Microsoft.ApplicationHost.WritableAdminManager');
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST";
var sitesSection = adminManager.GetAdminSection("system.applicationHost/sites", "MACHINE/WEBROOT/APPHOST");
var siteDefaultsElement = sitesSection.ChildElements.Item("siteDefaults");

var logFileElement = siteDefaultsElement.ChildElements.Item("logFile");
logFileElement.Properties.Item("logFormat").Value = "W3C";
logFileElement.Properties.Item("directory").Value = "%SystemDrive%\\inetpub\\logs\\LogFiles";
logFileElement.Properties.Item("enabled").Value = true;

adminManager.CommitChanges();

FTP Logging
برای اطمینان از نصب Ftp logging موقع نصب، باید از مورد زیر مطمئن باشید:

IIS را باز کنید و در لیست درختی، سرور را انتخاب کنید. در قسمت FTP میتوانید گزینه‌ی Ftp logging را ببینید. تنظیمات این قسمت هم دقیقا همانند قسمت logging میباشد و همان موارد برای آن هم صدق می‌کند.


بررسی تگ آن در applicationhost

تگ این نوع لاگ در فایل applicationhost در زیر مجموعه‌ی تگ <site> به شکل زیر نوشته می‌شود:

<system.ftpServer>
   <log centralLogFileMode="Central">
      <centralLogFile enabled="true" />
   </log>
</system.ftpServer>

گزینه centralLogFileMode  دو مقدار central و site را می‌پذیرد. اگر گزینه‌ی central انتخاب شود، یعنی همه‌ی لاگ‌ها را داخل یک فایل در سطح سرور ثبت کن ولی اگر گزینه‌ی site انتخاب شده باشد، لاگ هر سایت در یک فایل ثبت خواهد شد.

گزینه‌ی logInUTF8  یک خصوصیت اختیاری است که مقدار پیش فرض آن true میباشد. در این حالت باید تمامی رشته‌ها به انکدینگ UTF-8 تبدیل شوند.

همانطور که می‌بینید تگ log در بالا یک تگ فرزند هم به اسم centralLogFile دارد که همان خصوصیات جدول بالا در آن مهیاست.


دسترسی به تنظیمات این قسمت توسط دستور Appcmd: 

appcmd.exe set config -section:system.ftpServer/log /centralLogFileMode:"Central" /commit:apphost

appcmd.exe set config -section:system.ftpServer/log /centralLogFile.enabled:"True" /commit:apphost


دسترسی به تنظیمات این قسمت توسط دات نت:

using System;
using System.Text;
using Microsoft.Web.Administration;

internal static class Sample
{
   private static void Main()
   {
      using (ServerManager serverManager = new ServerManager())
      {
         Configuration config = serverManager.GetApplicationHostConfiguration();

         ConfigurationSection logSection = config.GetSection("system.ftpServer/log");
         logSection["centralLogFileMode"] = @"Central";

         ConfigurationElement centralLogFileElement = logSection.GetChildElement("centralLogFile");
         centralLogFileElement["enabled"] = true;

         serverManager.CommitChanges();
      }
   }
}


دسترسی به تنظیمات این قسمت توسط Javascript: 

var adminManager = new ActiveXObject('Microsoft.ApplicationHost.WritableAdminManager');
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST";

var logSection = adminManager.GetAdminSection("system.ftpServer/log", "MACHINE/WEBROOT/APPHOST");
logSection.Properties.Item("centralLogFileMode").Value = "Central";

var centralLogFileElement = logSection.ChildElements.Item("centralLogFile");
centralLogFileElement.Properties.Item("enabled").Value = true;

adminManager.CommitChanges();
مطالب
خلاصه اشتراک‌های روز جمعه 13 آبان 1390

مطالب
اجزاء معماری سیستم عامل اندروید (قسمت اول معماری امنیتی اندروید) :: بخش سوم
همانطور که در مطالب قبلی توضیح داده شد، اندروید بر روی هسته‌ی لینوکس نگارش 2.6 به بالا اجرا می‌شود. در این مطلب قصد داریم تا نگاهی به معماری امنیتی اندروید داشته باشیم.
Privilege Separation به چه معناست؟
هسته‌ی اندروید یک مدل جداسازی امتیازی (Privilege separation) را در زمان اجرای برنامه‌های کاربردی اجرا می‌کند. این مورد به این معنا است که مانند سیستم یونیکس، سیستم‌عامل اندروید به یک برنامه نیاز دارد تا تنها با شناسه‌ی کاربر خود و شناسه‌ی گروه خاص خودش اجرا شود. بخش‌های معماری سیستم اندروید به این روش از هم جدا شده‌اند. Privilege Separation یک ویژگی امنیتی مهم است؛ زیرا رایج‌ترین انواع حملات را انکار می‌کند و در نتیجه یکی از اولویت‌های یک برنامه می‌باشد. از آنجایی که عملیات جداسازی امتیازی را هسته انجام می‌دهد، لذا این مورد یکی از مباحث پر اهمیت در طراحی هسته می‌باشد که به شدت مورد توجه خواهد بود. تنها فلسفه پشت این طرح این است که اطمینان حاصل شود، هیچ برنامه‌ی کاربردی نمی‌تواند به کد یا داده‌های دیگر برنامه‌ها و یا به دستگاه کاربر و یا خود سیستم نفوذ کند. یک برنامه ممکن است مستقیما از فهرست تماس دستگاه یا تقویم خوانده نشود! این ویژگی همچنین به عنوان sandboxing شناخته می‌شود.
Permissions چگونه کار می‌کند؟
اجازه دهید با یک مثال ساده توضیح دهم: ما برنامه‌ای را داریم که صدا را ضبط کرده و آن‌را از طریق میکروفن دستگاه پخش می‌کند. برای اینکه برنامه به‌درستی کار کند، توسعه دهنده باید یک درخواست دسترسی به RECORD_AUDIO را برای اجازه دسترسی به ضبط صدا، در فایل AndroidManifest.xml بفرستد. این کار به برنامه ما اجازه می‌دهد تا از مؤلفه‌های سیستم که ضبط صدا را کنترل می‌کنند، استفاده کنیم. یک سؤال اینجا مطرح می‌شود که «چه کسی تصمیم می‌گیرد که این دسترسی داده شود یا اینکه تکذیب شود؟»
فقط و فقط هسته‌ی اندروید به کاربر نهایی اجازه می‌دهد تا این فرآیند تایید نهایی را انجام دهد؛ نه هیچ سیستم دیگر یا کاربر دیگری! زمانیکه کاربر، برنامه ما را نصب می‌کند، این کار او را تشویق می‌کند تا این عملیات را انجام دهد. به این نکته دقت کنید که عجله ای برای این دسترسی وجود ندارد و هر زمانیکه برنامه نصب شد، اتفاق خواهد افتاد و این مجوز دسترسی تنها در زمان نصب به کاربر داده می‌شود نه قبل از آن. (به تصویر زیر دقت کنید)

 اگر ما درخواست خود را برای دسترسی به RECORD_AUDIO ثبت نکنیم یا اگر صاحب دستگاه تائید نکند که پس از درخواست ما اجازه استفاده از آن را بدهد، آنگاه یک استثناء به حافظه‌ی مجازی (VM) داده خواهد شد و برنامه با شکست روبرو می‌شود. این مفهوم برای توسعه دهنده‌است که بداند در خواستی را صادر کرده است یا خیر؟ پس برای درخواست مجوز مورد نظر باید برچسب زیر، در فایل AndroidManifest.xml درج شود.
<uses-permission android:name="android.permission.RECORD_AUDIO" />

Application Code Signing
هر برنامه‌ی کاربردی که بر روی سیستم‌عامل اندروید اجرا می‌شود، باید امضاء شود. اندروید از گواهی توسعه دهندگان فردی برای شناسایی آن‌ها و ایجاد روابط اعتمادسازی استفاده می‌کند که در میان کاربردهای مختلفی که در سیستم‌عامل اجرا می‌شوند پیاده می‌شود. 
سیستم‌عامل مجاز به اجرای برنامه‌ای بدون امضاء نخواهد بود. 
استفاده‌ی از یک مرجع، برای صدور امضای یک برنامه لازم نیست؛ چرا که سیستم امنیتی اندروید تنها از یک امضای تک گانه که توسعه دهنده در برنامه قرار داده‌است پیروی می‌کند! مجوزهای کنترلی برنامه مانند امضاء در طول نصب برنامه از طریق هسته‌ی اندروید بررسی شده و ضمانت و تایید خواهند شد. تمامی این فرآیندها به صورت خودکار و بلادرنگ در پشت پرده به سرعت اتفاق می‌افتند! در این صورت اگر گواهی اعتماد (certificate) توسط توسعه دهنده منقضی شود و یا به نحوی مورد اطمینان برای دستگاه نباشد، تمامی عملیات‌های ذکر شده بر روی برنامه به صورت عادی، ادامه خواهند یافت.
مطالب
بررسی تغییرات Reflection در NET Core.
API کار با امکانات Reflection نیز در NET Core. نسبت به نگارش کامل دات نت، دارای تغییراتی است که در ادامه مهم‌ترین‌های آن‌ها را بررسی خواهیم کرد.


پیشنیازهای کار با Reflection در NET Core.

ابتدا نیاز است اسمبلی System.Reflection به قسمت وابستگی‌های فایل project.json اضافه شود:
"dependencies": {
    "System.Reflection": "4.3.0"
},
البته اگر وابستگی دیگری در فایل project.json، این وابستگی را پیشتر مورد استفاده قرار داده باشد، نیازی به ذکر مجدد آن نیست. برای این منظور می‌توان فایل project.lock.json را جهت یافتن مدخل System.Reflection بررسی کرد. اگر این مدخل در فایل lock موجود بود، توسط پروژه قابل دسترسی است و نیازی به ذکر صریح آن نخواهد بود.
پس از این مورد، ذکر فضای نام System.Reflection را در ابتدای کدها نیز فراموش نکنید. همین مورد بسیاری از خطاهای انتقال کدها را بدون تغییری برطرف می‌کند:
 using System.Reflection;


نوشتن کدهای شرطی، برای کامپایل یک کد، مخصوص فریم ورک‌های مختلف

در کدهای سی شارپ می‌توان توسط if# و else#، کامپایلر را جهت استفاده یا عدم استفاده‌ی کدهای نوشته شده، راهنمایی کرد. برای این منظور در NET Core.، به فایل project.json مراجعه کرده و ثابت دلخواهی را به نام COREFX به قسمت buildOptions اضافه می‌کنیم.
"buildOptions": {
   "define": [ "COREFX" ]
},
 پس از تعریف ثابت COREFX، اکنون نحوه‌ی استفاده‌ی از آن به صورت ذیل خواهد بود:
 #if COREFX
 // corefx codes
#else
 // other frameworks
#endif
از این روش می‌توان برای کامپایل یک فایل کد cs، جهت فریم ورک‌های مختلف استفاده کرد. در حالت فوق، کامپایلر فقط قسمت if# را پردازش کرده و از قسمت else# به طور کامل صرفنظر خواهد کرد.


اضافه شدن متدهای GetMethodInfo و GetTypeInfo

بسیاری از امکانات System.Type نگارش کامل دات نت به TypeInfo در NET Core. منتقل شده‌اند. برای مثال بجای کد پیشین
 var members = obj.GetType().GetMembers();
اینبار باید نوشت
 var members = obj.GetType().GetTypeInfo().GetMembers();
و یا نمونه‌ی if/else دار آن به صورت ذیل خواهد بود:
 #if COREFX
 toType.GetTypeInfo().IsGenericType
#else
 toType.IsGenericType
#endif
در اینجا قسمت if جهت NET Core. نوشته شده‌است و قسمت else برای نگارش کامل دات نت قابل استفاده خواهد بود.


یافتن اسمبلی جاری

در NET Core. متد GetExecutingAssembly حذف شده‌است و باید ابتدا نوع کلاس جاری را یافت و سپس توسط GetTypeInfo به Assembly آن دسترسی یافت:
 #if COREFX
 return typeof(MyClassName).GetTypeInfo().Assembly;
#else
 return System.Reflection.Assembly.GetExecutingAssembly();
#endif


خلاصه‌ی بحث

برای تبدیل کدهای مبتنی بر Reflection موجود، ابتدا از وجود وابستگی System.Reflection اطمینان حاصل کرده، فضای نام آن‌‌را الحاق و در موارد جزئی نیاز است از متد GetTypeInfo برای دسترسی به خواص API قبلی استفاده کرد.
نظرات مطالب
آشنایی با NHibernate - قسمت اول
@DotNetCoders
سورس اصلی کتابخانه، به زبان سی شارپ است اما نهایتا شما از اسمبلی‌های کامپایل شده مربوطه استفاده خواهید کرد و از اینجا به بعد دیگر تفاوتی نمی‌کند که زبان دات نتی مورد استفاده چی باشد.

@dadoo
باید دقت داشته باشید که LINQ به تنهایی فقط یک language feature است و نه یک data access technology . بنابراین باید دقیقا linq to sql یا linq to entities را مشخص کرد.
سابقه نزدیک به یک دهه پروژه اصلی Hibernate‌ که توسط جاوا کارها توسعه داده شده، در این فریم ورک لحاظ شده که از هر لحاظ نسبت به LINQ to entities اون رو پخته‌تر کرده. ضمنا پروایدر LINQ هم برای NH اخیرا توسعه داده شده و از این لحاظ کم و کسری ندارد.
linq to sql برای اس کیوال سرور توسعه داده شد. بعد مایکروسافت اومد اون رو با linq to entities تکمیل کرد (البته linq to sql مطابق وبلاگ رسمی برنامه نویس‌های MS هنوز هم توسعه پیدا می‌کنه و در دات 4 شاهد اون خواهیم بود) و توسط linq to entities امکان استفاده از سایر دیتابیس‌ها هم فراهم شده البته اگر پروایدر آن موجود باشد که تعدادی از آن‌ها هم تجاری هستند. اما با NH این مشکل رو ندارید چون تقریبا همه نوع دیتابیس معروفی را ساپورت می‌کند و رایگان هم هست.
learning curve مربوط به NH بیشتر است از سایر orm ها.
NH از دات نت فریم 2 به بعد را پشتیبانی می‌کند اما linq to entities فقط از دات نت فریم ورک سه و نیم سرویس پک یک به بعد به صورت کامل در دسترس است.

در کل در گوگل nhibernate vs linq را جستجو کنید.

@LoveAjax
محیط مدیوم تراست، امکان ریفلکشن رو حذف می‌کنه و این مورد برای NH و تمام ORM های دیگر نیز مساله ساز خواهد بود. اما برای NH راه حل دارد مطابق مستندات آن:
http://nhforge.org/wikis/howtonh/run-in-medium-trust.aspx
نظرات مطالب
سایت‌های مهمی که از ASP.NET MVC استفاده می‌کنند
بعید می‌دونم. علتش به توسعه پذیری SharePoint بر می‌گرده که بر اساس معماری وب فرم‌ها از ابتدا طراحی شده. اگر بروند سراغ MVC تمام افزونه‌های قبلی از کار می‌افته یا به شدت مشکل پیدا می‌کنند. ضمن اینکه SharePoint پلتفرم واقعا عظیمی است. خیلی هزینه‌بر است تبدیل آن.
برای مثال شاید همین سوال در مورد IE هم باشد. چرا IE رو با دات نت نمی‌نویسند؟ علتش این است که بعد از این همه سال میلیون‌ها دلار خرج code base آن شده. دور ریختن و دل کندن از آن واقعا سخت است.
نظرات مطالب
مروری بر چند تجربه‌ی کاری با SQLite
- خیر. تمام نگارش‌های Access مد نظر بودند. برای نمونه به برنامه معروف زیر مراجعه کنید :
http://www.elcomsoft.com/aopr.html
- در مورد رمزنگاری هم بله. یک ماژول تجاری همانطور که عرض کردم توسط نویسنده‌ی اصلی آن فروخته می‌شود یا پروایدری که شما عنوان کردید هم با استفاده از windows crypto api ، رمزنگاری را اعمال می‌کند که در این حالت دیتابیس شما فقط منحصر به ویندوز خواهد شد و برای استفاده از آن در MONO مشکل خواهید داشت.