بجای:
@Html.ActionLink("Log in", "Login", "Account", routeValues: null, htmlAttributes: new { id = "loginLink" }) <a id="loginLink" controller="Account" action="Login">Log in</a>
Roslyn نسبت به کامپایلر قدیمی native، تفاوت‌هایی را در نحوه‌ی کامپایل کدها نیز به همراه دارد. یک سری از مسایل که در کامپایلر native ندید گرفته می‌شدند، برای مثال مقایسه value types با null در اینجا به صورت یک اخطار نمایش داده خواهند شد و همچنین پردازش و کامپایل و خطایابی مقادیر پیش فرض پارامترها در آن بهبود یافته و ...
- مباحث اعتبارسنجی سمت کلاینت در اینجا بحث شدند.
+ بجای مقدار رشته‌ای "Null" (که یک مقدار واقعی و غیرنال هست)، از "" استفاده کنید (مقدار خالی). اگر مقدار انتخاب شده‌ی یک drop down خالی باشد، نال ترجمه می‌شود. بعد هم از NotEmpty برای بررسی آن استفاده کنید:
RuleFor(x => x.StringField).NotNull().NotEmpty().WithMessage("..."); - این پروژه به Angular Material 9x ارتقاء داده شده؛ جزئیات بیشتر
- کتابخانه‌ی jalali-moment متاسفانه باگ زیاد دارد. اگرتنظیم jalaliMoment.locale("fa") در آن وجود نداشته باشد، مدام خطای null reference می‌دهد. همچنین روش معرفی تاریخ میلادی به آن اینبار باید به اینصورت باشد (عدم سازگاری با نگارش‌های قبلی آن).
سلام؛ حتی پس از پیاده سازی DataProtectionKey تو Efcore با توجه به اینکه پس از اجرای برنامه رکورد مورد نظر تو جدول مربوطه تولید میشه ولی کماکان پس از رفرش صفحه متاسفانه از claim مقدار null رو دریافت میکنم. نمیدونم باز هم مشکل از رمزگشایی هست یا مورد دیگه ای هم وجود داره؟
یک نکته‌ی تکمیلی: تاثیر نوع‌های ارجاعی نال نپذیر C# 8.0 بر روی EF Core 3.0
تغییرات نحوه‌ی تعریف موجودیت‌ها در C# 8.0
تا پیش از C# 8.0، برای تعریف فیلدهای نال نپذیر و نال پذیر در موجودیت‌های EF Core، به صورت زیر عمل می‌شد:
اگر رشته‌ای مزین به ویژگی Required باشد، یعنی به یک فیلد نال‌نپذیر، ترجمه و نگاشت خواهد شد و برعکس. اما پس از فعالسازی ویژگی نوع‌های ارجاعی نال نپذیر C# 8.0 در پروژه‌ی خود، کامپایلر اخطارهایی مانند «Non-nullable property 'FirstName' is uninitialized. Consider declaring the property as nullable» را به ازای تک تک خواص تعریف شده‌ی در کلاس موجودیت فوق، صادر می‌کند. برای رفع این مشکل می‌توان از bang operator که کمی بالاتر در مورد آن توضیح داده شده، استفاده کرد:
در اینجا نحوه‌ی تعریف دو فیلد نال‌نپذیر و نال پذیر را در موجودیت‌های EF Core 3.0 و C# 8.0 مشاهده می‌کنید. خاصیت اول دیگر نیازی به ویژگی Required ندارد؛ اما چون دیگر نال را نمی‌پذیرد، می‌توان مقدار دهی اولیه‌ی آن‌را توسط !null انجام داد؛ تا کامپایلر دیگر خطایی را در مورد عدم مقدار دهی اولیه‌ی آن صادر نکند (تنها کاربرد !null است). البته بهتر است !null را صرفا با EF Core و موجودیت‌های آن استفاده کنید و برای سایر کلاس‌ها، از دیگر روش‌های مطرح شده‌ی در این مطلب مانند تعریف یک سازنده، کمک بگیرید.
مزیت این روش نسبت به Person_BeforeCS8 این است که اینبار علاوه بر نال‌نپذیر تعریف شدن فیلد FirstName، نحوه‌ی استفاده‌ی از آن در برنامه (عدم انتساب نال به آن) نیز تحت کنترل کامپایلر قرار می‌گیرد که پیشتر با ویژگی Required چنین امری میسر نبود.
بنابراین در موجودیت‌های برنامه‌ی مبتنی بر C# 8.0، دیگر نیاز به استفاده‌ی از ویژگی Required نبوده و نال‌پذیری با عملگر ? مشخص می‌شود.
کار با وابستگی‌ها و ارتباط‌های نال‌پذیر
فرض کنید یک چنین کوئری را در EF Core 3.0 و C# 8.0 نوشته‌اید:
در اینجا ParentPost می‌تواند نال باشد، اما در عمل EF Core به این موضوع اهمیتی نمی‌دهد و از آن صرفا جهت تهیه‌ی SQL نهایی استفاده می‌کند؛ اما کامپایلر C# 8.0، اخطار «Dereference of a possible null reference» را صادر می‌کند. برای رفع آن نیز می‌توان از bang operator استفاده کرد:
وجود عملگر ! در اینجا، به معنای اعلام صریح نال نبودن ParentPost، در شرایط کوئری فوق، به کامپایلر است.
تغییرات نحوه‌ی تعریف موجودیت‌ها در C# 8.0
تا پیش از C# 8.0، برای تعریف فیلدهای نال نپذیر و نال پذیر در موجودیت‌های EF Core، به صورت زیر عمل می‌شد:
public class Person_BeforeCS8
{
[Required]
public string FirstName { get; set; } // NOT NULL
public string MiddleName { get; set; } // NULL
} public class Person_AfterCS8
{
public string FirstName { get; set; } = null!; // NOT NULL
public string? MiddleName { get; set; } // NULL
} مزیت این روش نسبت به Person_BeforeCS8 این است که اینبار علاوه بر نال‌نپذیر تعریف شدن فیلد FirstName، نحوه‌ی استفاده‌ی از آن در برنامه (عدم انتساب نال به آن) نیز تحت کنترل کامپایلر قرار می‌گیرد که پیشتر با ویژگی Required چنین امری میسر نبود.
بنابراین در موجودیت‌های برنامه‌ی مبتنی بر C# 8.0، دیگر نیاز به استفاده‌ی از ویژگی Required نبوده و نال‌پذیری با عملگر ? مشخص می‌شود.
کار با وابستگی‌ها و ارتباط‌های نال‌پذیر
فرض کنید یک چنین کوئری را در EF Core 3.0 و C# 8.0 نوشته‌اید:
var parentPosts = db.Posts.Where(p => p.ParentPost.Id == postId).ToList();
var parentPosts = db.Posts.Where(p => p.ParentPost!.Id == postId).ToList();
public async Task<IActionResult> FileUpload(IFormFile file)
{
if (file == null || file.Length == 0)
{
return BadRequest();
}
using (var memoryStream = new MemoryStream())
{
await file.CopyToAsync(memoryStream);
var fileBytes = memoryStream.ToArray();
// ... save it
}
} 
سلام
در متد getPredicate به شرط if (type == typeof(Guid) به if (type == typeof(Guid) || type == typeof(Guid?)) تغییر داده شد مشکل برطرف شد .
آیا امکان بررسی این شرط که فیلدی برابر با Null باشد هم در این کتابخانه وجود داره ؟
در متد getPredicate به شرط if (type == typeof(Guid) به if (type == typeof(Guid) || type == typeof(Guid?)) تغییر داده شد مشکل برطرف شد .
آیا امکان بررسی این شرط که فیلدی برابر با Null باشد هم در این کتابخانه وجود داره ؟
جهت رفع باگ کد زیر را
بعد از خط
اضافه کنید.
var keys = from key in queries.AllKeys where key.StartsWith(requestBodyField.Field+"[") select key;
if(!keys.Any())
continue; بعد از خط
if (valueAsString == null)
{ اضافه کنید.
در کلاس ScheduledTasksCoordinator یک متد Remove از لیست اضافه کن:
public void RemoveTask(string taskName)
{
lock (_syncLock)
{
var task = _tasks.FirstOrDefault( x => x.Name == taskName);
if (task != null)
{
_tasks.Remove(task);
}
}
}