وحید نصیری وحید نصیری
نظرات اشتراک‌ها
نگارش بعدی ASP.NET Core از Full .NET Framework پشتیبانی نمی‌کند
بحث اصلی مطلب جاری این است که NET Core. (پیاده سازی) با NET Standard. (قرارداد) یکی نیست. NET Core. یکی از پیاده سازی‌های NET Standard. است؛ مانند دات نت 4.6.1 که آن هم پیاده سازی کننده‌ی دات نت استاندارد 2 است. هر دوی این‌ها دارای یک سری API خاص خودشان هم هستند که در NET Standard. وجود ندارند. سطح API دات نت Core هم بیشتر است از NET Standard. و در یکسری از موارد هم کاملا ناسازگار با دات نت کامل. بنابراین توافقی که در اینجا وجود دارد، صرفا پیاده سازی قرارداد NET Standard. است و بیشتر از آن هم مربوط است به توسعه دهندگان آن سکوی کاری خاص که الزامی به یکی بودن آن‌ها نیست.
کاری که پیشتر می‌خواستند انجام دهند، محدود کردن ASP.NET Core به سطح API موجود در NET Core. بود (NET Core 2.0 only. یا تصویر زیر) و نه صرفا به NET Standard. . این مساله برای توسعه دهندگان ASP.NET Core می‌توانست فوق العاده باشد؛ چون سطح API بیشتر و به‌روزتری را در اختیارشان قرار می‌داد و اگر قابلیتی در NET Standard. وجود نداشت، نمی‌بایستی درخواست می‌دادند تا اضافه شود تا بعد بتوانند استفاده کنند.


اما چون این مساله و سطح API بیشتر و گاهی از اوقات کاملا متفاوت، سازگاری با کتابخانه‌هایی را که در میدان دید این API قرار نمی‌گرفتند، زیر سؤال می‌برد، ارتقاء برنامه‌های قبلی را با مشکل مواجه می‌کرد. به همین جهت تصمیم گرفته‌اند که ASP.NET Core را سازگار با دات نت فریم ورک کامل نیز ارائه دهند و بنابراین «محدودش کنند» به NET Standard 2.0.  و نه حالت NET Core only‌. قبلی: اطلاعات بیشتر


به علاوه باید درنظر داشت که امکان اضافه کردن یک بسته‌ی نیوگت از یک کتابخانه‌ی نوشته شده‌ی برای دات نت کامل در برنامه‌های دات نت Core به معنای تضمینی برای کار کردن آن در زمان اجرا نخواهد بود. از این جهت که دات نت کامل، به همراه قسمت‌هایی است که در NET Standard. وجود خارجی ندارند. بنابراین اگر کتابخانه‌ی استفاده شده صرفا این API مشترک را هدف قرار داده‌است، هم قابلیت اتصال و هم قابلیت اجرا را خواهد داشت؛ اما اگر برای مثال کسی بسته‌ی NServiceBus را به پروژه‌ی ASP.NET Core 2.0 اضافه کند، بدون مشکل کامپایل خواهد شد. اما از آنجائیکه این کتابخانه از MSMQ استفاده می‌کند که خارج از میدان دید این استاندارد است، در زمان اجرا با شکست مواجه خواهد شد.
‫۷ سال و ۵ ماه قبل، یکشنبه ۲۴ اردیبهشت ۱۳۹۶، ساعت ۱۸:۱۵
وحید نصیری وحید نصیری
مطالب
MVC Scaffolding #3
شاید کیفیت کدهای تولیدی یا کدهای View حاصل از MVC Scaffolding مورد تائید شما نباشد. در این قسمت به نحوه تغییر و سفارشی سازی این موارد خواهیم پرداخت.

آشنایی با ساختار اصلی MVC Scaffolding

پس از نصب MVC Scaffolding از طریق NuGet به پوشه Packages مراجعه نمائید. در اینجا پوشه‌های MvcScaffolding، T4Scaffolding و T4Scaffolding.Core ساختار اصلی این بسته را تشکیل می‌دهند. برای نمونه اگر پوشه T4Scaffolding\tools را باز کنیم، شاهد تعدادی فایل ps1 خواهیم بود که همان فایل‌های پاورشل هستند. مطابق طراحی NuGet، همواره فایلی با نام init.ps1 در ابتدا اجرا خواهد شد. همچنین در  اینجا پوشه‌های T4Scaffolding\tools\EFRepository و T4Scaffolding\tools\EFDbContext نیز قرار دارند که حاوی قالب‌های اولیه کدهای مرتبط با الگوی مخزن و DbContext تولیدی می‌باشند.
در پوشه MvcScaffolding\tools، ساختار قالب‌های پیش فرض تولید Viewها و کنترلرهای تولیدی قرار دارند. در اینجا به ازای هر مورد، دو نگارش vb و cs قابل مشاهده است.


