‫۵ سال و ۷ ماه قبل، چهارشنبه ۲۴ بهمن ۱۳۹۷، ساعت ۱۷:۵۶
یک نکته‌ی تکمیلی: کدامیک از متدهای کار با رشته‌ها در سمت کلاینت پردازش می‌شوند و کدام‌ها در سمت سرور؟
در مثال‌های زیر، هر جائیکه قسمت where عبارت SQL حذف شده‌، یعنی Client-Side Evaluation رخ داده‌است:
- با اضافه شدن نوع مقایسه، محاسبه‌ی سمت کلاینت رخ می‌دهد:
var test1 = context.Blogs
.Where(blog => String.Compare(blog.Url, "A", StringComparison.Ordinal) > 0)
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
- بدون مشخص سازی نوع مقایسه، محاسبه‌ی سمت سرور را خواهیم داشت:
var test2 = context.Blogs
.Where(blog => String.Compare(blog.Url, "B") > 0)
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
// WHERE [blog].[Url] > N'B'
- در مورد متد Equals هم دقیقا به همین صورت است. با اضافه شدن نوع مقایسه، محاسبه‌ی سمت کلاینت رخ می‌دهد: 
var test3 = context.Blogs
.Where(blog => blog.Url.Equals("C", StringComparison.OrdinalIgnoreCase))
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
- بدون مشخص سازی نوع مقایسه، محاسبه‌ی سمت سرور را خواهیم داشت: 
var test3_1 = context.Blogs
.Where(blog => blog.Url.Equals("C_1"))
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
// WHERE [blog].[Url] = N'C_1'
- StartsWith و EndsWith در سمت سرور محاسبه می‌شوند:
var test4 = context.Blogs
.Where(blog => blog.Url.StartsWith("D"))
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
// WHERE [blog].[Url] LIKE N'D' + N'%' AND (LEFT([blog].[Url], LEN(N'D')) = N'D')
- اما اگر از عبارات SQL آن‌ها راضی نیستید، از متد EF.Functions.Like استفاده کنید:
var test5 = context.Blogs
.Where(blog => EF.Functions.Like(blog.Url, "S_i%"))
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
// WHERE [blog].[Url] LIKE N'S_i%'
- متدهای ToUpper و ToLower سمت سرور محاسبه می‌شوند (هرچند اگر از SQL Server استفاده می‌کنید، Collation پیش‌فرض آن غیرحساس به حروف کوچک و بزرگ است و در اکثر مواقع نیازی به یک چنین متدهایی نیست):
var test6 = context.Blogs
.Where(blog => blog.Url.ToUpper() == "E")
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
// WHERE UPPER([blog].[Url]) = N'E'
- اما حالت‌های Invariant دار آن‌ها خیر و در سمت کلاینت محاسبه می‌شوند:
var test7 = context.Blogs
.Where(blog => blog.Url.ToUpperInvariant() == "F")
.ToList();
// SELECT [blog].[BlogId], [blog].[Url]
// FROM [Blogs] AS [blog]
‫۵ سال و ۷ ماه قبل، چهارشنبه ۲۴ بهمن ۱۳۹۷، ساعت ۱۷:۲۱
روش ارتقاء به EF Core 2.2
    public class BloggingContext : DbContext
    {
        public BloggingContext()
        { }

        public BloggingContext(DbContextOptions options)
            : base(options)
        { }

        public DbSet<Blog> Blogs { get; set; }
        public DbSet<Post> Posts { get; set; }

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            if (!optionsBuilder.IsConfigured)
            {
                optionsBuilder.EnableSensitiveDataLogging();
                optionsBuilder.UseSqlServer(@"...");
                optionsBuilder.ConfigureWarnings(warnings =>
                {
                    warnings.Log(CoreEventId.IncludeIgnoredWarning);
                    warnings.Log(RelationalEventId.QueryClientEvaluationWarning);
                });
                optionsBuilder.UseLoggerFactory(GetLoggerFactory());
            }
        }

        private ILoggerFactory GetLoggerFactory()
        {
            IServiceCollection serviceCollection = new ServiceCollection();
            serviceCollection.AddLogging(builder =>
                   builder.AddConsole()
                          //.AddFilter(category: DbLoggerCategory.Database.Command.Name, level: LogLevel.Information));
                          .AddFilter(level => true)); // log everything
            return serviceCollection.BuildServiceProvider().GetRequiredService<ILoggerFactory>();
        }
    }
