مطالب
میان‌افزار جدید Authorization در ASP.NET Core 3.0
در نگارش‌های اولیه‌ی ASP.NET Core، پشتیبانی از authorization، صرفا توسط ویژگی [Authorize]، قابل اعمال به اکشن متد خاصی بود. برای بهبود تنظیم این قابلیت، میان‌افزار جدید Authorization به ASP.NET Core 3.0 اضافه شده‌است و تنظیم آن جهت کار با امکانات امنیتی برنامه، الزامی است؛ در غیر اینصورت در حین مرور این صفحات و قسمت‌های محافظت شده، برنامه با خطای زیر متوقف خواهد شد:
Endpoint xyz contains authorization metadata, but a middleware was not found that supports authorization.
Configure your application startup by adding app.UseAuthorization() inside the call to Configure(..) in the application startup code.


محل صحیح تعریف میان‌افزار Authorization در ASP.NET Core 3.0

توصیه شده‌است میان‌افزار جدید Authorization، با فراخوانی متد UseAuthorization، بلافاصله پس از فراخوانی متد UseAuthentication معرفی شود. در این حالت این میان‌افزار، با یک Policy پیش‌فرض تنظیم می‌شود که قابل تغییر و بازنویسی است:
public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}
در مورد مفهوم متد MapDefaultControllerRoute، می‌توانید به نظرات تکمیلی مطلب Endpoint routing مراجعه کنید.
در ASP.NET Core 3.0، پس از تنظیمات فوق است که قطعه کد زیر و اعمال فیلتر Authorize، مجددا کار می‌کند:
public class HomeController : ControllerBase
{
    [Authorize]
    public IActionResult BuyWidgets()
    {
        ...
    }
}


روش تعریف فیلتر Authorize به صورت سراسری در ASP.NET Core 3.0

می‌توان AuthorizeFilter را به صورت یک فیلتر سراسری (global filter in MVC) تعریف کرد تا به تمام کنترلرها و اکشن متدها اعمال شود. هرچند این روش هنوز هم در ASP.NET Core 3.0 کار می‌کند، اما روش توصیه شده‌ی جدید آن به صورت زیر است:
public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute().RequireAuthorization();
    });
}
در این حالت با اعمال RequireAuthorization به MapDefaultControllerRoute، سبب خواهیم شد تا اعتبارسنجی کاربر برای استفاده‌ی از تمام قسمت‌های برنامه، اجباری شود. در این بین اگر کنترلری و یا اکشن متدی نباید محافظت شود و دسترسی آزادانه‌ی به آ‌ن‌ها مدنظر است، می‌توان از فیلتر AllowAnonymous استفاده کرد:
[AllowAnonymous]
public class HomeController : ControllerBase
{
    ...
}


سفارشی سازی سیاست‌های Authorization در ASP.NET Core 3.0

اگر بخواهیم DefaultPolicy میان‌افزار Authorization را بازنویسی کنیم، می‌توان از متد services.AddAuthorization به صورت زیر استفاده کرد که در آن authentication و داشتن یک Scope خاص را اجباری می‌کند:
public void ConfigureServices(IServiceCollection services)
{
    ...
    
    services.AddAuthorization(options =>
    {
        options.DefaultPolicy = new AuthorizationPolicyBuilder()
          .RequireAuthenticatedUser()
          .RequireScope("MyScope")
          .Build();
    });
}


تنظیم سیاست‌های دسترسی، زمانیکه هیچ نوع تنظیمی از پیش تعریف نشده‌است

با تنظیم FallbackPolicy، می‌توان تمام endpointهایی را که توسط فیلتر [Authorize] و یا ()RequireAuthorization محافظت نشده‌اند، محافظت کرد.
DefaultPolicy توسط فیلتر [Authorize] و یا ()RequireAuthorization مورد استفاده قرار می‌گیرد؛ اما FallbackPolicy زمانی بکار خواهد رفت که هیچ نوع سیاست دسترسی تنظیم نشده‌باشد. حالت پیش‌فرض FallbackPolicy، پذیرش تمام درخواست‌ها بدون اعتبارسنجی است.
کارکرد مثال زیر با مثال‌های قبلی که از DefaultPolicy استفاده می‌کردند، یکی است و هدف آن، اجبار به اعتبارسنجی کاربران در همه‌جا (تمام endpoints)، منهای مواردی است که از فیلتر AllowAnonymous استفاده می‌شود:
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthorization(options =>
    {
        options.FallbackPolicy = new AuthorizationPolicyBuilder()
          .RequireAuthenticatedUser()
          .RequireScope("MyScope")
          .Build();
    });
}

public void Configure(IApplicationBuilder app)
{
    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

[AllowAnonymous]
public class HomeController : ControllerBase
{
}


امکان اعمال سفارشی میان‌افزار Authorization به Endpointهای مجزا

برای مثال در مبحث «بررسی سلامت برنامه»، فریم‌ورک، اعتبارسنجی درخواست‌های آن‌را پیش بینی نکرده‌است؛ اما اینبار می‌توان اعتبارسنجی را به endpoint آن اعمال کرد:
public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints
            .MapHealthChecks("/healthz")
            .RequireAuthorization(new AuthorizeAttribute(){ Roles = "admin", });
    });
}
همانطور که مشاهده می‌کنید، در اینجا RequireAuthorization، به صورت سفارشی به یک endpoint خاص اعمال شده‌است و تنظیمات آن، با تنظیمات سایر قسمت‌های برنامه یکی نیست.
مطالب
معماری اطلاعات (Information Architecture)

معماری اطلاعات یا Information Architecture و یا به اختصار IA در یک تیم توسعه نرم‌افزار، یک وظیفه پایه و اساسی است که معمولا بین طراحان، توسعه دهندگان و یا طراحان استراتژی محتوا تقسیم می‌گردد. اما صرف نظر از اینکه چه کسی در یک تیم آن را بر عهده می‌گیرد، IA تخصص خاص خود را نیازمند است که این تخصص که شامل ابزارها و شاخص‌ها و منابعی است که باید به درستی تحقیق و گردآوری گردند. در این مقاله قصد داریم تا به این امر بپردازیم که واقعا IA چیست؟ و چرا یک جنبه‌ی مهم و ارزشمند در طراحی فرآیندهای user experience به شمار می‌رود؟