سفارشی سازی قالب‌های پیش فرض Viewهای MVC Scaffolding

برای سفارشی سازی قالب‌های پیش فرض از دستور کلی زیر استفاده می‌شود:
Scaffold CustomTemplate Name Template
مانند دستور زیر:
Scaffold CustomTemplate View Index
در اینجا View نام یک Scaffolder است و Index نام قالبی در آن.
اگر دستور فوق را اجرا کنیم، فایل جدیدی به نام CodeTemplates\Scaffolders\MvcScaffolding.RazorView\Index.cs.t4 به پروژه جاری اضافه می‌شود. از این پس کلیه فرامین اجرایی، از نسخه محلی فوق بجای نمونه‌های پیش فرض استفاده خواهند کرد.
در ادامه قصد داریم اندکی این قالب پیش فرض را جهت اعمال ویژگی DisplayName به هدر جدول تولیدی نمایش اطلاعات Tasks تغییر دهیم. در کلاس Task، خاصیت زمان موعود با ویژگی DisplayName مزین شده است. این نام نمایشی حین تولید فرم‌های ثبت و ویرایش اطلاعات بکار گرفته می‌شود، اما در زمان تولید جدول اطلاعات ثبت شده، به هدر جدول اعمال نمی‌گردد.
[DisplayName("Due Date")]
public DateTime? DueDate { set; get; }
برای تغییر و بهبود این مساله، فایل Index.cs.t4 را که پیشتر به پروژه اضافه کردیم باز کنید. کلاس ModelProperty را یافته و خاصیت جدید DisplayName را به آن اضافه کنید:
// Describes the information about a property on the model
class ModelProperty {
    public string Name { get; set; }
    public string DisplayName { get; set; }
    public string ValueExpression { get; set; }
    public EnvDTE.CodeTypeRef Type { get; set; }
    public bool IsPrimaryKey { get; set; }
    public bool IsForeignKey { get; set; }
    public bool IsReadOnly { get; set; }
}
در حالت پیش فرض فقط از خاصیت Name برای تولید هدر جدول در ابتدای فایل t4 در حال ویرایش استفاده می‌شود. در پایان فایل t4 جاری، متد زیر را اضافه کنید:
static string GetDisplayName(EnvDTE.CodeProperty prop)
{
  var displayAttr = prop.Attributes.OfType<EnvDTE80.CodeAttribute2>().Where(x => x.FullName == typeof(System.ComponentModel.DisplayNameAttribute).FullName).FirstOrDefault();
  if(displayAttr == null)
  {
    return prop.Name;
  }
  return displayAttr.Value.Replace("\"","");
}
در اینجا بررسی می‌شود که آیا ویژگی DisplayNameAttribute بر روی خاصیت در حال بررسی وجود دارد یا خیر. اگر خیر از نام خاصیت استفاده خواهد شد و اگر بلی، مقدار ویژگی نام نمایشی استخراج شده و بازگشت داده می‌شود.
اکنون برای اعمال متد GetDisplayName، متد GetEligibleProperties را یافته و به نحو زیر تغییر دهید:
results.Add(new ModelProperty {
Name = prop.Name,
DisplayName = GetDisplayName(prop), 
ValueExpression = "Model." + prop.Name,
Type = prop.Type,
IsPrimaryKey = Model.PrimaryKeyName == prop.Name,
IsForeignKey = ParentRelations.Any(x => x.RelationProperty == prop),
IsReadOnly = !prop.IsWriteable()
});
در اینجا خاصیت DisplayName به لیست خروجی اضافه شده است.
اکنون قسمت هدر جدول تولیدی را در ابتدای فایل t4 یافته و به نحو زیر تغییر می‌دهیم تا از DisplayName استفاده کند:
<#
List<ModelProperty> properties = GetModelProperties(Model.ViewDataType, true);
foreach (ModelProperty property in properties) {
    if (!property.IsPrimaryKey && !property.IsForeignKey) {
#>
        <th>
            <#= property.DisplayName #>
        </th>
<#
    }
}
#>
در ادامه برای آزمایش تغییرات فوق، دستور ذیل را صادر می‌کنیم:
PM> Scaffold Controller -ModelType Task -ControllerName TasksController -DbContextType TasksDbContext -Repository -Force
پس از اجرای دستور، به فایل Views\Tasks\Index.cshtml مراجعه نمائید. اینبار هدر خودکار تولیدی از Due Date بجای DueDate استفاده کرده است.


