پاسخ به بازخورد‌های پروژه‌ها
Report Viewer
- نه. حاصل این گزارشات یا کلا فایل‌های PDF نوعی HTML نیستند. PDF یک فرمت مستقل و بسیار پیشرفته‌تر است. (من در مورد عکس آن یعنی تبدیل HTML به PDF مطلب نوشتم)
- یک سری مثال در سورس‌های این کتابخانه موجود است که نحوه استفاده از active-x خود شرکت adobe را جهت نمایش گزارشات در winforms و wpf بیان می‌کند.
- در وب هم این اکتیو ایکس به صورت خودکار کار می‌کند. فقط کافی است استفاده کننده adobe reader را نصب کرده باشد.
- به علاوه امکان تبدیل PDF به تصویر هم وجود دارد. می‌تونید لینک‌های این گروه رو دنبال کنید:
iTextSharp
در لینک‌ها فوق، شما یک سری جمع آوری اطلاعات را در مورد نحوه‌های دیگر نمایش فایل‌های PDF، مشاهده می‌کنید و از هم مهم‌تر در این بین پروژه pdf.js فایرفاکس است (که از نگارش 15 جزئی از فایرفاکس شده).
مطالب
Debugging برنامه هایی که از خط فرمان پارامتر می گیرند!
بسیاری از برنامه‌ها وجود دارند که در زمان فراخوانی از خط فرمان (Command Line) پارامترهایی دریافت می‌کنند و نسبت به آن پارامترها رفتار مشخصی را از خود نشان می‌دهند.
یکی از کاربرد‌های پارامتر ورودی args که از نوع آرایه ای از رشته‌ها در متد Main برنامه‌های کنسول بطور پیش فرض تعریف شده است همین موضوع است. شما می‌توانید از طریق کنترل مقدار این پارامتر برنامه‌ی خود را توسعه دهید.
برای مثال برنامه ای جهت چاپ مجذور اعدادی که از خط فرمان خوانده می‌شوند را در نظر بگیرید. کد مورد استفاده در این برنامه به شکل زیر خواهد بود:
static void Main(string[] args)
{
    foreach (var arg in args)
    {
        var x = Convert.ToInt32(arg);
        Console.WriteLine("{0} ^ 2 = {1}", x, x * x);
    }
    Console.ReadKey();
}

اما نکته اصلی این مطلب در مورد Debugging این گونه برنامه‌ها است.
جهت دیباگ این قبیل برنامه‌ها در ویژوال استادیو از قسمت Solution Explorer بر روی نام پروژه کلیک راست کرده و گزینه Properties را انتخاب کنید.
در پنجره باز شده به زبانه Debug بروید و در قسمت Command Line Arguments پارامترهای ورودی خود را بطوریکه با فضای خالی (Space) از هم جدا شده اند وارد کنید.
 

حال می‌توانید پس از ذخیره کردن تنظیمات، کلید F5 را بزنید.
مطالب
امکان استفاده از یک هارد SSD بجای RAM در SQL Server 2014
Buffer Pool یکی از مصرف کنندگان اصلی حافظه در SQL Server است. برای مثال زمانیکه اطلاعاتی را از بانک اطلاعاتی دریافت می‌کنید، این داده‌ها در Buffer Pool کش می‌شوند. همچنین SQL Server اطلاعات کلیه Execution Plans را نیز در Plan Cache که جزئی از Buffer Pool است، برای استفاده‌ی مجدد نگهداری می‌کند. هر چقدر حافظه‌ی فیزیکی سرور شما بیشتر باشد، مقدار Buffer Pool نیز به همین میزان افزایش خواهد یافت که البته حداکثر آن‌را می‌توان در تنظیمات حافظه‌ی سرور محدود کرد (Max Server Memory setting).
در دنیای واقعی میزان حافظه‌ی فیزیکی سرورها محدود است. در SQL Server 2014 راه حلی برای این مشکل تحت عنوان Buffer Pool Extensions ارائه شده‌است که محل قرارگیری آن‌را در تصویر ذیل مشاهده می‌کنید:


Buffer Pool Extensions از یک فایل ساده که به آن Extension File نیز گفته می‌شود، تشکیل شده‌است و امکان ذخیره سازی آن بر روی هاردهای سریعی مانند SSD Driveها میسر است. این فایل، ساختاری را همانند page file، در سیستم عامل ویندوز دارد. در این حالت بجای اضافه کردن RAM بیشتر به سرور، یک Extension File را می‌توان بکار گرفت. هر زمان که Buffer Pool اصلی تحت فشار قرار گیرد (به میزان حافظه‌ای بیش از حافظه‌ی فیزیکی سرور نیاز باشد)، از این افزونه‌ی فایلی استفاده خواهد شد.
اطلاعات جزئیات Buffer Pool را توسط کوئری ذیل می‌توان بدست آورد:
 Select * from sys.dm_os_buffer_descriptors


نحوه‌ی فعال سازی و تنظیم Buffer Pool Extensions

قبل از هر کاری بهتر است وضعیت افزونه‌ی Buffer pool را بررسی کرد:
 select * from sys.dm_os_buffer_pool_extension_configuration


همانطور که ملاحظه می‌کنید، در حالت پیش فرض غیرفعال است.
سپس یک فایل یک گیگابایتی را به عنوان افزونه‌ی Buffer pool ایجاد می‌کنیم.
 ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION ON
 (FILENAME = 'd:\BufferPoolExt.BPE', SIZE = 1GB);
توصیه شده‌است که این فایل را در یک درایور پر سرعت SSD قرار دهید؛ ولی محدودیتی از لحاظ محل قرارگیری ندارد (هر چند به نظر فقط در حالتیکه از SSD Drive استفاده شود واقعا کار می‌کند).
اینبار اگر کوئری اول را اجرا کنیم، چنین خروجی قابل مشاهده است:


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


تغییر اندازه‌ی افزونه‌ی Buffer pool

اگر سعی کنیم، یک گیگابایت را مثلا به 10 گیگابایت افزایش دهیم:
 ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION ON
 (FILENAME = 'd:\BufferPoolExt.BPE', SIZE = 10GB);
با خطای ذیل مواجه خواهیم شد:
 Could not change the value of the 'BPoolExtensionPath' property
برای رفع این مشکل، ابتدا باید افزونه‌ی Buffer pool را غیرفعال کرد:
 ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION OFF
سپس می‌توان مجددا اندازه و یا مسیر دیگری را مشخص کرد. بهتر است اندازه‌ی این فایل را حدود 16 برابر حداکثر میزان حافظه‌ی سرور (Max Server Memory) تعیین کنید.
همچنین توصیه شده‌است که پس از غیرفعال کردن این افزونه، بهتر است یکبار instance جاری را ری استارت کنید.


چه زمانی بهتر است از افزونه‌ی Buffer pool استفاده شود؟
در محیط‌های read-heavy OLTP، استفاده از یک چنین افزونه‌ای می‌تواند میزان کارآیی و پاسخگویی سیستم را به شدت افزایش دهد (تا 50 درصد).


سؤال: آیا غیرفعال کردن افزونه‌ی Buffer pool سبب از دست رفتن اطلاعات می‌شود؟
خیر. BPE، تنها clean pages را در خود ذخیره می‌کند؛ یعنی تنها اطلاعاتی که Commit شده‌اند در آن حضور خواهند داشت و در این حالت حذف آن یا ری استارت کردن سرور، سبب از دست رفتن اطلاعات نخواهند شد.


برای مطالعه بیشتر