Information Architecture چیست؟

بیان کردن یک تعریف دقیق برای IA کمی پیچیده‌تر از تعاریف دیگری همچون content strategy و یا interaction design به نظر می‌رسد. بر خلاف content strategy که به وسیله طراحان استراتژی محتوا و یا interaction design که توسط طراحان UI/UX انجام می‌گیرد، IA به ندرت در زمره‌ی یک کار جداگانه قرار می‌گیرد. اما با این وجود، این کار در مهندسی نرم افزار بسیار با ارزش و لازم محسوب می‌گردد. (منبع)

بر اساس تعریف ویکی‌پدیا، IA اینگونه تعریف می‌گردد: "معماری اطلاعات عبارت است از طراحی ساختاری سامانه‌های اشتراک اطلاعات، که با هدف یافت پذیری و کاربرد پذیری انجام می‌شود."

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

مفهوم کاربرد‌پذیری یا Usability ، شاخصه‌ای است که میزان سهولت کاربری یک ابزار را نشان می‌دهد. این تعریف را می‌توان به این صورت کامل نمود: "میزانی که یک محصول می‌تواند توسط کاربران خاصی برای رسیدن به هدفی مشخص مورد استفاده قرار گیرد و در حین استفاده، ضمن داشتن اثربخشی و کارآیی، رضایت کاربر را در زمینه مورد استفاده تامین کند." به عنوان مثال هنگامیکه شما قصد خرید اینترنتی را داشته باشید، در درجه اول مفهوم یافت‌پذیری برای شما پررنگ خواهد شد و پس از آن با انجام خرید حس کاربردپذیری فروشگاه خواهد بود که برای دفعات بعدی شما را به آن وب‌سایت هدایت خواهد کرد.

بنا بر آنچه که گفته شد، مفهوم یافت‌پذیری مقدم بر کاربرد‌پذیری است. یعنی اگر کاربر نتواند آنچه را که به دنبال آن است بیابد، هرگز فرصت استفاده از آنرا نخواهد داشت. به علاوه اگر یافت‌پذیری محقق شود، کاربرد‌پذیری هم بهبود خواهد یافت، چرا که مردم می‌توانند به سرعت و سهولت به آنچه که نیاز دارند دست یابند. ذکر این نکته نیز حائز اهمیت است که موتور‌های جست و جو، تنها وظیفه‌ی هدایت کاربران را به وب‌سایت هدف خواهند داشت. اما وظیفه یافت پذیری، با بازدید کاربران از وب‌سایت آغاز می‌گردد. به نوعی می‌توان گفت که یافت‌پذیری می‌کوشد به مردم این امکان را بدهد تا در هنگام گذار در وب‌سایت، به اطلاعاتی که نیاز دارند دست یابند.

معماری اطلاعات یکی از مهم‌ترین مراحل توسعه‌ی نرم‌افزار، به خصوص توسعه‌ی نرم‌افزار‌های تحت وب به شمار می‌رود. در حقیقت با انجام معماری اطلاعات دقیق، می‌توان مواردی از قبیل رسیدن به اهداف تعیین شده، کم کردن هزینه‌ی نگه‌داری و به روز رسانی، افزایش کارآیی و در نهایت کم شدن ریسک‌ها را مدیریت نمود.

بر اساس آنچه که در وب‌سایت UXmatters و webmonkey گفته شده است، IA در شش مرحله صورت می‌گیرد:

1. ارزیابی هدف کسب و کار ( Assess business intent )

2. ارزیابی هدف کاربران ( Assess user intent )

3. ارزیابی محتوا ( Assess content )

4. مدیریت محتوا ( Organize content )

5. برقرارسازی ارتباط میان اطلاعات ( Enable information relationships )

6. فراهم‌سازی فرآیند هدایت محتوا ( Provide navigation )

تصویر زیر که برگرفته از وب‌سایت SitePoint می‌باشد برخی از مراحل فوق را به صورت مختصر و ساده نمایش داده است.

اگر به وب‌سایت رسمی انجمن معماری اطلاعات سری بزنید مطالب مفیدی در زمینه‌ی پیاده سازی IA به دست خواهید آورد.

تصویر زیر ارتباط تنگاتنگ سه مبحث Information Design ، Interaction Design و Sensorial Design را نمایش می‌دهد. همانطور که می‌بینید، محتوا در مرکزیت هر سه موضوع قرار دارد. بنابراین می‌توان اینگونه استنباط کرد که محتوا اصلی‌ترین بخش یک کسب‌وکار نرم‌افزاری را تشکیل می‌دهد. اما در بخش پیشین دیدیم که محتوا به تنهایی نمی‌تواند راهگشای نتیجه‌ی عالی از یک نرم‌افزار باشد. با توجه به دو مفهوم یافت‌پذیری و کاربرد‌پذیری دیدیم برای آنکه بتوانیم در تولید نرم‌افزار بهترین باشیم، بایستی در قدم اول مفهوم یافت‌پذیری را رعایت نماییم. به زبان ساده باید هر چیزی را در جای مورد نظر خود قرار دهیم تا کاربر در مدت زمان خیلی کمی بتواند به آن دسترسی داشته باشد.

همانطور که در تصویر فوق ملاحظه میکنید دو اصطلاح شاید نا آشنای دیگر نیز آورده شده است، Interaction Design و Sensorial Design. در مقاله‌ای دیگر به آنها خواهیم پرداخت.

