نگاهی به طراحی جدید Firefox 89
روش معمول انجام اینکار، به روز رسانی دستی تمام فایلهای AssemblyInfo.cs یک Solution است و همچنین اطمینان حاصل کردن از همگام بودن آنها. در ادامه قصد داریم با استفاده از فایلهای T4، یک فایل SharedAssemblyInfo.tt را جهت تولید اطلاعات مشترک Build بین اسمبلیهای مختلف یک پروژه، تولید کنیم.
ایجاد پروژهی SharedMetaData
برای نگهداری فایل مشترک SharedAssemblyInfo.cs نهایی و همچنین اطمینان از تولید مجدد آن به ازای هر Build، یک پروژهی class library جدید را به نام SharedMetaData به Solution جاری اضافه کنید.
سپس نیاز است یک فایل text template جدید را به نام SharedAssemblyInfo.tt، به این پروژه اضافه کنید.
به خواص فایل SharedAssemblyInfo.tt مراجعه کرده و Transform on build آنرا true کنید. به این ترتیب مطمئن خواهیم شد این فایل به ازای هر build جدید، مجددا تولید میگردد.
اکنون محتوای این فایل را به نحو ذیل تغییر دهید:
<#@ template debug="false" hostspecific="false" language="C#" #> // // This code was generated by a tool. Any changes made manually will be lost // the next time this code is regenerated. // using System.Reflection; using System.Resources; using System.Runtime.CompilerServices; using System.Runtime.InteropServices; [assembly: AssemblyCompany("some name")] [assembly: AssemblyCulture("")] [assembly: NeutralResourcesLanguageAttribute("en")] [assembly: AssemblyProduct("product name")] [assembly: AssemblyCopyright("Copyright VahidN 2014")] [assembly: AssemblyTrademark("some name")] #if DEBUG [assembly: AssemblyConfiguration("Debug")] #else [assembly: AssemblyConfiguration("Release")] #endif // Assembly Versions are incremented manually when branching the code for a release. [assembly: AssemblyVersion("<#= this.MajorVersion #>.<#= this.MinorVersion #>.<#= this.BuildNumber #>.<#= this.RevisionNumber #>")] // Assembly File Version should be incremented automatically as part of the build process. [assembly: AssemblyFileVersion("<#= this.MajorVersion #>.<#= this.MinorVersion #>.<#= this.BuildNumber #>.<#= this.RevisionNumber #>")] <#+ // Manually incremented for major releases, such as adding many new features to the solution or introducing breaking changes. int MajorVersion = 1; // Manually incremented for minor releases, such as introducing small changes to existing features or adding new features. int MinorVersion = 0; // Typically incremented automatically as part of every build performed on the Build Server. int BuildNumber = (int)(DateTime.UtcNow - new DateTime(2013,1,1)).TotalDays; // Incremented for QFEs (a.k.a. “hotfixes” or patches) to builds released into the Production environment. // This is set to zero for the initial release of any major/minor version of the solution. int RevisionNumber = 0; #>
MajorVersion با افزودن تعداد زیادی قابلیت به برنامه، به صورت دستی تغییر میکند. همچنین اگر یک breaking change در برنامه یا کتابخانه وجود داشته باشد نیز این شماره باید تغییر نماید.
MinorVersion با افزودن ویژگیهای کوچکی به نگارش فعلی برنامه تغییر میکند.
BuildNumber به صورت خودکار بر اساس هر Build انجام شده باید تغییر یابد. در اینجا این عدد به صورت خودکار به ازای هر روز، یک واحد افزایش پیدا میکند. ابتدای مبداء آن در این مثال، 2013 قرار گرفتهاست.
RevisionNumber با ارائه یک وصله جدید برای نگارش فعلی برنامه، به صورت دستی باید تغییر کند. اگر اعداد شماره نگارش major یا minor تغییر کنند، این عدد باید به صفر تنظیم شود.
اکنون اگر این محتوای جدید را ذخیره کنید، فایل SharedAssemblyInfo.cs به صورت خودکار تولید خواهد شد.
افزودن فایل SharedAssemblyInfo.cs به صورت لینک به تمام پروژهها
نحوهی افزودن فایل جدید SharedAssemblyInfo.cs به پروژههای موجود، اندکی متفاوت است با روش معمول افزودن فایلهای cs هر پروژه. ابتدا از منوی پروژه گزینهی add existing item را انتخاب کنید. سپس فایل SharedAssemblyInfo.cs را یافته و به صورت add as link، به تمام پروژههای موجود اضافه کنید.
اینکار باید در مورد تمام پروژهها صورت گیرد. به این ترتیب چون فایل SharedAssemblyInfo.cs به این پروژهها صرفا لینک شدهاست، اگر محتوای آن در پروژهی metadata تغییر کند، به صورت خودکار و یک دست، در تمام پروژههای دیگر نیز منعکس خواهد شد.
در ادامه اگر بخواهید Solution را Build کنید، پیام تکراری بودن یک سری از ویژگیها را یافت خواهید کرد. این مورد از این جهت رخ میدهد که هنوز فایلهای AssemblyInfo.cs اصلی، در پروژههای برنامه موجود هستند.
این فایلها را یافته و صرفا چند سطر همیشه ثابت ذیل را در آنها باقی بگذارید:
using System.Reflection; using System.Runtime.InteropServices; [assembly: AssemblyTitle("title")] [assembly: AssemblyDescription("")] [assembly: ComVisible(false)] [assembly: Guid("9cde6054-dd73-42d5-a859-7d4b6dc9b596")]
اضافه کردن build dependency به پروژه MetaData
در پایان کار نیاز است اطمینان حاصل کنیم، فایل SharedAssemblyInfo.cs به صورت خودکار پیش از Build هر پروژه، تولید میشود. برای این منظور، از منوی Project، گزینهی Project dependencies را انتخاب کنید. سپس در برگهی dependencies آن، به ازای تمام پروژههای موجود، گزینهی SharedMetadata را انتخاب نمائید.
این مساله سبب اجرای خودکار فایل SharedAssemblyInfo.tt پیش از هر Build میشود و به این ترتیب میتوان از تازه بودن اطلاعات SharedAssemblyInfo.cs اطمینان حاصل کرد.
اکنون اگر پروژه را Build کنید، تمام اجزای آن شماره نگارش یکسانی را خواهند داشت:
و در دفعات آتی، تنها نیاز است تک فایل SharedAssemblyInfo.tt را برای تغییر شماره نگارشهای اصلی، ویرایش کرد.
مدیریت سفارشی سطوح دسترسی کاربران در MVC
البته این نام پیشفرض است. اگر نیاز به تعیین نام دیگری بود به این صورت میشود عمل کرد:
<roleManager enabled="true" cacheRolesInCookie="true" defaultProvider="..." cookieName=".ASPXROLES" cookiePath="/" cookieTimeout="30" cookieRequireSSL="false" cookieSlidingExpiration="true" createPersistentCookie="false" cookieProtection="All"> <providers> <!-- .... --> </providers> </roleManager>
- اگر از دات نت 4 و نیم استفاده میکنید، برای حالت کش نشدن این نقشها اخیرا یک patch ارائه شده : (^). مورد چهارم آن.
Assume that you set the value of the cachedRolesInCookie property to true in your web application. Your application serializes the RolePrincipal object into the cookie, and then sends it in response. In this situation, the role cookie value is empty in the application's following request.
مروری بر نحوهی توزیع برنامههای Blazor بر روی IIS
1- پیش از هر کاری باید مطابق نگارش ASP.NET Core در حال استفاده (که به عنوان هاست Blazor Server و یا ارائه دهندهی قسمت Web API برنامهی سمت کلاینت WASM مطرح است)، بستهی NET Core hosting bundle. را نصب کرد که عموما تحت عنوان «Hosting Bundle Installer» قابل دریافت است.
نکتهی مهم: همانند تمام نگارشهای دات نت، در اینجا نیز باید Hosting Bundle را پس از نصب IIS، بر روی سیستم نصب کرد. اگر این ترتیب تغییر کند، یکبار دیگر نصاب آنرا اجرا کرده و گزینهی ترمیم نصب را انتخاب کنید تا یکپارچگی آن با IIS صورت گیرد.
2- نیاز است برنامهی خود را اصطلاحا publish کرد تا به همراه فایلهای نهایی قابل کپی باشد که در پوشهای توسط IIS هاست خواهند شد. برای اینکار اگر از نگارش کامل ویژوال استودیو استفاده میکنید، فقط کافی است بر روی پروژهی مدنظر کلیک راست کرده و از منوی باز شده، گزینهی publish را انتخاب کنید و مراحل آنرا طی نمائید و یا این مراحل را میتوان توسط دستور خط فرمان زیر نیز خلاصه کرد که وابستگی خاصی، به IDE ویژهای ندارد و چند سکویی است:
dotnet publish -o "c:\dir1\dir2" -c Release
و یا اگر فقط دستور dotnet publish -c Release را در ریشهی پروژه اجرا کنیم، خروجی نهایی را در پوشهی bin\Release\net5.0\publish میتوان مشاهده کرد که به همراه یک web.config مخصوص برنامههای blazor هم هست و در آن mime typeهای متناظری، به همراه URL rewriting مناسب برنامههای تک صفحهای وب از پیش تنظیم شدهاست. بنابراین در اینجا نصب ماژول URL rewrite بر روی IIS نیز الزامی است.
3- در اینجا نیز همانند تنظیمات برنامههای ASP.NET Core، باید application pool منتسب به برنامه را ویرایش کرده و NET Clr Version. آنرا بر روی No Managed Code قرار داد.
روش فعالسازی توزیع مبتنی بر فشرده سازی Brotli در IIS
در حین عملیات publish استاندارد، به صورت پیشفرض از تمام فایلها، سه نسخهی اصلی، gz شده (gzip) و یا br شده (فشرده سازی Brotli که فایلهای کم حجمتری را نسبت به gz ارائه میدهد) نیز تهیه میشوند که بسته به نوع مرورگر و پشتیبانی آن از روشهای مختلف فشرده سازی، یکی از آنها در اختیار کلاینت قرار خواهد گرفت که به این صورت کاربران، تجربهی دریافت کم حجمتر و سریعتری را خواهند داشت.
باید دقت داشت Web.config ای که به همراه دستور dotnet publish ایجاد میشود، روش توزیع پیشفرض فایلهای br. تولیدی را ندارد. برای اینکار نیاز است تنظیمات این فایل web.config توصیه شدهی توسط تیم Blazor را به web.config خود اضافه کرد تا در نهایت حجم دریافتی از سرور به شدت کاهش یابد.
یک نکته: اگر میخواهید فایل web.config سفارشی خودتان را داشته باشید، نمونهای از آنرا در ریشهی پروژه قرار داده و سپس فایل csproj را به نحو زیر ویرایش کنید تا از آن در حین publish استفاده کند:
<PropertyGroup> <PublishIISAssets>true</PublishIISAssets> </PropertyGroup>
در حین publish برنامههای Blazor WASM کار IL trimming نیز انجام میشود
برای کاهش حجم نهایی برنامههای Blazor WASM، در حین publish در حالت release، کار IL Trimming نیز به صورت خودکار انجام میشود تا کدهای IL ای که در برنامه نقش نداشتهاند و مستقیما در جائی استفاده نشدهاند، به صورت خودکار حذف شوند و به این ترتیب حجم ارائهی نهایی به شدت کاهش یابد.
فقط باید دقت داشت که در این حالت اگر عملیات پویایی مانند reflection در کدهای شما صورت میگیرد، به علت نداشتن ارجاع استاتیکی به منابع مورد استفاده، در زمان اجرا با مشکل مواجه خواهد شد. اگر میخواهید اخطارهایی را در این زمینه مشاهده کنید، گزینهی زیر را به فایل csproj اضافه نمائید:
<SuppressTrimAnalysisWarnings>false</SuppressTrimAnalysisWarnings>
حذف مباحث بومی سازی در صورت عدم نیاز
اگر در برنامهی خود از مباحث time-zones استفاده نمیکنید، میتوانید با غیرفعال کردن آن در فایل csproj، حداقل 100 کیلوبایت از حجم برنامهی نهایی را کاهش دهید:
<BlazorEnableTimeZoneSupport>false</BlazorEnableTimeZoneSupport>
<InvariantGlobalization>true</InvariantGlobalization>
معماری های رایج برنامه های وب
Most traditional .NET applications are deployed as single units corresponding to an executable or a single web application running within a single IIS appdomain. This approach is the simplest deployment model and serves many internal and smaller public applications very well. However, even given this single unit of deployment, most non-trivial business applications benefit from some logical separation into several layers.
یکی از متداولترین الگوهای امروزی برای رفع وابستگی به یک سرویس در یک Object وابسته به ان سرویس الگوی Dependency Injection میباشد . در این الگو , وابستگی به سایر کلاسها , به صورت اتوماتیک به داخل سرویس مورد نظر تزریق میشود و نیاز به نمونه گیری و ساخت Object از ان وابستگی به صورت Explicit نیست . این الگو در مهندسی نرم افزار فوایدیی (Refactoring , کنترل LifeTime اشیاء , ...) دارد که مرتبط با موضوع این مقاله نیست , اما نحوه صحیح نمونه گیریی از DbContext با الگوی Dependency Injection در انواع برنامهها اعم از وب یا دسکتاپ موضوع اصلی این مقاله میباشد.
با توجه به آخرین نگارشهای موجود Angular و React، انتخاب شما برای انجام یک پروژه بزرگ کدام است؟
When a developer switches context, they must first disengage from the task at hand and then shift their focus to the new task. This whole process takes time and can drain devs mentally. It takes a developer 25 minutes to refocus after a context switch.