Buffer Pool Extension
SQL Server 2014 Buffer Pool Extensions
Do you require a SSD to use the Buffer Pool Extension feature in SQL Server 2014
Buffer Pool Extensions in SQL Server 2014
SQL Server 2014 – Buffer Pool Extension
نظرات مطالب
ASP.NET MVC #24
سری «پایه» همین مباحث است. شما با این اطلاعات راحت می‌تونید یک پروژه رو جمع کنید.
ASP.NET MVC 4 نسبت به نگارش 3 آن، آنچنان تغییرات اساسی را به همراه ندارد. یک سری افزونه جدید دارد جهت فشرده سازی اسکریپت‌ها و cssها،‌ اندکی بهبود Razor و یک سری مسایل امنیتی که من لابلای همین سری به آن‌ها اشاره داشتم و ... از این نوع مباحث + مبحث Web API رو اضافه کردن که به نوعی ترکیب WCF با ASP.NET MVC است به نحوی شکیل!
البته مجوز نگارش 4 بتای آن که در دسترس هست، Go live است یعنی می‌تونید همین الان در محیط کار ازش استفاده کنید. هر زمان که نگارش نهایی آن آمد من یک سری ارتقاء به MVC4 رو اضافه خواهم کرد.
مابقی مسایل هم بیشتر تکنیک است تا مباحث پایه. مثلا تکنیک‌های استفاده از jQuery UI در ASP.NET MVC یا استفاده از Kendo UI در ASP.NET MVC و موارد مشابه.
مطالب
بررسی سایز و پسوند فایل آپلود شده قبل از ارسال به سرور
می توان قبل از اینکه کاربر فایلی را سمت سرور ارسال کند پسوند فایل را چک کرد و از یک رفت و برگشت بیهوده به سرور جلوگیری کرد .
یک پیاده سازی ساده به کمک jQuery :
var ext = $('#my_file_field').val().split('.').pop().toLowerCase();
if($.inArray(ext, ['gif','png','jpg','jpeg']) == -1) {
    alert('invalid extension!');
}
 
 در کد بالا ابتدا پسوند فایل انتخاب شده توسط کاربر پیدا می‌شود ، سپس به کمک متد inArray با آرایه ای از پسوند‌های دلخواه ما مقایسه می‌شود و در صورت معتبر نبودن پیغامی به کاربر نشان می‌دهد.
کد بالا را می‌توان در رویداد Change کنترل فایل یا در هنگام Post شدن Form اطلاعات قرار داد.
کاملا واضح است که این روش را می‌توان به راحتی دور زد و نباید به آن اکتفا کرد.
مثال این روش را اینجا بررسی کنید.
بررسی سایز فایل :
در اکثر برنامه‌های تحت وب کاربرها محدود به Upload فایل تا سایز خاصی هستند ، این مورد را هم می‌توان قبل از Upload کنترل و اعتبارسنجی کرد : 
//binds to onchange event of your input field
$('#myFile').bind('change', function() {

  //this.files[0].size gets the size of your file.
  alert(this.files[0].size);

});
این روش تا زمانی که کاربر JavaScript را غیر فعال نکرده قابل اطمینان است.
مطالب
ارتقاء به ASP.NET Core 2.0 - معرفی بسته‌ی Microsoft.AspNetCore.All
یکی از مهم‌ترین تغییرات ASP.NET Core 2.0، نسبت به نگارش‌های قبلی آن، ارائه‌ی یک «متا پکیج» جدید به نام Microsoft.AspNetCore.All است. این بسته به همراه تمام وابستگی‌های مورد نیاز جهت توسعه‌ی برنامه‌های ASP.NET Core 2.0 است؛ این «تمام» شامل تمام بسته‌های Razor، بسته‌های MVC، بسته‌های EF Core و غیره است. به این ترتیب به روز رسانی بسته‌های وابسته‌ی به هم، بسیار ساده خواهد شد و همچنین به فایل‌های csproj بسیار خلوت و قابل مدیریتی، خواهیم رسید.


بسته‌ی Microsoft.AspNetCore.All فقط مخصوص پروژه‌های netcoreapp2.0 است

این «متا پکیج» تنها در پروژه‌هایی که TargetFramework آن‌ها به netcoreapp2.0 تنظیم شده‌است، قابل استفاده می‌باشد:
 <TargetFramework>netcoreapp2.0</TargetFramework>
اگر TargetFramework تنظیمی netstandard2.0 باشد، قادر به استفاده‌ی از آن نخواهید بود. در این حالت باید مانند سابق، تک تک بسته‌های مورد نیاز را در فایل csproj به صورت جداگانه‌ای تعریف کنید.


نحوه‌ی به روز رسانی پروژه‌ها جهت استفاده‌ی از Microsoft.AspNetCore.All

پیش از ناقص کردن برنامه و حذف بسته‌های نیوگتی که نباید از فایل csproj حذف شوند، ابتدا باید لیستی را که توسط «متا پکیج» Microsoft.AspNetCore.All ارائه می‌شود، بررسی کرد. این لیست را پس از نصب SDK جدید، در آدرس ذیل می‌توانید مشاهده کنید:
 C:\Program Files\dotnet\store\x64\netcoreapp2.0


