نظرات مطالب
آموزش MEF#1
ممنون.
بله حتما در پستهای بعدی در مورد MEF و استفاده اون در (WAF(WPF Application Framework و MVC و
Prism توضیحاتی رو خواهد داد.
بله حتما در پستهای بعدی در مورد MEF و استفاده اون در (WAF(WPF Application Framework و MVC و
Prism توضیحاتی رو خواهد داد.
اشتراکها
NET Framework 4.6.1. منتشر شد
The .NET Framework 4.6.1 includes new features in the following areas:
-
Cryptography
-
ADO.NET
-
Windows Presentation Foundation (WPF)
-
Windows Workflow Foundation
-
Profiling
-
NGen
For more information on the .NET Framework 4.6.1, see the following topics:
-
The .NET Framework API diff (on GitHub)
- توسط httpContextAccessor امکان دسترسی به سشن هم وجود دارد: httpContextAccessor.HttpContext.Session.GetInt32("count").Value
- متغیر Application مربوط هست به دوران Classics ASP دههی نود میلادی (حتی پیش از معرفی ASP.NET Web Forms). این متغیر این روزها با یک ConcurrentDictionary که بدون نیاز به قفل گذاری، امکان تهیه یک دیکشنری thread-safe را میسر میکند، قابلیت جایگزینی را دارد. یک مثال از کاربرد ConcurrentDictionary (OnlineVisitorsModule.zip برای ASP.NET 4.x و MVC 5.x)
- رویدادهای Session_Start و Session_End و کلا مباحث Global.asax در اصل بهتر است به HTTP Modules تبدیل و refactor شوند. HTTP Modules هم در ASP.NET Core به صورت کامل حذف و با مفهوم جدیدی به نام Middlewares جایگزین شدهاند. امکان نوشتن Middlewareهای سفارشی هم وجود دارد.
- متغیر Application مربوط هست به دوران Classics ASP دههی نود میلادی (حتی پیش از معرفی ASP.NET Web Forms). این متغیر این روزها با یک ConcurrentDictionary که بدون نیاز به قفل گذاری، امکان تهیه یک دیکشنری thread-safe را میسر میکند، قابلیت جایگزینی را دارد. یک مثال از کاربرد ConcurrentDictionary (OnlineVisitorsModule.zip برای ASP.NET 4.x و MVC 5.x)
- رویدادهای Session_Start و Session_End و کلا مباحث Global.asax در اصل بهتر است به HTTP Modules تبدیل و refactor شوند. HTTP Modules هم در ASP.NET Core به صورت کامل حذف و با مفهوم جدیدی به نام Middlewares جایگزین شدهاند. امکان نوشتن Middlewareهای سفارشی هم وجود دارد.
نظرات مطالب
EF Code First #12
- Context زمانی تشکیل خواهد شد که کار وهله سازی کنترلر متناظر و موجودی با موفقیت انجام شده باشد.
+ زمانیکه runAllManagedModulesForAllRequests در وب کانفیگ به true تنظیم شده تمام درخواستها به موتور ASP.NET نگاشت میشوند. میشود این وضعیت را کنترل کرد؛ مراجعه کنید به قسمت « تنظیمات ثانویه پس از فعال سازی RouteExistingFiles»
در کل تهیه یک برنامه ASP.NET MVC نیاز به رعایت یک سری موارد دارد که پیشتر در این سایت بحث شده: «چک لیست تهیه یک برنامه ASP.NET MVC». یکی از نکات آن هم «پوشههای Content و Scripts از سیستم مسیریابی تعریف شده در Global.asax خارج شوند» است.
+ زمانیکه runAllManagedModulesForAllRequests در وب کانفیگ به true تنظیم شده تمام درخواستها به موتور ASP.NET نگاشت میشوند. میشود این وضعیت را کنترل کرد؛ مراجعه کنید به قسمت « تنظیمات ثانویه پس از فعال سازی RouteExistingFiles»
در کل تهیه یک برنامه ASP.NET MVC نیاز به رعایت یک سری موارد دارد که پیشتر در این سایت بحث شده: «چک لیست تهیه یک برنامه ASP.NET MVC». یکی از نکات آن هم «پوشههای Content و Scripts از سیستم مسیریابی تعریف شده در Global.asax خارج شوند» است.
نظرات مطالب
ASP.NET Web API - قسمت چهارم
سلام آقای راد
با تشکر از زحمتی که میکشید. فرمودید که :
"بنابراین web api به دنبال متدی در controller میگردد که نام آن با عبارت get "آغاز" شده باشد. "
آیا این کار باعث عدم دقت و ایجاد خطاهای ناخواسته نمیشه؟ این فقط متدی با get شروع بشه شاید برای من که خیلی کم mvc کار کردم یکم مشکل دار به نظر برسه.اگر ما دو متد داشته باشیم که در ابتدای آنها get باشد آیا برنامه خطا میگیرد؟ ممنون میشم یکم در این باره توضیح بدین
من همیشه از حالت web application برای ASP.Net استفاده میکنم.
+ شما در ASP.Net همیشه میتونید نحوه کامپایل شدن را در وب کانفیگ هم تعیین کنید. به این صورت:
compilation defaultLanguage="c#" debug="false"
برای مطالعه بیشتر
http://aspnetresources.com/articles/debug_code_in_production.aspx
و یا استفاده از روش زیر که در آن retail را باید true کنید:
http://msdn.microsoft.com/en-us/library/ms228298(VS.80).aspx
+ شما در ASP.Net همیشه میتونید نحوه کامپایل شدن را در وب کانفیگ هم تعیین کنید. به این صورت:
compilation defaultLanguage="c#" debug="false"
برای مطالعه بیشتر
http://aspnetresources.com/articles/debug_code_in_production.aspx
و یا استفاده از روش زیر که در آن retail را باید true کنید:
http://msdn.microsoft.com/en-us/library/ms228298(VS.80).aspx
یکی از نقشهای IISهای جدید (از نگارش 7 به بعد) که در ویندوز سرورهای قابل نصب است، نقش Performance است و ذیل آن دو نقش فشرده سازی استاتیک و پویا قابل انتخاب است. اگر این نقشها بر روی سرور نصب باشند، دیگر نیازی به استفاده از HTTP Moduleهای متداول فشرده سازی صفحات وب نیست. برای استفادهی از آن تنها کافی است کمی web.config را ویرایش کرد و ... گفته شدهاست که کار میکند! اما پس از اعمال تنظیمات، اگر به هدرهای خروجی Response صفحه در ابزارهای web developer مرورگرها دقت کنید، خبری از encoding جدیدی به نام gzip نیست (Content-Encoding: gzip) و به نظر اعمال نمیشود. در ادامه بررسی خواهیم کرد که چرا اینگونه است.
فعال سازی GZip توکار IIS
تنظیمات پیش فرض فعال سازی ماژول توکار GZip وب سرورهای جدید شامل دو مرحله است:
الف) تنظیمات سرور جهت فعال سازی فشرده سازی
بر روی ویندوزهای سرور، پس از مراجعه به Administrative Tools -> Server Manager و گشودن Roles آن، ذیل قسمت Web Server که در اینجا IIS است، نیاز است نقش جدیدی به نام Performance اضافه شود و مطابق تصویر، هر دو گزینهی فشرده سازی استاتیک و پویا انتخاب گردد.
بنابراین اولین قدم برای عیب یابی کار نکردن GZip توکار IIS، از این مرحله شروع میشود که آیا اصلا ماژول مربوطه نصب هست یا خیر؟
ب) تنظیمات برنامه جهت فعال سازی ماژول GZip
پس از اطمینان از نصب ماژول توکار فشرده سازی صفحات وب IIS در سمت تنظیمات سرور، اکنون باید چند سطر ذیل را به Web.Config برنامه اضافه کرد:
در اینجا تنظیمات مخصوص نحوهی فعال سازی فشرده سازی توکار صفحات پویا و فایلهای استاتیک را مشاهده میکنید. در این تنظیمات محل قرارگیری فایلهای موقتی فشرده شدهی توسط این ماژول و همچنین mime typeهای مدنظر جهت فشرده سازی، ذکر شدهاند. با این تنظیمات، تنها mime typeهایی که به صورت صریح ذکر شدهاند فشرده خواهند شد و از سایر mime types صرفنظر میشود.
این تنظیماتی است که در اکثر سایتها نیز یافت میشود. ذکر آنها اجباری است و پس از اعمال، اگر برنامه را اجرا کنید ... چیزی فشرده نمیشود! علت اصلی را باید در تنظیماتی یافت که مخصوص سرور است و در اینجا ذکر نشدهاند.
تنظیمات مخصوص آستانهی فشرده سازی صفحات
علت اصلی عدم مشاهدهی هدر gzip، در Response برنامه، به frequent hit threshold تنظیم شدهی در IIS بر میگردد. مقدار آن به 2 درخواست در طی 10 ثانیه تنظیم شدهاست. یعنی اگر به صفحهای در طی 10 ثانیه دو درخواست نرسد، فشرده نخواهد شد. این تنظیم را میتوان با مراجعهی به configuration editor نود اصلی سرور وب در IIS manager، ویرایش کرد:
برای نمونه در تصویر فوق، این آستانه به یک درخواست در طی 10 ساعت تنظیم شدهاست. این عدد سبب خواهد شد تا تمامی درخواستهای رسیده حتما فشرده سازی شوند.
این تنظیم معادل یک سطر ذیل در فایل web.config است. اما چون قسمت system.webServer/serverRuntime در تنظیمات سرور قفل شدهاست، هیچ تاثیری نخواهد داشت و حتما باید در سمت سرور و توسط IIS manager اعمال شود:
برای آزاد سازی این تنظیمات نیاز است دستور ذیل بر روی سرور اجرا شود. پس از آن کاربران برنامههای وب میتوانند از تنظیمات وب کانفیگ خاص خود استفاده کنند:
یک نکته
اگر از سرورهای پس از 2008 استفاده میکنید، گزینهی staticCompressionIgnoreHitFrequency نیز به تنظیمات serverRuntime اضافه شدهاست که با تنظیم آن به true، از این حد آستانه، برای فایلهای استاتیک صرفنظر خواهد شد.
تنظیمات مخصوص اندازهی فایلهایی که باید فشرده سازی شوند
تنها حد آستانهی درخواست صفحات وب نیست که بر روی فشرده سازی یا عدم آن ثاثیرگذار است. در اینجا میزان CPU Usage سیستم و یا حتی اندازهی Response خروجی نیز مهم هستند که نمونهای از تنظیمات آنرا در شکل ذیل مشاهده میکنید:
در اینجا با تنظیم minFileSizeForComp به 1024، اعلام شدهاست که حجمهایی کمتر از یک کیلوبایت، فشرده سازی نشوند (مقدار پیش فرض آن، بیش از این عدد است).
البته این عدد را به شکل زیر نیز میتوان به تنظیمات httpCompression وب کانفیگ اضافه کرد:
پس از اعمال این تنظیمات نیاز است یکبار IIS را نیز ری استارت کرد.
نتیجه گیری
اگر پس از فعال سازی GZip وب سرور، خروجی برنامه فشرده سازی نشد (Content-Encoding: gzip)، علت اینجا است که هنوز 2 درخواست مورد نیاز، در طی 10 ثانیه به سمت سرور ارسال نشدهاند و تنظیمات پیش فرض این ماژول، جهت حداقل مصرف CPU و فشار بر روی سرور است.
فعال سازی GZip توکار IIS
تنظیمات پیش فرض فعال سازی ماژول توکار GZip وب سرورهای جدید شامل دو مرحله است:
الف) تنظیمات سرور جهت فعال سازی فشرده سازی
بر روی ویندوزهای سرور، پس از مراجعه به Administrative Tools -> Server Manager و گشودن Roles آن، ذیل قسمت Web Server که در اینجا IIS است، نیاز است نقش جدیدی به نام Performance اضافه شود و مطابق تصویر، هر دو گزینهی فشرده سازی استاتیک و پویا انتخاب گردد.
بنابراین اولین قدم برای عیب یابی کار نکردن GZip توکار IIS، از این مرحله شروع میشود که آیا اصلا ماژول مربوطه نصب هست یا خیر؟
ب) تنظیمات برنامه جهت فعال سازی ماژول GZip
پس از اطمینان از نصب ماژول توکار فشرده سازی صفحات وب IIS در سمت تنظیمات سرور، اکنون باید چند سطر ذیل را به Web.Config برنامه اضافه کرد:
<system.webServer> <httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files"> <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" staticCompressionLevel="9" /> <dynamicTypes> <add mimeType="text/*" enabled="true" /> <add mimeType="message/*" enabled="true" /> <add mimeType="application/x-javascript" enabled="true" /> <add mimeType="application/javascript" enabled="true" /> <add mimeType="application/json" enabled="true" /> <add mimeType="application/json; charset=utf-8" enabled="true" /> <add mimeType="application/atom+xml" enabled="true" /> <add mimeType="application/xaml+xml" enabled="true" /> <add mimeType="*/*" enabled="false" /> </dynamicTypes> <staticTypes> <add mimeType="text/*" enabled="true" /> <add mimeType="message/*" enabled="true" /> <add mimeType="application/x-javascript" enabled="true" /> <add mimeType="application/javascript" enabled="true" /> <add mimeType="application/json" enabled="true" /> <add mimeType="application/json; charset=utf-8" enabled="true" /> <add mimeType="application/atom+xml" enabled="true" /> <add mimeType="application/xaml+xml" enabled="true" /> <add mimeType="*/*" enabled="false" /> </staticTypes> </httpCompression> <urlCompression doStaticCompression="true" doDynamicCompression="true" /> </system.webServer>
این تنظیماتی است که در اکثر سایتها نیز یافت میشود. ذکر آنها اجباری است و پس از اعمال، اگر برنامه را اجرا کنید ... چیزی فشرده نمیشود! علت اصلی را باید در تنظیماتی یافت که مخصوص سرور است و در اینجا ذکر نشدهاند.
تنظیمات مخصوص آستانهی فشرده سازی صفحات
علت اصلی عدم مشاهدهی هدر gzip، در Response برنامه، به frequent hit threshold تنظیم شدهی در IIS بر میگردد. مقدار آن به 2 درخواست در طی 10 ثانیه تنظیم شدهاست. یعنی اگر به صفحهای در طی 10 ثانیه دو درخواست نرسد، فشرده نخواهد شد. این تنظیم را میتوان با مراجعهی به configuration editor نود اصلی سرور وب در IIS manager، ویرایش کرد:
برای نمونه در تصویر فوق، این آستانه به یک درخواست در طی 10 ساعت تنظیم شدهاست. این عدد سبب خواهد شد تا تمامی درخواستهای رسیده حتما فشرده سازی شوند.
این تنظیم معادل یک سطر ذیل در فایل web.config است. اما چون قسمت system.webServer/serverRuntime در تنظیمات سرور قفل شدهاست، هیچ تاثیری نخواهد داشت و حتما باید در سمت سرور و توسط IIS manager اعمال شود:
<system.webServer> <serverRuntime frequentHitThreshold="1" frequentHitTimePeriod="10:00:00" /> </system.webServer>
C:\Windows\System32\inetsrv\appcmd.exe unlock config /section:system.webServer/serverRuntime
یک نکته
اگر از سرورهای پس از 2008 استفاده میکنید، گزینهی staticCompressionIgnoreHitFrequency نیز به تنظیمات serverRuntime اضافه شدهاست که با تنظیم آن به true، از این حد آستانه، برای فایلهای استاتیک صرفنظر خواهد شد.
تنظیمات مخصوص اندازهی فایلهایی که باید فشرده سازی شوند
تنها حد آستانهی درخواست صفحات وب نیست که بر روی فشرده سازی یا عدم آن ثاثیرگذار است. در اینجا میزان CPU Usage سیستم و یا حتی اندازهی Response خروجی نیز مهم هستند که نمونهای از تنظیمات آنرا در شکل ذیل مشاهده میکنید:
در اینجا با تنظیم minFileSizeForComp به 1024، اعلام شدهاست که حجمهایی کمتر از یک کیلوبایت، فشرده سازی نشوند (مقدار پیش فرض آن، بیش از این عدد است).
البته این عدد را به شکل زیر نیز میتوان به تنظیمات httpCompression وب کانفیگ اضافه کرد:
<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" minFileSizeForComp="1024">
پس از اعمال این تنظیمات نیاز است یکبار IIS را نیز ری استارت کرد.
نتیجه گیری
اگر پس از فعال سازی GZip وب سرور، خروجی برنامه فشرده سازی نشد (Content-Encoding: gzip)، علت اینجا است که هنوز 2 درخواست مورد نیاز، در طی 10 ثانیه به سمت سرور ارسال نشدهاند و تنظیمات پیش فرض این ماژول، جهت حداقل مصرف CPU و فشار بر روی سرور است.