مطالب
ایجاد ایندکس منحصربفرد در EF Code first
در EF Code first برای ایجاد UNIQUE INDEX ویژگی یا تنظیمات Fluent API خاصی درنظر گرفته نشده است و می‌توان از همان روش‌های متداول اجرای مستقیم کوئری SQL بر روی بانک اطلاعاتی جهت ایجاد UNIQUE INDEX‌ها کمک گرفت:
public static void CreateUniqueIndex(this DbContext context, string tableName, string fieldName)
{
      context.Database.ExecuteSqlCommand("CREATE UNIQUE INDEX [IX_Unique_" + tableName 
+ "_" + fieldName + "] ON [" + tableName + "]([" + fieldName + "] ASC);");
}
و این کل کاری است که باید در متد Seed کلاس مشتق شده از DbMigrationsConfiguration انجام شود. مثلا:
public class MyDbMigrationsConfiguration : DbMigrationsConfiguration<MyContext>
{
        public BlogDbMigrationsConfiguration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
        }

        protected override void Seed(MyContext context)
        {
            CreateUniqueIndex(context, "table1", "field1");
            base.Seed(context);
        }
}
روش فوق کار می‌کند اما آنچنان مناسب نیست؛ چون به صورت strongly typed تعریف نشده است و اگر نام جداول یا فیلدها را بعدها تغییر دادیم، به مشکل برخواهیم خورد و کامپایلر خطایی را صادر نخواهد کرد؛ چون table1 و field1 در اینجا به صورت رشته تعریف شده‌اند.
برای حل این مشکل و تبدیل کدهای فوق به کدهایی Refactoring friendly، نیاز است نام جدول به صورت خودکار از DbContext دریافت شود. همچنین نام خاصیت یا فیلد نیز به صورت strongly typed قابل تعریف باشد.
کدهای کامل نمونه بهبود یافته را در ذیل مشاهده می‌کنید:
using System;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Data.Objects;
using System.Linq;
using System.Linq.Expressions;
using System.Text.RegularExpressions;

namespace General
{
    public static class ContextExtensions
    {
        public static string GetTableName<T>(this DbContext context) where T : class
        {
            ObjectContext objectContext = ((IObjectContextAdapter)context).ObjectContext;
            return objectContext.GetTableName<T>();
        }

        public static string GetTableName<T>(this ObjectContext context) where T : class
        {
            var sql = context.CreateObjectSet<T>().ToTraceString();
            var regex = new Regex("FROM (?<table>.*) AS");
            var match = regex.Match(sql);
            string table = match.Groups["table"].Value;
            return table
                    .Replace("`", string.Empty)
                    .Replace("[", string.Empty)
                    .Replace("]", string.Empty)
                    .Replace("dbo.", string.Empty)
                    .Trim();
        }

        private static bool hasUniqueIndex(this DbContext context, string tableName, string indexName)
        {
            var sql = "SELECT count(*) FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS where table_name = '" 
                      + tableName + "' and CONSTRAINT_NAME = '" + indexName + "'";
            var result = context.Database.SqlQuery<int>(sql).FirstOrDefault();
            return result > 0;
        }

        private static void createUniqueIndex(this DbContext context, string tableName, string fieldName)
        {
            var indexName = "IX_Unique_" + tableName + "_" + fieldName;
            if (hasUniqueIndex(context, tableName, indexName))
                return;

            var sql = "ALTER TABLE [" + tableName + "] ADD CONSTRAINT [" + indexName + "] UNIQUE ([" + fieldName + "])";
            context.Database.ExecuteSqlCommand(sql);
        }

        public static void CreateUniqueIndex<TEntity>(this DbContext context, Expression<Func<TEntity, object>> fieldName) where TEntity : class
        {
            var field = ((MemberExpression)fieldName.Body).Member.Name;
            createUniqueIndex(context, context.GetTableName<TEntity>(), field);
        }
    }
}

توضیحات
متد GetTableName ، به کمک SQL تولیدی حین تعریف جدول متناظر با کلاس جاری، نام جدول را با استفاده از عبارات باقاعده جدا کرده و باز می‌گرداند. به این ترتیب به دقیق‌ترین نامی که واقعا جهت تولید جدول مورد استفاده قرار گرفته است خواهیم رسید.
در مرحله بعد آن، همان متد createUniqueIndex ابتدای بحث را ملاحظه می‌کنید. در اینجا جهت حفظ سازگاری بین SQL Server کامل و SQL CE از UNIQUE CONSTRAINT استفاده شده است که همان کار ایجاد ایندکس منحصربفرد را نیز انجام می‌دهد. به علاوه مزیت دیگر آن امکان دسترسی به تعاریف قید اضافه شده توسط view ایی به نام INFORMATION_SCHEMA.TABLE_CONSTRAINTS است که در نگارش‌های مختلف SQL Server به یک نحو تعریف گردیده و قابل دسترسی است. از این view در متد hasUniqueIndex جهت بررسی تکراری نبودن UNIQUE CONSTRAINT در حال تعریف، استفاده می‌شود. اگر این قید پیشتر تعریف شده باشد، دیگر سعی در تعریف مجدد آن نخواهد شد.
متد CreateUniqueIndex تعریف شده در انتهای کلاس فوق، امکان دریافت نام خاصیتی از TEntity را به صورت strongly typed میسر می‌سازد.
اینبار برای تعریف یک قید و یا ایندکس منحصربفرد بر روی خاصیتی مشخص در متد Seed، تنها کافی است بنویسیم:
context.CreateUniqueIndex<User>(x=>x.Name);
در اینجا دیگر از رشته‌ها خبری نبوده و حاصل نهایی Refactoring friendly است. به علاوه نام جدول را نیز به صورت خودکار از context استخراج می‌کند.
 
نظرات مطالب
غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن
یک نکته‌ی تکمیلی: روش محافظت از کلیدهای سیستم DataProtection با یک مجوز SSL