روش دیگر یافتن این لیست، مراجعه‌ی به سایت نیوگت و بررسی قسمت dependencies آدرس https://www.nuget.org/packages/Microsoft.AspNetCore.All است:


سپس به فایل csproj ایی که دارای TargetFramework مساوی netcoreapp2.0 است مراجعه کرده و هر کدام از بسته‌هایی را که در این لیست قرار دارند ... حذف کنید. در آخر بجای تمام این مداخل حذف شده، یک مدخل کلی ذیل را تعریف کنید:
<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
</ItemGroup>


سؤال: آیا استفاده‌ی از بسته‌ی Microsoft.AspNetCore.All، ارائه‌ی نهایی برنامه را حجیم نمی‌کند؟

اگر به مسیر dotnet\store ایی که پیشتر عنوان شد مراجعه کنید، در اینجا بیش از 180 بسته را خواهید یافت. در این حالت شاید به نظر برسد که حجم نهایی قابل توزیع برنامه‌های ASP.NET Core با استفاده از تک مدخل Microsoft.AspNetCore.All بسیار بالا خواهد رفت. اما ... خیر.
NET Core 2.0. به همراه ویژگی جدیدی است به نام Runtime store. هدف از آن، پیش نصب بسته‌ها بر روی سیستم جاری، در یک مکان مرکزی است تا دیگر در حین توزیع نهایی برنامه، نیازی به توزیع مجدد آن‌ها نباشد. به همین جهت، به آن می‌توان شبیه به مفهوم پیشین Global assembly cache یا GAC مخصوص NET Core. نگاه کرد. به علاوه تمام این بسته‌ها ngen شده و سرعت آغاز و اجرای برنامه‌ها را بهبود می‌بخشند.
زمانیکه SDK جدید NET Core 2.0. را نصب می‌کنید، تمام بسته‌های مورد نیاز آن، در مسیر مرکزی C:\Program Files\dotnet\store نصب می‌شوند. بنابراین سیستمی که به همراه این SDK باشد، حتما حاوی تمام وابستگی‌های ذکر شده‌ی در متاپکیج Microsoft.AspNetCore.All نیز خواهد بود و در این حالت نیازی به توزیع مجدد آن‌ها نیست.
پس از آن مهم‌ترین تفاوتی را که مشاهده خواهید کرد، کاهش حجم نهایی برنامه‌های ASP.NET Core 2.0 نسبت به نگارش‌های 1x است. برای آزمایش، یک برنامه‌ی ASP.NET Core 1.x و سپس یک برنامه‌ی ساده‌ی ASP.NET Core 2.x را publish کنید.
این تصویر، پوشه‌ی نهایی قابل توزیع یک برنامه‌ی ASP.NET Core 1.x را پس از publish نمایش می‌دهد:

و این تصویر، پوشه‌ی نهایی قابل توزیع یک برنامه‌ی ASP.NET Core 2.x را پس از publish نمایش می‌دهد:

در این حالت پوشه‌ی نهایی نگارش 1x شامل 94 آیتم و پوشه‌ی نهایی نگارش 2x شامل 13 آیتم است. یعنی حجم نهایی را که باید ارائه داد، به شدت کاهش یافته‌است.


بالا رفتن کارآیی تازه واردان به دنیای ASP.NET Core با متاپکیج جدید Microsoft.AspNetCore.All