سفارشی سازی قالب‌های پیش فرض کنترلرهای MVC Scaffolding

در ادامه قصد داریم کدهای الگوی مخزن تهیه شده را اندکی تغییر دهیم. برای مثال با توجه به اینکه از تزریق وابستگی‌ها استفاده خواهیم کرد، نیازی به سازنده اولیه پیش فرض کنترلر که در بالای آن ذکر شده «در صورت استفاده از یک DI این مورد را حذف کنید»، نداریم. برای این منظور دستور زیر را اجرا کنید:
 PM> Scaffold CustomTemplate Controller ControllerWithRepository
در اینجا قصد ویرایش قالب پیش فرض کنترلرهای تشکیل شده با استفاده از الگوی مخزن را داریم. نام ControllerWithRepository از فایل ControllerWithRepository.cs.t4 موجود در پوشه packages\MvcScaffolding\tools\Controller گرفته شده است.
به این ترتیب فایل جدید CodeTemplates\Scaffolders\MvcScaffolding.Controller\ControllerWithRepository.cs.t4 به پروژه جاری اضافه خواهد شد. در این فایل چند سطر ذیل را یافته و سپس حذف کنید:
// If you are using Dependency Injection, you can delete the following constructor
        public <#= Model.ControllerName #>() : this(<#= String.Join(", ", Repositories.Values.Select(x => "new " + x.RepositoryTypeName + "()")) #>)
        {
        }
برای آزمایش آن دستور زیر را صادر نمائید:
PM> Scaffold Controller -ModelType Task -ControllerName TasksController -DbContextType TasksDbContext -Repository -Force -ForceMode ControllerOnly
چون تنها قصد تغییر کنترلر را داریم از پارامتر ForceMode با مقدار ControllerOnly استفاده شده است.
یا اگر نیاز به تغییر کدهای الگوی مخزن مورد استفاده است می‌توان از دستور ذیل استفاده کرد:
 Scaffold CustomScaffolder EFRepository
به این ترتیب فایل جدید CodeTemplates\Scaffolders\EFRepository\EFRepositoryTemplate.cs.t4 جهت ویرایش به پروژه جاری اضافه خواهد شد.
لیست Scaffolder‌های مهیا با دستور Get-Scaffolder قابل مشاهده است.
‫۱۱ سال و ۹ ماه قبل، چهارشنبه ۴ بهمن ۱۳۹۱، ساعت ۱۱:۳۵
وحید نصیری وحید نصیری
مطالب
روش ایجاد پروژه‌ها‌ی کتابخانه‌ای کامپوننت‌های Blazor
جهت به اشتراک گذاشتن کامپوننت‌های سفارشی Blazor در پروژه‌های مختلف، امکان بسته بندی آن‌ها به صورت کتابخانه‌های کامپوننت‌ها نیز پیش‌بینی شده‌است که می‌توانند به همراه فایل‌های CSS ،JS و تصاویر هم باشند.


روش ایجاد یک پروژه‌ی کتابخانه‌ای، از کامپوننت‌های Blazor

اگر از ویژوال استودیو استفاده می‌کنید، نوع «Razor Class Library»، پروژه‌های مخصوص کتابخانه‌های کامپوننت‌های Blazor را آغاز می‌کند و اگر می‌خواهید از CLI استفاده کنید، باید از دستور «dotnet new razorclasslib» استفاده کرد؛ که قابلیت تبدیل به بسته‌های نیوگت را با دستور dotnet pack داشته و به این ترتیب می‌توان آن‌ها را به اشتراک گذاشت و یا حتی می‌توان ارجاعی از این پروژه را در سایر پروژه‌های شخصی، مورد استفاده قرار داد.
ساختار پیش‌فرض فایل csproj اینگونه پروژه‌ها به صورت زیر است:
<Project Sdk="Microsoft.NET.Sdk.Razor">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>
  
  <ItemGroup>
    <SupportedPlatform Include="browser" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Components.Web" Version="5.0.6" />
  </ItemGroup>
</Project>

روش افزودن فایل‌های ثابت مورد استفاده‌ی در کتابخانه