در اینجا برای لاگ کردن خروجی EF می‌توان یک ILoggerFactory را که توسط متد AddFilter، سطوح لاگ کردن آن مشخص می‌شود، به UseLoggerFactory ارسال کرد.
‫۵ سال و ۷ ماه قبل، سه‌شنبه ۲۳ بهمن ۱۳۹۷، ساعت ۱۲:۴۴
عنوان کرده مسیر login/ را پیدا نمی‌کند (همان tokenPath که نهایتا به متد GrantResourceOwnerCredentials کلاس AppOAuthProvider منتهی می‌شود و توسط Owin مدیریت می‌شود. در ابتدای این متد یک break point قرار دهید. برنامه را اجرا کرده و سپس بر روی دکمه‌ی login کلیک کنید...). سپس تنظیمات سیستم، تنظیمات Owin ، مسیریابی‌ها و کانفیگ برنامه را بررسی کنید.
‫۵ سال و ۷ ماه قبل، شنبه ۲۰ بهمن ۱۳۹۷، ساعت ۲۱:۳۷
وجود پارامترهای مسیریابی برای انتقال اطلاعات به صفحات دیگر است. اما زمانیکه با «کوکی‌ها در ASP.NET Core» کار می‌کنید، اطلاعات آن‌ها در تمام صفحات در دسترس هستند. بنابراین قرار دادن مقدار آ‌ن‌ها در سیستم مسیریابی با متدهایی مانند return RedirectToAction زائد است.
خطای 400، صرفا یک خطای عددی نیست. ظاهر آن یک عدد است، اما می‌تواند شامل ریز جزئیات خطاهای ارسالی از سمت سرور هم باشد:

bad requestها (یا خطای 400) همان return BadRequest‌های اعتبارسنجی اطلاعات (و یا سایر خطاهایی که خود فریم ورک ارسال می‌کند و نه اعتبارسنجی کاربران با خطای 401) هستند. مطلب « نمایش خطاهای اعتبارسنجی سمت سرور ASP.NET Core در برنامه‌های Angular » را مطالعه کنید تا با روش استخراج ریز جزئیات ارسالی این نوع خطاها از سمت سرور و نمایش آن‌ها به کاربر آشنا شوید. به علاوه لاگ‌های سمت سرور را هم مدنظر داشته باشید.
‫۵ سال و ۷ ماه قبل، چهارشنبه ۱۷ بهمن ۱۳۹۷، ساعت ۱۴:۴۴
چون بر اساس اطلاعات header رسیده، اطلاعات دریافتی را به یک JSON Object تبدیل می‌کند که قابل انتساب به یک رشته نیست. به همین جهت برای مثال از JToken و یا یک کلاس سفارشی (که عنوان شد) می‌توانید برای دریافت اطلاعات یک شیء رسیده استفاده کنید.
Http Module منسوخ شده‌است (و زمانیکه ماژولی منسوخ شده اعلام می‌شود، یعنی در چند نگارش بعد، از کل مجموعه حذف خواهد شد). این سری از Http Client استفاده می‌کند که مطلب روش «ارتقاء به HTTP Client در Angular 4.3» را در این مورد می‌توانید مطالعه کنید؛ به همراه مطلب «ارتقاء به Angular 6: بررسی تغییرات RxJS». مباحث Interceptors توکار مورد استفاده‌ی در اینجا، برای Http Client آن وجود خارجی دارد. برای Http Module منسوخ شده‌، روش «راه‌اندازی Http Interceptor در Angular» وجود داشت.