یکی از مشکلاتی که به همراه کار با ASP.NET Core 1.x وجود دارد، مشخص نبودن محل قرارگیری ویژگی‌های جدید و بسته‌های مرتبط با آن‌ها است. همچنین به ازای هر ویژگی جدید باید یک بسته‌ی نیوگت جدید را نصب کرد و عموما یافتن این‌ها و یا دانستن وجود آن‌ها، کار دشواری می‌باشد.
اما زمانیکه متابسته‌ی Microsoft.AspNetCore.All به قسمت ارجاعات پروژه اضافه می‌شود، در آغاز کار برنامه، سیستم IntelliSense آن‌ها را پردازش کرده و بلافاصله در اختیار برنامه نویس قرار می‌گیرند. این قابلیت حتی در VSCode نیز همانند Visual Studio کار می‌کند و توسعه دهنده‌ها بلافاصله IntelliSense بسیار کاملی را از قابلیت‌های موجود در اختیار خواهند داشت؛ به همراه ویژگی‌های تکمیلی دیگری مانند افزودن و یا اصلاح ساده‌تر فضاهای نام مرتبط.
نظرات مطالب
بررسی روش آپلود فایل‌ها از طریق یک برنامه‌ی Angular به یک برنامه‌ی ASP.NET Core
سلام.
من برای دانلود فایل در بخش api ام این کد رو نوشتم:
public async Task<ServiceResult<FileContentResult>> GetByFileFolderId(int id)
        {
            var file = await FileRepository.GetByFileFolderId( id);
            var locatedFile = (byte[])Convert.ChangeType(file.FileData64, typeof(byte[]));
            var result= new FileContentResult(locatedFile, new
            MediaTypeHeaderValue("application/pdf"))
            {
                FileDownloadName = "SomeFileDownloadName.pdf"
            };
            return Ok(result);
        }
و در بخش کلاینت از این کد استفاده کردم:
getPDF(fileId): Observable<Blob> {
    const uri = 'MyApiUri/GetByFileFolderId?id=' + fileId;
    return this.http.get(uri, { responseType: 'blob' });
  }

downloadFile(){
this.getPDF()
.subscribe(x => {
  var newBlob = new Blob([x], { type: "application/pdf" });

  const data = window.URL.createObjectURL(newBlob);
  var link = document.createElement('a');
  link.href = data;
  link.download = "SomeFileDownloadName.pdf";
  link.dispatchEvent(new MouseEvent('click', { bubbles: true, cancelable: true, view: window }));
  setTimeout(function () {
      window.URL.revokeObjectURL(data);
      link.remove();
  }, 100);
});
}
ولی زمانی که فایل رو دانلود میکنه و فایل رو میخوام باز کنم ارور This PDF is corrupted میده. و برای انواع دیگر فایل هم همین مشکل رو داره و نمیتونه محتوای فایل رو تشخیص بده.
مطالب
آموزش Xamarin Forms - قسمت دوم - بررسی ساختار پروژه‌های زمارین

در  مقاله قبلی، درباره نحوه نصب و راه اندازی اولین پروژه Xamarin Forms کمی صحبت کردیم. حال وقت آن رسیده‌است که درباره ساختار اپلیکیشن‌های Xamarin Forms  بیشتر بحث کنیم. در سیستم عامل‌های مختلف، رابط‌های کاربری با اسامی مختلفی مانند Control ، Widget ، View  و Element صدا زده میشوند که هدف تمامی آنها نمایش و ارتباط با کاربر میباشد. در Xamarin Forms به تمام عناصری که در صفحه نمایش نشان داده میشوند، Visual Elements گفته میشود؛ که در سه گروه بندی اصلی قرار میگیرند:

· Page

· Layout

· View

هر چیزی که فضایی را در صفحه اشغال کند، یک Visual Element است. Xamarin Forms از یک ساختار سلسه مراتبی Parent-Child برای UI استفاده میکند. به طور مثال یک اپلیکیشن را در نظر بگیرید. هر اپلیکیشن به طور کلی از چندین صفحه تشکیل شده است. هر Page برای چینش کنترل‌های مختلف، از یک سری Layout استفاده میکند و هر Layout هم شامل چندین View مختلف میباشد.

 در  مقاله قبلی، پروژه اولیه خود را ساختیم. اگر به پروژه Shared مراجعه کنیم، خواهیم دید که این پروژه دارای کلاسی به نام App است. اگر به خاطر داشته باشید، گفتیم که این کلاس اولین Page درون اپلیکیشن را مشخص میکند و همچنین میتوان برای مدیریت LifeCycle اپلیکیشن مانند OnStart و ... از آن استفاده کرد. در متد سازنده، صفحه‌ای به نام MainPage به عنوان اولین صفحه برنامه مشخص شده بود. به کدهای این صفحه بار دیگر نگاهی کنیم تا بتوانیم کمی بر روی این کدها توضیحاتی را ارائه دهیم:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:PreviewerTest"
             x:Class="PreviewerTest.MainPage">