پروژه‌ی پیش‌فرضی که در اینجا ایجاد می‌شود، به همراه یک پوشه‌ی wwwroot نیز هست. این پوشه محلی است که باید فایل‌های ثابت اشتراکی پروژه را مانند فایل‌های CSS و JS مورد استفاده، قرار داد.
این نوع پروژه‌ها از ویژگی Isolated CSS و یا Isolated JS ارائه شد‌ه‌ی در Blazor 5x نیز پشتیبانی می‌کنند.


روش استفاده‌ی از فایل‌های ثابت موجود در یک کتابخانه

این فایل‌های ثابت به همراه بسته‌ی نهایی پروژه، به صورت خودکار توزیع می‌شوند (و نیازی به ارائه‌ی مجزای آن‌ها نیست) و برای استفاده‌ی از آن‌ها در پروژه‌های دیگر، باید از روش مسیردهی زیر استفاده کرد:
/_content/PackageId/MyImage.png
- content_ مسیر آغاز کننده‌ی دسترسی به منابع یک کتابخانه‌ی کامپوننت‌های Blazor است.
- PackageId عموما همان نام پروژه‌ی مورد استفاده‌است (نام فایل csproj مانند MyBlazorComponentLibrary). هرچند می‌توان آن‌را به صورت مجزایی در فایل csproj نیز مقدار دهی کرد.
- در این مثال MyImage.png، نام منبعی است که قرار است از آن استفاده کنیم و پیشتر در پوشه‌ی wwwroot کتابخانه، کپی شده‌است و یا حتی می‌توان زیر پوشه‌هایی را نیز در اینجا ایجاد و از آن‌ها استفاده کرد؛ مانند:
/_content/MyBlazorComponentLibrary/scripts/HelloWorld.js
همچنین باید دقت داشت که مداخل فایل‌های اسکریپتی کتابخانه را مانند:
<script src="_content/MyBlazorComponentLibrary/exampleJsInterop.js"></script>
در برنامه‌های Blazor WASM باید به فایل wwwroot/index.html و در برنامه‌های Blazor Server به فایل Pages/_Host.cshtml افزود و این مداخل باید پیش از یکی از فایل‌های framework/blazor.server.js_ و یا framework/blazor.webassembly.js_ تعریف شوند.


روش استفاده‌ی از کتابخانه‌ی نهایی تولید شده

برای استفاده‌ی از کتابخانه‌ی نهایی تولید شده یا می‌توان ارجاعی را به فایل csproj آن، به پروژه‌ی خود افزود:
<ItemGroup>
   <ProjectReference Include="..\MyBlazorComponentLibrary\MyBlazorComponentLibrary.csproj" />
</ItemGroup>
و یا می‌توان بسته‌ی نیوگت آن‌را (در صورت وجود) نصب کرد.

پس از آن، جهت سهولت استفاده‌ی از این کامپوننت‌های اشتراکی، بهتر است فضای نام آن‌ها را به فایل Imports.razor_ پروژه‌ی خود افزود؛ تا نیازی به تعریف آن‌ها در تمام کامپوننت‌های مورد استفاده نباشد.
‫۳ سال و ۴ ماه قبل، جمعه ۳۱ اردیبهشت ۱۴۰۰، ساعت ۱۶:۲۵
وحید نصیری وحید نصیری
نظرات مطالب
حل مشکل ویژوال استودیو در سیستمهایی که از رزولوشن (DPI) بالا و مانیتور های 4K استفاده می کنند
- به روز رسانی ویندوز 10 در این مورد
«High-DPI Scaling Improvements for Desktop Applications in the Windows 10 Creators Update »
- انتشار NET 4.7. با پشتیبانی بهتر از مانیتورهایی با DPI بالا
- Windows Forms HDPI Samples    
‫۷ سال و ۶ ماه قبل، چهارشنبه ۱۶ فروردین ۱۳۹۶، ساعت ۰۵:۵۶
وحید نصیری وحید نصیری
اشتراک‌ها
یاد گرفتن زبان‌های برنامه نویسی زمان‌بر است
تصور اینکه هر ماه می‌توان زبان جدیدی را آموخت شاید به ظاهر درست باشد اما عمیق نبوده و الزاما منجر به تولید محصولی با کیفیت نخواهد شد. حتی موتزارت که در 4 سالگی یک اعجوبه‌ی موسیقی بود، 13 سال طول کشید تا اولین موسیقی در سطح جهانی خود را تولید کند.
یاد گرفتن زبان‌های برنامه نویسی زمان‌بر است
‫۱۰ سال و ۹ ماه قبل، چهارشنبه ۲ بهمن ۱۳۹۲، ساعت ۱۳:۲۴