اگر برنامه‌های ASP.NET Core را اجرا کرده باشید، عموما در ابتدای آن یک پیام محافظت نشده بودن کلیدهای سیستم DataProtection را لاگ می‌کند. برای رفع این مشکل می‌توان این مراحل را طی کرد:
الف) نیاز به یک مجوز SSL داریم که دارای private key هم باشد.
برای این منظور سه دستور زیر را صادر کنید تا یک فایل pfx مناسب سیستم DataProtection تولید شود:
"C:\Program Files\Git\usr\bin\openssl.exe" genrsa -out private.key 2048
"C:\Program Files\Git\usr\bin\openssl.exe" req -new -x509 -key private.key -out publickey.cer -days 1398
"C:\Program Files\Git\usr\bin\openssl.exe" pkcs12 -export -out idp.pfx -inkey private.key -in publickey.cer
این دستورات از openssl.exe برنامه‌ی Git for windows استفاده می‌کنند. اگر فایل pfx نهایی دارای private key نباشد (روش فوق این مشکل را ندارد)، حین استفاده‌ی از آن در برنامه، با خطاهایی مانند «کلید یافت نشد» و یا «access denied» مواجه می‌شوید.

ب) خواندن فایل pfx در برنامه
روش خواندن فایل‌های pfx به صورت زیر است:
private static X509Certificate2 loadCertificateFromFile(string filePath, string password)
{
    // NOTE:
    // You should check out the identity of your application pool and make sure
    // that the `Load user profile` option is turned on, otherwise the crypto susbsystem won't work.

    // For decryption the certificate must be in the certificate store. It's a limitation of how EncryptedXml works.
    using (var store = new X509Store(StoreName.My, StoreLocation.CurrentUser))
    {
      store.Open(OpenFlags.ReadWrite);
      store.Add(new X509Certificate2(filePath, password, X509KeyStorageFlags.Exportable));
    }

    return new X509Certificate2(
            filePath,
            password,
            keyStorageFlags: X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet
                             | X509KeyStorageFlags.Exportable);
}
دو نکته در اینجا مهم هستند: اگر از IIS استفاده می‌کنید، روشن کردن گزینه‌ی «Load user profile» را در Application pool برنامه فراموش نکنید، تا سیستم RSA به خوبی کار کند. همچنین در اینجا قسمت store.Add الزامی است. از این جهت که ASP.NET Core برای کار decryption کلیدها، فقط به اطلاعات X509Store سیستم مراجعه می‌کند و کاری به فایل pfx ما ندارد.

ج) معرفی مجوز تولید شده به سیستم
دراینجا آخرین مرحله، ذکر متد ProtectKeysWithCertificate به همراه مجوزی است که تولید کردیم:
services
   .AddDataProtection()
   .SetDefaultKeyLifetime(...)
   .SetApplicationName(...)
   .ProtectKeysWithCertificate(loadCertificateFromFile("path ...", "123"));
اکنون اگر برنامه را اجرا کنید، از فایل pfx تولیدی، برای رمزنگاری کلیدهای سیستم DataProtection استفاده خواهد شد.
مطالب
SQL تولیدی در NHibernate از کدام متد صادر شده است؟

اگر مطلب "ذخیره سازی SQL تولیدی در NH3" را دنبال کرده باشید که یک مثال عملی از "NHibernate 3.0 و عدم وابستگی مستقیم به Log4Net" بود، خروجی حاصل از آن به صورت زیر است:
---+ 12/29/2010 05:35:59.75 +---
SQL ...

---+ 12/29/2010 05:35:59.75 +---
SQL ...
و پس از مدتی این فایل هیچ حسی را منتقل نمی‌کند! یک سری SQL که لاگ شده‌اند. مشخص نیست کدام متد در کدام کلاس و کدام فضای نام، سبب صدور این عبارت SQL ثبت شده‌، گردیده‌ است.
خوشبختانه در دات نت فریم ورک می‌توان با بررسی Stack trace ، رد کاملی را از فراخوان‌های متدها یافت:
StackTrace stackTrace = new StackTrace();
StackFrame stackFrame = stackTrace.GetFrame(1);
MethodBase methodBase = stackFrame.GetMethod();
Type callingType=methodBase.DeclaringType;
با بررسی StackFrame ها امکان یافتن نام متدها، فضاهای نام و غیره میسر است. مثلا یکی از کاربردهای مهم این روش، ثبت فراخوان‌های متدی است که استثنایی را ثبت کرده است.
بر این اساس سورس مثال قبل را جهت درج اطلاعات فراخوان‌های متدها تکمیل کرده‌ام، که از این آدرس قابل دریافت است.