<Label Text="Welcome to Xamarin Forms!"
           VerticalOptions="Center"
           HorizontalOptions="Center" />
</ContentPage>

همانطور که میبینید ساختار سلسه مراتبی را به خوبی میتوانید در این کدها مشاهده کنید. در وهله اول یک ContentPage را به عنوان والد اصلی مشاهده میکنید. Page ‌ها در Xamarin Forms انواع مختلفی دارند که ContentPage یکی از آنهاست و از آن میتوانید به عنوان یک صفحه ساده استفاده کنید.

در درون این صفحه یک Label را به عنوان Child صفحه مشاهده میکنید (تمامی کنترل‌ها در زمارین در زیر گروه View قرار میگیرند).

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

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:XamarinSample"
             x:Class="XamarinSample.MainPage">
    <StackLayout>
        <Label Text="Welcome to Xamarin Forms!" VerticalOptions="Center" HorizontalOptions="Center" />
        <Button Text="Ok!"/>
    </StackLayout>
</ContentPage>

StackLayout عناصر فرزند خود را به صورت افقی و عمودی در کنار هم در صفحه میچیند. 

اگر به خاطر داشته باشید، در هنگام ساخت پروژه زمارین چندین پروژه برای پلتفرم‌های مختلف در کنار آن ساخته شد. پروژه XamarinSample.Android  برای ساخت و مدیریت پروژه در پلتفرم اندروید، مورد استفاده قرار میگیرد. همانطور که گفتیم کدهای درون این پروژه‌ها با پروژه Shared ادغام شده و با هم اجرا خواهند شد. وقت آن رسیده که سری به کدهای آن بزنیم و نحوه‌ی اجرای پروژه Shared را توسط پروژه اندروید ببینیم.

وقتی پروژه اندروید را باز کنید با کلاسی به نام MainActivity مواجه خواهید شد. این کلاس وظیفه ایجاد Activity اصلی برنامه را دارد. 

namespace XamarinSample.Droid {
 [Activity(Label = "XamarinSample", Icon = "@drawable/icon", Theme = "@style/MainTheme", MainLauncher = true, ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)]
 public class MainActivity: global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity {
  protected override void OnCreate(Bundle bundle) {
   TabLayoutResource = Resource.Layout.Tabbar;
   ToolbarResource = Resource.Layout.Toolbar;

   base.OnCreate(bundle);

   global::Xamarin.Forms.Forms.Init(this, bundle);
   LoadApplication(new XamarinSample.App());
  }
 }
}

در Attribute بالای سر کلاس، برخی از ویژگی‌ها مانند تم، آیکن، سایز و ... مقداردهی شده‌اند. همچنین باعث میشود که در صورت تغییر Orientation و سایز، Activity از اول ساخته نشود. در متد OnCreate علاوه بر استایل دهی به TabLayout و ToolBar ‌ها متدی به نام Forms.Init صدا زده شده است. این متد استاتیک که در تمامی پروژه‌ها فراخوانی میشود، سیستم Xamarin Forms را در هر کدام از پلت فرم‌ها بارگزاری میکند.

نظرات مطالب
PHP سریعتر از ASP.NET! افسانه یا واقعیت؟
خوب، مثال‌های بحث جاری در ساده‌ترین حالت ممکن تهیه شدند. یعنی یک فریم ورک ASP.NET با کلی دم و دستگاه (ماژول سشن، ماژول مسیریابی، ماژول امنیت، ماژول اعتبارسنجی درخواست‌ها، ماژول فشرده سازی و ...) از یک سیستم ساده PHP سریعتر عمل می‌کنه. این چطور بی‌ربط به عنوان مقاله هست؟
نظرات مطالب
فشرده سازی خروجی فایلهای استاتیک سایت
در مورد تصویر ارسالی:
در این سایت از این روش  (System.Web.Optimization) استفاده می‌شود. روش یاد شده در IIS7 خروجی فشرده شده با GZip نیز دارد؛ اما نه در IIS6. ولی در هر دو حالت، کش را تنظیم می‌کند:

به همین جهت در بار بعدی مشاهده سایت، دیگر درخواست اضافه‌ای جهت دریافت اسکریپت‌ها و شیوه نامه‌ها ارسال نخواهد شد: