اگر درخواست نصب StructureMap 4.4 با خطای Cannot find package متوقف شد، علت اینجا است که در تنظیمات ویژوال استودیو هنوز از فید قدیمی https://www.nuget.org/api/v2 استفاده می‌کنید. این فید به آدرس https://api.nuget.org/v3/index.json تغییر یافته‌است.
نظرات مطالب
Blazor 5x - قسمت 19 - کار با فرم‌ها - بخش 7 - نکات ویژه‌ی کار با EF-Core در برنامه‌های Blazor Server
- Context در EF، همان پیاده سازی الگوی واحد کار است.
- این تغییرات (برای Blazor Server فقط) انجام شده تا رفتاری مشابه Web API را پیدا کند که در پایان هر درخواست، سرویس‌های IDisposable را به صورت خودکار Dispose میکند. بنابراین با هم سازگار هستند و دقیقا از همین سرویس‌ها، در قست Blazor WASM این سری هم بدون مشکل استفاده شده‌است.
بیشتر از یک دهه از بکارگیری XMLHttpRequest برای ارسال درخواست‌های Ajax ایی می‌گذرد. موزیلا جهت رفع مشکلات آن و ارائه‌ی یک API مدرن‌تر، Fetch API را تدارک دیده‌است.
- در ASP.NET Core، یکسری key/value pair مانند HttpContext.Request.Query و HttpContext.Request.Form و ... به صورت مجزایی وجود دارند. البته روش بهتر استفاده از Model Binding است.
+ سمت سرور مطلب جاری در ASP.NET Core، با سمت سرور مطلب «بررسی روش آپلود فایل‌ها از طریق یک برنامه‌ی Angular به یک برنامه‌ی ASP.NET Core» یکی هست. آن مطلب را از قسمت «دریافت فرم درخواست پشتیبانی در سمت سرور و ذخیره‌ی فایل‌های آن» به بعد مطالعه کنید.
+ نکته‌ی تکمیلی «در نسخه‌ی اخیر افزونه jquery-ajax-unobtrusive، ارسال فایل با استفاده از FormData نیز به صورت توکار پشتیبانی میشود» را هم مدنظر داشته باشید. یعنی برای سمت کلاینت نیازی به نوشتن کدهای خاصی برای ارسال فایل به سمت سرور نیست (نیازی نیست کد جی‌کوئری بنویسید). همینکه به صورت معمولی از افزونه‌ی jquery-ajax-unobtrusive استفاده کنید، تمام نکات آن مانند قبل است.
بازخوردهای دوره
تزریق خودکار وابستگی‌ها در ASP.NET Web API به همراه رها سازی خودکار منابع IDisposable
هر کدام را باید جداگانه تعریف کنید. برای Web API از روش جاری، برای MVC از روش مطرح شده در مطلب آن. درخواستی که به Web API ارسال میشود در یک context جداگانه نسبت به ASP.NET MVC پردازش میشود و با آن یکی نیست. حتی فضاهای نام آن‌ها هم یکی نیست. ASP.NET Web API جزئی از ASP.NET MVC نیست و در وب فرم‌ها هم مستقلا کاربرد دارد.
neo4j یک بانک اطلاعاتی گراف پایه است که جزو بانک‌های اطلاعاتی no-sql طبقه بندی میشود. سرعت بسیار بالا و امکان اجرای کوئری‌های پیچیده، از برجسته‌ترین ویژگی‌های این بانک اطلاعاتی است.
در زیر برخی دستورات ابتدایی آن آورده شده است.
مثال واقعی:
در مثال بالا یک آبجکت با نوع یوزر را ایجاد کردیم. با اینکار در واقع تایپ یوزر را هم به neo4j معرفی کردیم. البته هر اسمی را می‌توانیم جای یوزر بگذاریم.
بازیابی یک آبجکت
برای بازیابی یک آبجکت، از فرم ساده زیر استفاده میشود:
می‌توانیم برای بازیابی شرط هم تعیین کنیم:
ایجاد رابطه بین دو شیء
برای ایجاد رابطه بین دو شیء، از فرم زیر استفاده میکنیم:
اسم LIKE را ما بر روی این رابطه گذاشتیم و البته هر اسم دیگری را نیز می‌توانستیم بگذاریم و الزامی هم برای نوشتن با حروف بزرگ نبود. فقط برای راحت‌تر تفکیک کردن از سایر نوع آبجکت‌ها، این اسم را با حرف بزرگ نوشتیم .
برای بازیابی همه مواردی که لایک شده‌اند:
برای بازیابی همه مواردی که یک یوزر خاص لایک کرده‌است:
برای بازیابی دو طرفی که در رابطه LIKE شرکت داشته‌اند، از فرم زیر استفاده میکنیم:
میتوانید قسمت شرط را هم اضافه کنید و برای مثال همه کاربرانی را که از یک تاریخ خاص ایجاد شده‌اند و چیزی را لایک کرده‌اند، بدست بیاورید:
بهترین کاربرد neo4j استفاده به عنوان مکمل برای بانک اطلاعاتی‌های دیگر مثل مونگو و کاساندرا است؛ به این صورت که دیتای اصلی در دیتابیس مونگو یا کاساندرا ذخیره گردد و ایندکس این دیتا‌ها به همراه چند پارامتر کلیدی که در کوئری‌ها استفاده زیادی دارد در neo4j ذخیره گردد. اکثر کوئری‌ها بر روی neo4j اجرا شوند و با استفاده از کلیدهای یافته شده، دیتای اصلی از بانک اطلاعاتی اصلی دریافت شود. این روش در پروژه‌های بسیار بزرگ (مثل شبکه‌های اجتماعی) کاربرد فراوانی دارد. همین شیوه برای استفاده از ElasticSearch نیز بسیار مرسوم است.
برای کار با neo4j آدرس http://127.0.0.1:7474 را درمرورگر وارد کنید و سپس وارد ویرایشگر کوئری شوید. برای بار اول، neo4j از شما نام کاربری و رمز عبوری را درخواست میکند. این نام و رمز عبور، هنگام نصب تعیین میشود. معمولآ نام کاربری آن neo4j است.
در زیر برخی دستورات ابتدایی آن آورده شده است.
ایجاد یک آبجکت و یا ویرایش آن
برای ساخت یک آبجکت و یا ویرایش آن، باید از فرم کوئری زیر استفاده کنیم. این مرحله معادل ساخت جدول در بانک‌های اطلاعاتی رابطه‌ای است.
CREATE (VariableName:objectType { guid: {keyInMainDB }, property1 :value1 ,property2 : value2 ,... )
فرم زیر، هم برای ایجاد کاربرد دارد و هم برای ویرایش. چون این فرم هر دو حالت را باهم پوشش می‌دهد، بیشتر استفاده میشود. هر چند در مواقعی که می‌خواهیم تعداد زیادی دیتا وارد بانک کنیم، حالت قبل سرعت بالاتری دارد.
MERGE (VariableName:objectType { guid: keyInMainDB }) SET VariableName +={property1: value1,property2: value2,...}
MERGE (object:User { guid: 1353554 }) SET object +={username:"nasser" ,time_created: 1522480294 } مقادیر عددی مستقیم، و موارد رشته‌ای با کوتیشن به خواص نسبت داده شدند. اسم خواص را هم ما انتخاب کردیم. علاوه بر عدد و رشته، neo4j از آرایه هم به عنوان نوع داده ورودی پشتیبانی میکند.
بازیابی یک آبجکت
برای بازیابی یک آبجکت، از فرم ساده زیر استفاده میشود:
match (VariableName:objectType ) return VariableName
برای بازیابی آبجکتی که در بالا درج شد، از مثال واقعی زیر استفاده میکنیم:
match (object:User { guid: 1353554 }) return object match (object:User ) where object.time_created>1522480293 return object
ایجاد رابطه بین دو شیء
برای ایجاد رابطه بین دو شیء، از فرم زیر استفاده میکنیم:
MATCH (v1:objectType1 {guid: guid1}),
(v2:objectType2 {guid: guid2})
MERGE (v1)-[:RelationshipName]->(v2) برای مثال واقعی میتوانید حالتی را در نظر بگیرید که یک کاربر، کاربر دیگری را در شبکه اجتماعی دنبال میکند. در اینجا رابطه دنبال کردن بین دو کاربر ایجاد میشود. یا حالتی که یک فرد، یک متن یا تصویر را لایک میکند، در اینجا بین آبجکت کاربر و آن آبجکت متن یا تصویر، رابطه لایک کردن ایجاد میشود.
مثال واقعی برای لایک کردن:
MATCH (usr:User {guid: 1353554 }),(img:Image {guid: 88554 })
MERGE (usr)-[:LIKE]->(img) برای بازیابی کاربرهایی که مواردی را لایک کرده‌اند از فرم زیر استفاده میکنیم:
MATCH (usr:User)-[r:LIKE]-() Return usr
MATCH ()-[r:LIKE]-(n) Return n
MATCH (usr:User{guid:1353554 })-[r:LIKE]-(n) Return n MATCH p=()-[r:LIKE]->() RETURN p
MATCH (usr:User )-[r:LIKE]-(n) where usr.time_created>1522480293 Return usr
اگر با Elasticsearch کار کرده باشید میدانید که تولید Elasticsearch DSL Query کمی پیچیده است و عموما باید به صورت manual این Query هارو تولید کنید.
با استفاده از این پکیج برای تولید این Queryها میتوانید از syntax پشتیبانی شده در Gridify استفاده کنید که کار ساخت Query برای Elasticsearch را ساده میکند.
مثال:
await client.SearchAsync<User>(s => s
.Index("users")
.ApplyFiltering("emailAddress = John")); query زیر را تولید میکند:
GET users/_search
{
"query": {
"term": {
"emailAddress.keyword": {
"value": "test@test.com"
}
}
}
}
با قدرت گرفتن جاوا اسکریپت، نیازهایی مانند کوئری گرفتن در سمت کلاینت، کش کردن داده‌ها در سمت کلاینت، ردیابی تغییرات، اعتبارسنجی مدلها، ذخیره کردن گروهی از عملیات‌ها (Save Batch)، تعامل با Web Api .Net یا Node Js، قابلیت کار کردن با No Sql و... افزایش یافته است و تمام این کارها توسط breeze امکان پذیر میباشد. breeze با هر سرویس دهنده‌ای که بتواند از طریق http و با فرمت json عملیات خود را انجام دهد، میتواند ارتباط برقرار کند.
breeze مطابق با استاندارد ECMAScript 5 نوشته شده‌است؛ از این‌رو بر روی اکثر مرورگرهای جدید به خوبی اجرا میشود.
برای مرورگرهای قدیمی می‌توان کتابخانه es5-shim.js and es5-sham.js را قبل از تگ اسکریپت breeze js قرار داد.
در این قسمت به برخی از توانایی های breeze اشاره کوتاهی میکنیم و در مقالات بعدی پیاده سازی آن‌را در قالب angular js /Web Api .net خواهیم داشت:
1- کوئری‌های breeze اکثر امکانات linq را دارا میباشد؛ مانند شرطهای ساده، شرطهای پیچیده، Sorting ،Paging،Projections و Filter کردن برخی از پراپرتی‌ها که بسیار مشابه linq میباشد:
var query = breeze.EntityQuery
.from("Customers")
.where("CompanyName", "startsWith", "A")
.orderBy("CompanyName"); var promise = manager.executeQuery(query)
.then(querySucceeded)
.fail(queryFailed); if (manager.hasChanges()) {
manager.saveChanges().then(saveSucceeded).fail(saveFailed);
}
// listen for any change to a customer
customer.entityAspect.propertyChanged.subscribe(somethingHappened); <!-- Angular template -->
<li data-ng-repeat="emp in employees">
<label>{{emp.FirstName}}</label>
<label>{{emp.LastName}}</label>
</li>
// bound to employees from query
manager.executeQuery(breeze.EntityQuery.from("Employees"))
.then(function(data) { $scope.employees = data.results; }); /* Query with related entities using expand */
// query for orders of customers whose name begins "Alfreds"
// include their customers & child details & their detail products
breeze.EntityQuery.from("Orders")
.where("Customer.CompanyName", "startsWith", "Alfreds")
.expand("Customer, OrderDetails.Product")
.using(manager)
.execute().then(querySucceeded).fail(queryFailed); // execute query asynchronously on the server manager.executeQuery(query).then(querySuccess).fail(queryFail); // execute query synchronously on local cache var customers = manager.executeQueryLocally(query)
نحوه‌ی نصب و راه اندازی برنامه‌های ASP.NET Core را در IIS، پیشتر در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 22 - توزیع برنامه توسط IIS» بررسی کردیم. در این مطلب می‌خواهیم به تعدادی از خطاهای ممکن در حین راه اندازی اولیه‌ی این نوع برنامه‌ها بپردازیم.
خطای 500.19
این خطا زمانی رخ می‌دهد که ماژول هاستینگ ASP.NET Core، توسط IIS شناسایی نشده باشد. نصب مجدد آن این مشکل را برطرف میکند.
لیست تمام ماژول‌های هاستینگ را همواره در اینجا میتوانید پیدا کنید.
خطای 502.5 و یا گاهی از اوقات 502
باید دقت داشته باشید که اگر تنظیم disableStartUpErrorPage در IIS فعال باشد (قابل افزودن به تگ aspNetCore تنظیمات وب کانفیگ ذیل)، صرفا خطای 502 را دریافت می‌کنید.
این خطا به معنای شکست در اجرای ماژول هاستینگ ASP.NET Core است و ممکن است به یکی از دلایل ذیل ایجاد شده باشد:
الف) در حین اجرای برنامه‌ی شما، استثنایی در کدهای فایل آغازین startup.cs برنامه، رخ داده‌است.
ب) پورت مورد استفاده‌ی برنامه، توسط پروسه‌ی دیگری در حال استفاده است.
ج) برنامه‌ی شما برای SDK با نگارش 1.1.2 تنظیم و کامپایل شده‌است؛ اما بر روی سرور حداکثر، SDK نگارش 1.1.1 نصب شده‌است.
د) ممکن است پروسه‌ی IIS قادر به یافتن و حتی اجرای dotnet.exe نباشد.
برای لاگ کردن مورد «الف»، باید لاگ کردن خطاهای برنامه را در web.config آن فعالسازی کنید:
چند نکته:
- اگر این مورد به مسیر logs\stdout\. تنظیم شده‌است، باید پوشه‌ی logs را در ریشه‌ی پروژه به صورت دستی ایجاد کنید؛ و گرنه IIS آن‌را به صورت خودکار ایجاد نخواهد کرد.
- کاربر App Pool برنامه (با نام پیش‌فرض « IIS AppPool\DefaultAppPool») باید دسترسی نوشتن در این پوشه را داشته باشد؛ وگرنه فایل لاگی در آن ایجاد نخواهد شد.
- همچنین اگر با رعایت تمام این موارد، محتوای این فایل تولید شده باز هم خالی بود، یکبار IIS را ری‌استارت کنید. ممکن است IIS کار نوشتن در فایل لاگ را تمام نکرده باشد و با این کار مجبور به تکمیل و بستن فایل میشود.
- برای حالت «ب» قبل از هر تغییری، یکبار کل سرور را ری‌استارت کنید.
- برای مورد «ج» نیز باید آخرین SDK هاستینگ را بر روی سرور نصب کنید.
لیست تمام SDKهای نصب شده‌ی بر روی سیستم را در مسیر «C:\Program Files\dotnet\sdk» میتوانید مشاهده کنید. همچنین دستور «dotnet --list-sdks» نیز لیست SDKهای نصب شده را نمایش می‌دهد.
- برای رفع حالت «د»، نیاز است این موارد را بررسی کنید:
1- «Load User Profile» را به true تنظیم کنید.
برای اینکار به قسمت Application pools مراجعه کرده و تنظیمات پیشرفته‌ی App pool مورد استفاده را ویرایش کنید (تصویر فوق).
این تنظیم برای دائمی کردن کلیدهای رمزنگاری برنامه‌های ASP.NET Core نیز ضروری است و باید جزو چک لیست نصب برنامه‌های ASP.NET Core قرار گیرد.
2- مورد «د» حتی میتواند به علت عدم تعریف مسیر «C:\Program Files\dotnet\» در path ویندوز باشد. برای این منظور دستور env:path$ را در power shell اجرا کنید و بررسی کنید که آیا این مسیر در خروجی آن موجود است یا خیر؟ اگر نبود، پس از اضافه کردن آن به path ویندوز، باید یکبار IIS را هم ریست کنید تا این تنظیمات جدید را بخواند.
3- مورد «د» ممکن است به علت اشتباه تنظیم پوشه‌ی اصلی برنامه در IIS نیز باشد. یعنی dotnet.exe قادر به یافتن اسمبلی‌های برنامه نیست.
4- برای رفع مورد «د» دو دسترسی دیگر را نیز باید بررسی کنید:
الف) آیا کاربر Application pool برنامه به پوشه‌ی برنامه دسترسی read & execute را دارد یا خیر؟
ب) آیا کاربر Application pool برنامه به پوشه‌ی C:\Program Files\dotnet دسترسی read & execute را دارد یا خیر؟
اگر خیر، نحوه‌ی دسترسی دادن به آن‌ها به صورت زیر است:
خطای 502.3 و یا گاهی از اوقات 500
این خطا به صورت خلاصه به معنای «Bad Gateway: Forwarder Connection Error» است و زمانی رخ می‌دهد که پروسه‌ی dotnet.exe به درخواست رسیده شده یا پاسخی نداده‌است (مشاهده خطای 0x80072EE2 یا ERROR_WINHTTP_TIMEOUT) و یا بیش از اندازه این پاسخ دهی طول کشیده‌است (این تنظیمات را در configuration editor میتوانید مشاهده کنید که در حقیقت همان تگ aspNetCore در تنظیمات وب کانفیگ فوق است).
برای دیباگ بهتر این مورد نیاز است علاوه بر تنظیم web.config فوق، به فایل appsettings.json مراجعه کرده و سطح پیش فرض لاگ کردن اطلاعات را که warning است به information تغییر دهید:
در این حالت درخواستی که پردازش نشده‌است نیز در لاگ‌ها حضور خواهد داشت و ممکن است این درخواست به علت عدم تنظیم CORS بدون پاسخ باقی مانده باشد.
و یا اگر پردازشی دارید که بیش از 2 دقیقه طول می‌کشد (مطابق تنظیمات تصویر فوق)، میتوانید مقدار request time out را بیشتر کنید.
خطای 0x80004005 : 80008083
خطای 0x80008083 به معنای تداخل نگارش‌ها است و خطای 0x80004005 به معنای مفقود بودن یک فایل یا عدم دسترسی به آن است.
این خطا زمانی رخ می‌دهد که برنامه‌ی خود را ارتقاء داده باشید، اما ماژول هاستینگ ASP.NET Core را بر روی سرور به روز رسانی نکرده باشید.
خطای 500.19
اگر برنامه‌ی شما از امکانات URL Rewrite خود IIS استفاده میکند، عدم نصب بودن آن بر روی سرور، این خطا را سبب خواهد شد.
برای اینکار ابتدا IIS را متوقف کنید. سپس SDK جدید را نصب و پس از آن IIS را مجددا راه اندازی نمائید.
خطای 503
برنامه اجرا نشده و سطر ذیل در Event Viewer ویندوز قابل مشاهده است:
اگر اخیرا سیستم عامل را ارتقاء داده‌اید، ممکن است این خطا را دریافت کنید. راه حل آن نصب مجدد ماژول هاستینگ ASP.NET Core است تا نصب قبلی تعمیر شود.
خطای 500.19
این خطا زمانی رخ می‌دهد که ماژول هاستینگ ASP.NET Core، توسط IIS شناسایی نشده باشد. نصب مجدد آن این مشکل را برطرف میکند.
لیست تمام ماژول‌های هاستینگ را همواره در اینجا میتوانید پیدا کنید.
خطای 502.5 و یا گاهی از اوقات 502
باید دقت داشته باشید که اگر تنظیم disableStartUpErrorPage در IIS فعال باشد (قابل افزودن به تگ aspNetCore تنظیمات وب کانفیگ ذیل)، صرفا خطای 502 را دریافت می‌کنید.
این خطا به معنای شکست در اجرای ماژول هاستینگ ASP.NET Core است و ممکن است به یکی از دلایل ذیل ایجاد شده باشد:
الف) در حین اجرای برنامه‌ی شما، استثنایی در کدهای فایل آغازین startup.cs برنامه، رخ داده‌است.
ب) پورت مورد استفاده‌ی برنامه، توسط پروسه‌ی دیگری در حال استفاده است.
ج) برنامه‌ی شما برای SDK با نگارش 1.1.2 تنظیم و کامپایل شده‌است؛ اما بر روی سرور حداکثر، SDK نگارش 1.1.1 نصب شده‌است.
د) ممکن است پروسه‌ی IIS قادر به یافتن و حتی اجرای dotnet.exe نباشد.
برای لاگ کردن مورد «الف»، باید لاگ کردن خطاهای برنامه را در web.config آن فعالسازی کنید:
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*"
modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" />
</system.webServer> - اگر این مورد به مسیر logs\stdout\. تنظیم شده‌است، باید پوشه‌ی logs را در ریشه‌ی پروژه به صورت دستی ایجاد کنید؛ و گرنه IIS آن‌را به صورت خودکار ایجاد نخواهد کرد.
- کاربر App Pool برنامه (با نام پیش‌فرض « IIS AppPool\DefaultAppPool») باید دسترسی نوشتن در این پوشه را داشته باشد؛ وگرنه فایل لاگی در آن ایجاد نخواهد شد.
- همچنین اگر با رعایت تمام این موارد، محتوای این فایل تولید شده باز هم خالی بود، یکبار IIS را ری‌استارت کنید. ممکن است IIS کار نوشتن در فایل لاگ را تمام نکرده باشد و با این کار مجبور به تکمیل و بستن فایل میشود.
- برای حالت «ب» قبل از هر تغییری، یکبار کل سرور را ری‌استارت کنید.
- برای مورد «ج» نیز باید آخرین SDK هاستینگ را بر روی سرور نصب کنید.
لیست تمام SDKهای نصب شده‌ی بر روی سیستم را در مسیر «C:\Program Files\dotnet\sdk» میتوانید مشاهده کنید. همچنین دستور «dotnet --list-sdks» نیز لیست SDKهای نصب شده را نمایش می‌دهد.
- برای رفع حالت «د»، نیاز است این موارد را بررسی کنید:
1- «Load User Profile» را به true تنظیم کنید.
برای اینکار به قسمت Application pools مراجعه کرده و تنظیمات پیشرفته‌ی App pool مورد استفاده را ویرایش کنید (تصویر فوق).
این تنظیم برای دائمی کردن کلیدهای رمزنگاری برنامه‌های ASP.NET Core نیز ضروری است و باید جزو چک لیست نصب برنامه‌های ASP.NET Core قرار گیرد.
2- مورد «د» حتی میتواند به علت عدم تعریف مسیر «C:\Program Files\dotnet\» در path ویندوز باشد. برای این منظور دستور env:path$ را در power shell اجرا کنید و بررسی کنید که آیا این مسیر در خروجی آن موجود است یا خیر؟ اگر نبود، پس از اضافه کردن آن به path ویندوز، باید یکبار IIS را هم ریست کنید تا این تنظیمات جدید را بخواند.
3- مورد «د» ممکن است به علت اشتباه تنظیم پوشه‌ی اصلی برنامه در IIS نیز باشد. یعنی dotnet.exe قادر به یافتن اسمبلی‌های برنامه نیست.
4- برای رفع مورد «د» دو دسترسی دیگر را نیز باید بررسی کنید:
الف) آیا کاربر Application pool برنامه به پوشه‌ی برنامه دسترسی read & execute را دارد یا خیر؟
ب) آیا کاربر Application pool برنامه به پوشه‌ی C:\Program Files\dotnet دسترسی read & execute را دارد یا خیر؟
اگر خیر، نحوه‌ی دسترسی دادن به آن‌ها به صورت زیر است:
Right click on the folder -> Properties -> Security tab -> Click at Edit button -> Enter `IIS AppPool\DefaultAppPool` user (IIS AppPool\<app_pool_name>) -> Click at Check names -> OK -> Then give it `read & execute` or other permissions.
خطای 502.3 و یا گاهی از اوقات 500
این خطا به صورت خلاصه به معنای «Bad Gateway: Forwarder Connection Error» است و زمانی رخ می‌دهد که پروسه‌ی dotnet.exe به درخواست رسیده شده یا پاسخی نداده‌است (مشاهده خطای 0x80072EE2 یا ERROR_WINHTTP_TIMEOUT) و یا بیش از اندازه این پاسخ دهی طول کشیده‌است (این تنظیمات را در configuration editor میتوانید مشاهده کنید که در حقیقت همان تگ aspNetCore در تنظیمات وب کانفیگ فوق است).
برای دیباگ بهتر این مورد نیاز است علاوه بر تنظیم web.config فوق، به فایل appsettings.json مراجعه کرده و سطح پیش فرض لاگ کردن اطلاعات را که warning است به information تغییر دهید:
"Console": {
"LogLevel": {
"Default": "Information"
}
} و یا اگر پردازشی دارید که بیش از 2 دقیقه طول می‌کشد (مطابق تنظیمات تصویر فوق)، میتوانید مقدار request time out را بیشتر کنید.
خطای 0x80004005 : 80008083
Application ‘<IIS path>’ with physical root ‘<Application path>’ failed to start process with commandline ‘”dotnet” .\MyApp.dll’, ErrorCode = ‘0x80004005 : 80008083.
این خطا زمانی رخ می‌دهد که برنامه‌ی خود را ارتقاء داده باشید، اما ماژول هاستینگ ASP.NET Core را بر روی سرور به روز رسانی نکرده باشید.
خطای 500.19
HTTP Error 500.19 - Internal Server Error The requested page cannot be accessed because the related configuration data for the page is invalid.
برای اینکار ابتدا IIS را متوقف کنید. سپس SDK جدید را نصب و پس از آن IIS را مجددا راه اندازی نمائید.
خطای 503
برنامه اجرا نشده و سطر ذیل در Event Viewer ویندوز قابل مشاهده است:
The Module DLL C:\WINDOWS\system32\inetsrv\aspnetcore.dll failed to load. The data is the error.
خلاصه موارد ممکن:
- در یک صفحه چندبار از Html.AntiForgeryToken استفاده شده‌است. این مورد کوکی آنتی‌فورجری را تخریب میکند و نهایتا اطلاعات آن قابل رمزگشایی و مقایسه در سمت سرور نخواهد بود.
- تنظیم AntiForgeryConfig.SuppressIdentityHeuristicChecks = true را به فایل global.asax.cs نیز اضافه کنید. آنتی‌فورجری توکن وضعیت کاربر لاگین شده به سیستم را نیز نگهداری و رمزنگاری میکند. در این حالت اگر در یک برگه‌ی دیگر لاگ آف کنید و در برگه‌ی قبلی سعی در ارسال فرم، آنتی‌فورجری توکن یک پیام خطا را نمایش می‌دهد. با تنظیم SuppressIdentityHeuristicChecks = true این بررسی وضعیت لاگین شخص حذف خواهد شد.
- حالت تنظیم machine key یاد شده، در یک web farm با چندین سرور ممکن است رخ دهد. اگر چنین حالتی را ندارید، تنظیمی را تغییر ندهید.
- در یک صفحه چندبار از Html.AntiForgeryToken استفاده شده‌است. این مورد کوکی آنتی‌فورجری را تخریب میکند و نهایتا اطلاعات آن قابل رمزگشایی و مقایسه در سمت سرور نخواهد بود.
- تنظیم AntiForgeryConfig.SuppressIdentityHeuristicChecks = true را به فایل global.asax.cs نیز اضافه کنید. آنتی‌فورجری توکن وضعیت کاربر لاگین شده به سیستم را نیز نگهداری و رمزنگاری میکند. در این حالت اگر در یک برگه‌ی دیگر لاگ آف کنید و در برگه‌ی قبلی سعی در ارسال فرم، آنتی‌فورجری توکن یک پیام خطا را نمایش می‌دهد. با تنظیم SuppressIdentityHeuristicChecks = true این بررسی وضعیت لاگین شخص حذف خواهد شد.
- حالت تنظیم machine key یاد شده، در یک web farm با چندین سرور ممکن است رخ دهد. اگر چنین حالتی را ندارید، تنظیمی را تغییر ندهید.