اکنون اگر از این ماژول جدید استفاده کنیم، خروجی نمونه‌‌ی آن به صورت زیر خواهد بود:
---+ 01/02/2011 02:19:24.98 +---
-- Void ASP.feedback_aspx.ProcessRequest(System.Web.HttpContext) [File=App_Web_4nvdip40.5.cs, Line=0]
--- Void Prog.Web.UserCtrls.FeedbacksList.Page_Load(System.Object, System.EventArgs) [File=FeedbacksList.ascx.cs, Line=23]
---- Void Prog.Web.UserCtrls.FeedbacksList.BindTo() [File=FeedbacksList.ascx.cs, Line=43]
----- System.Collections.Generic.IList`1[Feedback] Prog.GetAllUserFeedbacks(Int32) [File=FeedbackWebRepository.cs, Line=66]

SELECT ...
@p0 = 3 [Type: Int32 (0)]
به این معنا که عبارت SQL ثبت شده، حاصل از پردازش صفحه‌ی feedback.aspx، سپس متد Page_Load آن که از یوزر کنترل FeedbacksList.ascx استفاده می‌کند، می‌باشد. در اینجا فراخوانی متد BindTo سبب فراخوانی متد GetAllUserFeedbacks در فایل FeedbackWebRepository.cs واقع در سطر 66 آن گردیده است.
اینطوری حداقل می‌توان دریافت که SQL تولیدی دقیقا به کجا بر می‌گردد و چه متدی سبب صدور آن شده است.

ملاحظات:
این ماژول تنها در صورت وجود فایل pdb معتبر کنار اسمبلی‌های شما این خروجی مفصل را تولید خواهد کرد. در غیر اینصورت از آن صرفنظر می‌کند. (برای مثال نام فایل سورس فراخوان، شماره‌ی سطر فراخوان، حتی محل قرارگیری آن فایل بر روی کامپیوتر شما در فایل‌های pdb ثبت می‌گردند؛ به همین جهت توصیه اکید حین ارائه‌ی نهایی برنامه، حذف این نوع فایل‌ها است)

مطالب
نحوه‌ی فعال سازی library caching زمانیکه یک Silverlight library را تولید کرده‌ایم

در مورد کاهش حجم فایل‌های XAP سیلورلایت زمانیکه از اسمبلی‌های کتابخانه‌های دیگر مانند Silverlight toolkit استفاده می‌شود، در این فصل بحث شده است و راه حل، استفاده از گزینه‌ی reduce XAP size by using application library caching است. به این صورت کاربران دیگر به ازای هر بار مشاهده‌ی سایت نیازی نخواهند داشت تا یک سری کتابخانه‌ی کمکی را که هیچ تغییری در آن‌ها حاصل نخواهد شد، دریافت کنند و اطلاعات آن‌ها از cache مرورگر خوانده می‌شود. این مورد با کتابخانه‌ها و ابزارهای کمکی تولید شده توسط مایکروسافت کار می‌کند. اما اگر خودتان یک Silverlight library را تولید کنید، چنین اتفاقی رخ نخواهد داد و باز هم فایل اسمبلی کتابخانه‌ی شما درون فایل XAP اصلی برنامه قرار گرفته و خبری از caching مجزای آن نیست. چرا اینطور است؟ چکار باید کرد؟!
علت آن بر می‌گردد به نحوه‌ی پیاده سازی library caching در VS.NET و Silverlight . برای این منظور چند مرحله باید طی شود تا این قابلیت برای کتابخانه‌های ساخت خودمان نیز فعال گردد:
الف) به کتابخانه‌ی خود باید امضای دیجیتال اضافه کنید:
اینکار با استفاده از امکانات خود VS.NET بسیار ساده است. به خواص پروژه مراجعه کنید. سپس برگه‌ی Signing را باز کرده و گزینه‌ی Sign the assembly را انتخاب کنید (شکل زیر). در قسمت choose a strong name key file ، گزینه‌ی new را انتخاب کرده و پس از وارد کردن یک نام دلخواه و گذر واژه‌ای، فایل pfx امضای دیجیتال اسمبلی شما تولید خواهد شد. اکنون تنها کافی است یکبار دیگر برنامه را کامپایل کنید.


ب) به یک فایل extMap.xml هم نیاز است:
هنگام پیاده سازی قابلیت library caching ، VS.NET به دنبال فایلی به نام AssemblyFileName.extmap.xml دقیقا در کنار فایل اسمبلی مورد نظر می‌گردد. ساختار عمومی این فایل XML به صورت زیر است:

<?xml version="1.0"?>
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<assembly>
<name>SLHelper</name>
<version>1.0.0.0</version>
<publickeytoken>f265933def965412</publickeytoken>
<relpath>SLHelper.dll</relpath>
<extension downloadUri="SLHelper.zip" />
</assembly>
</manifest>

نام، شماره نگارش، مسیر قرارگیری فایل اسمبلی مورد نظر و همچنین نام نهایی آن حین جدا سازی آن از XAP برنامه باید مشخص گردد. گزینه‌ی publickeytoken مهم‌ترین تنظیم این فایل است و قسمت الف را به همین منظور نیاز داشتیم. این عدد را به سادگی با استفاده از برنامه‌ی reflector می‌توان بدست آورد (شکل زیر).



جهت ساده سازی قسمت (ب)، برنامه‌ی کمکی را از آدرس ذیل می‌توانید دریافت کنید:
Utility: Extmap Maker

برای مطالعه بیشتر
Silverlight 3: Cached Assemblies and you can to

مطالب
کار با Docker بر روی ویندوز - قسمت پنجم - ایجاد Imageهای سفارشی
تا اینجا با نحوه‌ی اجرای برنامه‌های مختلف توسط داکر مانند وب سرور لینوکسی nginx و یا IIS ویندوزی آشنا شدیم؛ اما هنوز محتوایی را در آن‌ها هاست نکرده‌ایم. در این قسمت این موضوع را بررسی خواهیم کرد و در طی این فرآیند، با نحوه‌ی ساخت Imageهای سفارشی نیز آشنا خواهیم شد.


روش نگاشت محتوای یک سایت استاتیک در یک Container که وب سرور است

فرض کنید یک سایت استاتیک بوت استرپی را تهیه کرده‌اید و قصد دارید آن‌را توسط وب سرور nginx، هاست کنید. برای این‌کار، چندین گزینه پیش روی ما هستند:
گزینه‌ی اول: دریافت image مربوط به nginx، سپس ایجاد یک container از آن و در آخر با استفاده از «روش به اشتراک گذاری فایل سیستم میزبان با کانتینرها» که در قسمت قبل بررسی کردیم، این وب سایت را آماده‌ی اجرا و دسترسی می‌کنیم.
گزینه‌ی دوم: کپی کردن فایل‌های وب سایت از سیستم میزبان، به درون فایل سیستم خود container.
گزینه‌ی سوم: ایجاد یک image سفارشی که از ابتدا به همراه فایل‌های وب سایت استاتیک ما است و در این حالت تنها کافی است این image را تبدیل به container اجرایی کنیم.


روش اول: به اشتراک گذاری فایل سیستم میزبان با کانتینر وب سرور جهت هاست آن

در قسمت قبل، یک فایل tar ایجاد شده‌ی در سیستم میزبان ویندوزی را با یک کانتینر لینوکسی به اشتراک گذاشتیم تا بتوانیم محتویات آن‌را استخراج کنیم. در اینجا قصد داریم پوشه‌ی وب سایت استاتیک خود را که در سیستم میزبان ویندوزی قرار دارد، با وب سرور nginx که توسط یک container در حال اجرا است، به اشتراک بگذاریم تا آن‌را هاست کند.
فرض کنید وب سایت استاتیک ما در مسیر c:\users\vahid\mysite سیستم میزبان قرار دارد که داخل آن یک فایل index.html و تعدادی فایل css و js آماده‌ی برای هاست شدن، وجود دارند. برای هاست آن توسط nginx، از دستور زیر استفاده خواهیم کرد:
 docker run --rm -it -p 8080:80 -v c:\users\vahid\mysite:/usr/share/nginx/html nginx
در این دستور:
- سوئیچ rm سبب می‌شود تا پس از خاتمه‌ی کار nginx، این container نیز حذف شود.
- از سوئیچ it استفاده شده‌است تا با فشردن ctrl+c، بتوانیم پروسه‌ی container را خاتمه دهیم و پس از آن، برنامه‌ی nginx دیگر در background در حال اجرا نباشد (اجرای آن در foreground).
- سپس پورت 8080 سیستم میزبان، به پورت 80 وب سرور nginx نگاشت شده‌است. چون containerها دارای network stack خاص خودشان هستند (که آن‌را در قسمت سوم بررسی کردیم)، پورت 80 آن‌ها با پورت 80 سیستم میزبان تداخل نمی‌کند و اگر برای مثال بر روی پورت 80 سیستم جاری، IIS در حال اجرا باشد، سبب عدم اجرا شدن وب سرور nginx به دلیل تداخل پورت‌ها نمی‌شود.
- در ادامه روش volume mount را مشاهده می‌کنید که در قسمت قبل بررسی کردیم. مسیر c:\users\vahid\mysite سیستم میزبان، به مسیر ویژه‌ی /usr/share/nginx/html داخل container نگاشت شده‌است. این مسیر، یک مسیر استاندارد بوده و در مستندات docker hub این وب سرور، ذکر شده‌است.
- در آخر هم نام image این وب سرور را ذکر کرده‌ایم.

پس از اجرای این دستور، اگر nginx پیش‌تر دریافت نشده باشد، image آن دریافت شده، یک container بر اساس آن ساخته می‌شود و سپس با پارامترهایی که توضیح دادیم، اجرا خواهد شد. اکنون اگر در سیستم میزبان، مسیر http://localhost:8080 را در مرورگر باز کنید، وب سایت استاتیک خود را مشاهده خواهید کرد.


روش دوم: کپی کردن فایل‌های وب سایت از سیستم میزبان، به درون فایل سیستم خود container

همانطور که در قسمت سوم نیز بررسی کردیم، فایل سیستم مربوط به هاست، به طور کامل از فایل سیستم container، جدا و ایزوله است و بدون volume mount، یک container نمی‌تواند به فایل‌های میزبان خود دسترسی پیدا کند. بنابراین گزینه‌ی دیگری که در اینجا وجود خواهد داشت، کپی کردن فایل‌های میزبان و انتقال آن‌ها به container می‌باشد؛ شبیه به کپی کردن فایل‌ها از یک کامپیوتر موجود در شبکه به کامپیوتر دیگری در آن.
برای این منظور ابتدا nginx را در پس‌زمینه اجرا می‌کنیم:
 docker run -d -p 8080:80 --name nginx nginx
در این دستور، سوئیچ‌های rm و it حذف شده‌اند. علت اینجا است که سوئیچ d، سبب اجرای این دستور در پس‌زمینه می‌شود؛ یعنی بلافاصله سبب بازگشت ما به خط فرمان خواهد شد و در این حالت نمی‌خواهیم که این container حذف شود. همچنین یک نام نیز به آن انتساب داده شده‌است تا بتوان ساده‌تر با آن کار کرد.
پس از اجرای این دستور و بازگشت به command prompt، جهت اطمینان حاصل کردن از اجرای آن در پس زمینه، دستور docker ps را صادر می‌کنیم که لیست آن، حاوی گزارشی از container‌های در حال اجرا است.
اکنون توسط دستور ویژه‌ی docker exec، می‌خواهیم درون یک container در حال اجرا، پروسه‌ای را اجرا کنیم. یعنی با اینکه پروسه‌ی nginx داخل این container در حال اجرا است، برای مثال می‌خواهیم یک shell را نیز داخل آن اجرا کنیم:
 docker exec -it nginx bash
در اینجا دستور docker exec، سبب اجرای bash shell داخل کانتینری با نام nginx می‌شود (همان سوئیچ name در دستور قبلی و نه نام image آن) و چون می‌خواهیم به این shell در foreground دسترسی داشته باشیم، از سوئیچ it نیز استفاده شده‌است. پس از اجرا شدن bash shell، اکنون به فایل سیستم این container دسترسی یافته‌ایم. برای مثال دستور ls را صادر کنید تا لیستی از آن‌را مشاهده نمائید. سپس به کمک آن، به پوشه‌ی ویژه‌ی html این وب سرور وارد می‌شویم:
 cd /usr/share/nginx/html
و برای مثال می‌توان در آن تغییر ایجاد کرد:
ls
mv index.html index2.html
exit
این دستورات سبب می‌شوند تا فایل پیش‌فرض index.html آن، به index2.html تغییر نام یابد و سپس از این shell خارج می‌شویم و به shell سیستم میزبان باز خواهیم گشت. در اینجا دستور docker cp (که در PowerShell سیستم میزبان اجرا می‌شود)، امکان کپی کردن فایل‌ها را از سیستم میزبان به یک container میسر می‌کند.
 docker cp c:\users\vahid\mysite nginx:/usr/share/nginx/html
پس از دستور docker cp ابتدا مسیر مبداء مشخص می‌شود و سپس ابتدا نام container مقصد به همراه یک : و در ادامه مسیر مقصد نهایی کپی در آن container ذکر خواهند شد. به این ترتیب فایل‌های وب سایت استاتیک ما در سیستم میزبان به پوشه‌ی html مخصوص nginx، در کانیتنری که در حال اجرای آن است کپی می‌شوند. برای آزمایش صحت این کپی می‌توان دستور زیر را صادر کرد که لیست فایل‌های این پوشه‌ی html را نمایش می‌دهد:
 docker exec nginx ls /usr/share/nginx/html
اینبار نیز اگر در سیستم میزبان، مسیر http://localhost:8080 را در مرورگر باز کنید، وب سایت استاتیک خود را مشاهده خواهید کرد که فایل‌های آن از داخل خود container تامین می‌شوند و وابستگی به سیستم میزبان ندارند.


روش سوم: ایجاد یک image سفارشی که از ابتدا به همراه فایل‌های وب سایت استاتیک ما است

در روش دوم، موفق شدیم که فایل‌های مدنظر خود را به درون container در حال اجرا کپی کنیم. اکنون می‌خواهیم یک snapshot را از آن تهیه کنیم؛ شبیه به کاری که با ماشین‌های مجازی نیز انجام می‌شود و این روشی است که از آن برای ساخت یک image سفارشی استفاده می‌شود. برای این منظور از دستور docker commit استفاده می‌شود تا تصویری را از وضعیت یک container در حال اجرا، در آن لحظه تهیه کنیم:
 docker commit nginx mysite:nginx
پس از دستور docker commit، نام container ای که می‌خواهیم تصویر وضعیت جاری آن‌را ذخیره کنیم، ذکر می‌شود. پس از آن به صورت اختیاری می‌توان یک نام جدید و همچنین tag ای را برای آن ذکر کرد.
اکنون پس از اجرای این دستور، با استفاده از فرمان docker images می‌توان مشاهده کرد که image جدید mysite، با tag ای معادل nginx، ایجاد شده‌است.
در ادامه برای اجرای این image جدید، می‌توان از دستور زیر استفاده کرد:
 docker run -d -p 8090:80 --name mysite mysite:nginx
روش اجرای آن همانند سایر imageهای موجود است و در اینجا از نام image به همراه tag آن استفاده شده‌است. همچنین پورت نگاشت شده‌ی آن‌را به سیستم میزبان نیز 8090 انتخاب کرده‌ایم. نامی را نیز به آن نسبت داده‌ایم تا بتوان از آن در دستور docker exec استفاده کرد.
اکنون اگر در سیستم میزبان، مسیر http://localhost:8090 را در مرورگر باز کنید، وب سایت استاتیک خود را مشاهده خواهید کرد و یا توسط دستور زیر می‌توانید فایل‌های موجود در پوشه‌ی html وب سرور nginx این container جدید در حال اجرا را ملاحظه نمائید:
 docker exec mysite ls /usr/share/nginx/html
که این فایل‌ها نه از طریق نگاشت فایل سیستم میزبان، به مسیری در container جاری تامین شده‌اند و نه از جائی به داخل آن کپی شده‌اند. بلکه دقیقا از image از پیش آماده شده‌ی آن خوانده شده‌اند.


نگاهی به لایه‌های یک Image در مقایسه با یک Container

زمانیکه خواستیم image جدید و سفارشی خاص خود را ایجاد کنیم، با image اصلی nginx شروع کردیم. اولین لایه‌ی موجود در این image، سیستم عاملی است که می‌تواند آن‌را اجرا کند. برفراز این لایه، لایه‌ی خود nginx قرار گرفته‌است. اگر خواستید تاریخچه‌ی ایجاد یک image را مشاهده کنید، از دستور docker history nginx استفاده نمائید. خروجی آن لیست دستوراتی را نمایش می‌دهد که برای ساخت این image مورد استفاده قرار گرفته‌اند. البته دستور docker history nginx --no-trunc، اطلاعات بیشتری را با نمایش لیست کامل و خلاصه نشده‌ی دستورات، ارائه می‌دهد. این دستورات را در صفحه‌ی docker hub هر image نیز می‌توان مشاهده کرد. در قسمت full description هر image، در ابتدای توضیحات، قسمتی است به نام supported tags and respective dockerfile links. در اینجا هر tag نامبرده شده، در حقیقت لینکی است به یک فایل که دقیقا همین دستورات را لیست کرده‌است. به این فایل، docker file گفته می‌شود که روش ساخت یک image را توضیح می‌دهد. هدف آن، خودکار سازی اجرای دستوراتی است که سبب ساخت یک image می‌شوند.

در ادامه اگر از این image، یک container را ایجاد کنیم، این container هر دو لایه‌ی OS و Framework را به همراه خواهد داشت؛ به علاوه‌ی لایه‌ی دیگری به نام Container/Run که می‌توان فایل‌های آن‌را خواند و یا در آن نوشت. بنابراین لایه‌ای که فایل‌های وب سایت استاتیک ما در آن کپی شدند، دقیقا همین لایه‌است.


و زمانیکه از یک container تصویری تهیه می‌شود، تغییراتی را که به فایل سیستم آن ایجاد کرده‌ایم، به صورت یک لایه‌ی جدید بر روی لایه‌های قبلی آن image، ظاهر و ثبت می‌شود. برای اثبات این موضوع، می‌توان از دستور docker diff nginx استفاده کرد. در اینجا nginx نام container ای است که می‌خواهیم تغییرات آن‌را با image قبلی که بر پایه‌ی آن ایجاد شده‌است، مشاهده کنیم.


تبدیل دستورات docker به یک docker file

تا اینجا یک چنین دستوراتی را برای اجرای کانتینر nginx، کپی فایل‌ها به آن و سپس تهیه‌ی یک تصویر از آن، اجرا کردیم:
docker run -d -p 8080:80 --name nginx nginx
docker cp c:\users\vahid\mysite nginx:/usr/share/nginx/html
docker commit nginx mysite:nginx
برای خودکار سازی آن‌ها هرچند می‌توان این دستورات را در یک اسکریپت نیز قرار داد، اما docker، قابلیت پردازش اسکریپت‌های خاص خود را نیز دارد که به آن Dockerfile گفته می‌شود. برای این منظور سطرهای فوق به صورت زیر تغییر می‌کنند:
بجای سطر اول، تنها نام image ای را که می‌خواهیم کار را بر مبنای آن انجام دهیم، ذکر می‌کنیم:
 FROM nginx
دستور دوم نیز تبدیل به دستور کپی Docker می‌شود:
 COPY mysite /usr/share/nginx/html
این دو سطر را به صورت یک فایل متنی، با نام ویژه‌ی Dockerfile ذخیره می‌کنیم (بدون پسوند) و این Dockerfile را دقیقا در کنار پوشه‌ی mysite قرار می‌دهیم (داخل پوشه‌ی c:\users\vahid) تا کار کپی را از همینجا شروع کند.
سپس برای اجرای این فایل، بجای دستور docker commit آخر، از دستور زیر استفاده می‌کنیم:
 docker build -f Dockerfile -t mysite:nginx-df .
البته می‌توان f Dockerfile- را نیز از این دستور حذف کرد؛ چون مقدار پیش‌فرض آن است (مگر آنکه بخواهیم مسیر خاصی را دقیقا مشخص کنیم):
 docker build -t mysite:nginx-df .
در هر دو دستور آخری که ذکر شدند، در انتهای دستور، یک نقطه نیز قرار دارد که به آن build context گفته می‌شود؛ یا دقیقا همین پوشه‌ای که در آن قرار داریم (c:\users\vahid).
تگ این image را نیز متفاوت با قبلی‌ها انتخاب کرده‌ایم؛ nginx-df بجای مقدار قبلی.
در این حالت اگر دستور آخر را اجرا کنیم، دستور docker images گزارش اضافه شدن این image جدید را ارائه خواهد داد.

مرجع کامل ساخت Dockerfileها را در اینجا می‌توانید مطالعه کنید.


ساخت یک image سفارشی برای هاست یک وب سایت استاتیک در IIS

تا اینجا از وب سرور لینوکسی nginx برای هاست وب سایت استاتیک خود استفاده کردیم. در ادامه می‌خواهیم از وب سرور IIS برای اینکار استفاده نمائیم. بنابراین ابتدا نیاز است یا از ویندوز سرور استفاده کنیم و یا می‌توان با کلیک راست بر روی آیکن Docker در قسمت Tray Icons ویندوز، به Windows Containers سوئیچ کرد و سپس به صورت زیر عمل نمود.
اینبار محتوای Dockerfile ای که کنار پوشه‌ی mysite قرار می‌گیرد، به صورت زیر خواهد بود:
FROM microsoft/iis:nanoserver

COPY mysite c:/inetpub/wwwroot
کار با image اصلی iis با tag مخصوص nanoserver که کم حجم‌تر است، شروع می‌شود. سپس فایل‌های mysite به پوشه‌ی wwwroot این وب سرور کپی خواهد شد.
در ادامه با استفاده از دستور زیر و اجرای فایل Dockerfile، این image جدید را با tag ای به نام iis ایجاد می‌کنیم:
 docker build -t mysite:iis .
پس از آن دستورات docker images و docker ps را جهت مشاهده‌ی وضعیت این image جدید اجرا کنید.


به اشتراک گذاری imageهای سفارشی در Docker Hub

برای به اشتراک گذاری imageهای سفارشی خود در Docker Hub، نیاز است tag آن‌ها را توسط دستور docker tag مطابق فرمت ویژه‌ی docker hub ویرایش کرد:
 docker tag mysite:nginx-df my_user_name/some_name:new_tag_name
در این دستور، Tag فعلی، با ذکر نام کاربری، نام مخزنی جدید در docker hub و سپس یک tag دلخواه، ویرایش می‌شود.
و در آخر برای انتشار آن می‌توان از دستور docker push استفاده کرد:
 docker push my_user_name/some_name:new_tag_name
اگر در اینجا پیام خطای unauthorized را مشاهده کردید، ابتدا دستور docker login را اجرا کنید تا بتوانید به سایت docker hub لاگین کنید (بر اساس مشخصات اکانت خود در داکر هاب) و سپس دستور فوق را اجرا نمائید.
پس از پایان کار اگر به سایت docker hub و مخازن خود مراجعه کنید، این image جدید قابل مشاهده خواهد بود.
بازخوردهای دوره
انتقال خودکار Data Annotations از مدل‌ها به ViewModelهای ASP.NET MVC به کمک AutoMapper
مدل اصلی عموما همان domain models هستند؛ برای مثال مدل‌های EF و EF از این ویژگی‌ها جهت تنظیم ساختار بانک اطلاعاتی و همچنین اعتبارسنجی خاص خودش استفاده می‌کند. بنابراین قلب طراحی مدل‌های سیستم، مدل‌های domain هستند و view models صرفا کاربرد نمایش سفارشی اطلاعات و همچنین کاهش سطح در معرض دید قرار گرفتن مدل‌های domain را جهت بهبود وضعیت امنیتی سیستم، دارند.
نظرات اشتراک‌ها
بررسی وضعیت فعلی پروژه Roslyn
کامپایلر سی‌شارپ با ++C نوشته شده. الان این کامپایلر و مابقی کامپایلرهای دات نتی رو با خود دات نت و سی‌شارپ بازنویسی کرده‌اند؛ تحت پروژه‌ای به نام Roslyn. مزیت آن امکان استفاده وسیع از این کامپایلر به صورت سرویس به برنامه نویس‌های دات نت است و همچنین داخل خود VS.NET برای بهبود عملکرد IDE، کارهای Refactoring و آنالیزهای پیشرفته کدها.
اشتراک‌ها
کتابخانه‌ای برای تغییر تصاویر وب‌سایت به صورت هوشمند؛ جهت بهبود کارآیی و سرعت
در حال حاضر قابلیت‌هایی که لایبری دارد:
  • تغییر عرض عکس
  • تغییر ارتفاع عکس
  • تغییر فرمت عکس
    • png
    • jpg
    • jpeg
  • چرخش اتوماتیک
  • تغییر کیفیت عکس (0-100)
  • کش در مموری
  • بعد از تغییر عرض و ارتفاع با هم انتخاب مود مورد نظر
    • pad
    • max 
    • crop 
    • stretch 
قابلیت‌هایی  که در آینده اضافه خواهند شد:
  • کش در دیسک (که بسیار مهم خواهد بود)
  • اضافه کردن واتر مارک
  • و بهبود کارآیی پکیج
کتابخانه‌ای برای تغییر تصاویر وب‌سایت به صورت هوشمند؛ جهت بهبود کارآیی و سرعت