‫۴ سال و ۱۰ ماه قبل، یکشنبه ۵ آبان ۱۳۹۸، ساعت ۱۶:۰۳
روشی که خودشان برای این نوع تبدیلات (تبدیل عدد ارسالی به صورت رشته‌ای یا همان عدد داخل "") پیشنهاد کرده‌اند به این صورت هست:
using System;
using System.Buffers;
using System.Buffers.Text;
using System.Text.Json;
using System.Text.Json.Serialization;

namespace Test
{
    public class LongToStringConverter : JsonConverter<long>
    {
        public override long Read(ref Utf8JsonReader reader, Type type, JsonSerializerOptions options)
        {
            if (reader.TokenType == JsonTokenType.String)
            {
                ReadOnlySpan<byte> span = reader.HasValueSequence ? reader.ValueSequence.ToArray() : reader.ValueSpan;
                if (Utf8Parser.TryParse(span, out long number, out int bytesConsumed) && span.Length == bytesConsumed)
                {
                    return number;
                }

                if (long.TryParse(reader.GetString(), out number))
                {
                    return number;
                }
            }

            return reader.GetInt64();
        }

        public override void Write(Utf8JsonWriter writer, long value, JsonSerializerOptions options)
        {
            writer.WriteStringValue(value.ToString());
        }
    }
}
در نگارش NET 5.0. به نظر قرار هست گزینه‌ای شبیه به options.DeserializeQuotedNumbers == true برای مدیریت این نوع موارد اضافه شود.
‫۴ سال و ۱۰ ماه قبل، یکشنبه ۵ آبان ۱۳۹۸، ساعت ۱۵:۴۹
کمی بالاتر در مورد خطای 500.19 ای که نیاز به دسترسی بیشتری دارد، توضیح داده شد. افزودن authenticated users زیاده روی هست. از لیست تمام این authenticated users، فقط یک یوزر IIS AppPool\DefaultAppPool باید دسترسی به پوشه‌ی برنامه‌ی شما را داشته باشد.
‫۴ سال و ۱۰ ماه قبل، یکشنبه ۵ آبان ۱۳۹۸، ساعت ۱۵:۴۷
قسمت
if (int.TryParse (value, out _))
   return int.Parse (value);
به این نحو قابل بازنویسی است:
if (int.TryParse (value, out var result))
   return result;
‫۴ سال و ۱۰ ماه قبل، یکشنبه ۵ آبان ۱۳۹۸، ساعت ۱۲:۳۱
یک نکته‌ی تکمیلی: ارتقاء به نگارش 3.1 و تغییر تنظیمات کوکی‌ها


مرورگر کروم، از نگارش 80 آن به بعد به همراه یک تغییر غیرسازگار با نگارش‌های قبلی آن است: از این پس تمام کوکی‌های آن در صورتیکه تنظیمات SameSite را نداشته باشند، به صورت SameSite=Lax تفسیر می‌شوند؛ که تغییر امنیتی فوق العاده‌ای است و سبب خواهد شد تا بسیاری از حملات مانند CSRF به طور کامل غیرعملی شوند. اما ... این مورد سبب از کار افتادن برنامه‌هایی خواهد شد که از سرویس‌هایی مانند IdentityServer استفاده می‌کنند. در یک چنین حالتی نیاز خواهید داشت برای رفع این مشکل، SameSite=None را تنظیم کنید.

اما SameSite چیست؟ تنظیم و خاصیت SameSite از سال 2016 به کوکی‌ها اضافه شد تا بتوان توسط آن در برابر حملات CSRF مقاومت کرد؛ مقادیر اولیه‌ی آن نیز Lax و Strict بودند. Lax به این معنا است که کوکی‌ها در حین مرور یک سایت، باید به صورت خودکار به سمت سرور همان سایت ارسال شوند؛ اما در حالت مرور سایت و هدایت از طریق سایت‌های دیگر به سایت ما، فقط درخواست‌های GET رسیده می‌توانند کوکی‌ها را نیز ارسال کنند. حالت Strict آن فقط کوکی‌های تنظیم شده‌ی درون یک سایت را معتبر شمرده و ارسال می‌کند. عدم تنظیم SameSite نیز مشکل خاصی را ایجاد نمی‌کرد. برای مثال اعمال اعتبارسنجی مبتنی بر OpenIdConnect مانند login/logout، نیاز دارند در طی یک درخواست POST، اطلاعاتی را به سایت خارجی درخواست کننده ارسال کنند. برای اینکه این عملیات به درستی صورت گیرد، می‌بایستی تنظیمات SameSite انجام نمی‌شد تا جابجایی کوکی‌ها بین دو دومین مختلف در حالت POST، بدون مشکل صورت می‌گرفت.
با تغییر جدید گوگل، حالت پیش‌فرض SameSite که اجباری نبود، به صورت اجباری به Lax تنظیم شده‌است؛ اما برای حالاتی مانند OpenIdConnect، مقدار None را نیز اضافه کرده‌است. به همین جهت این نوع برنامه‌ها اگر از تنظیم SameSite=None استفاده نکنند، دیگر نمی‌توانند کوکی‌های درخواست‌های POST را بین دومین‌های مختلف جابجا کنند.

مشکل مهم! مقدار None را فقط مرورگر کروم متوجه می‌شود و جزو استاندارد SameSite نیست! در این استاندارد اگر مقدار SameSite تنظیم شود و مرورگر نتواند آن‌را تشخیص دهد (مانند iOS 12)، مقدار Strict را به عنوان مقدار دریافتی تنظیم می‌کند! به همین جهت برنامه‌ی شما باید بر اساس نوع مرورگر تصمیم‌گیری کند که آیا باید SameSite را به خروجی اضافه کند یا خیر.

وضعیت دات نت در این مورد: با به روز رسانی‌های جدید دات نت 4.7.2 و همچنین NET Core 2.1.، مقدار جدید None توسط برنامه (در CookieOptions) قابل تنظیم خواهد بود که سبب تولید SameSite=None می‌شود. به علاوه در NET Core 3.1.،  مقدار SameSite.Unspecified را نیز می‌توان تنظیم کرد که سبب خواهد شد تا خاصیت SameSite اصلا تنظیم نشود (اصلا به درخواست اضافه نشود؛ تا مرورگرهایی که نمی‌توانند مقدار None را تفسیر کنند، به اشتباه آن‌را به Strict تنظیم نکنند).

به صورت خلاصه: اگر برنامه‌ی شما از OpenIdConnect و یا IdentityServer استفاده نمی‌کند، هیچ تنظیمی را تغییر ندهید! تنظیم پیش‌فرض SameSite=Lax گوگل سبب می‌شود تا عملا حملات CSRF دیگر بر روی سایت شما قابل اجرا نباشد. اما اگر از IdentityServer استفاده می‌کنید، این تنظیم پیش‌فرض، سبب از کار افتادن امکان ارسال کوکی‌های حالت POST، به سایت‌های خارجی می‌شود و برنامه و سیستم شما از کار خواهد افتاد.
‫۴ سال و ۱۰ ماه قبل، سه‌شنبه ۳۰ مهر ۱۳۹۸، ساعت ۱۲:۰۹
یک روش دیگر در صف قرار دادن Taskها برای اجرای موازی، در مطلب «ParallelExtensionsExtras Tour – #7 – Additional TaskSchedulers» توسط خود تیمی که Taskها را برای اولین بار معرفی کرد، در فایل:
C# and C++ and F# and VB\C#,C++,F#,VB\ParallelExtensionsExtras\TaskSchedulers\QueuedTaskScheduler.cs
مثال‌های آن مطلب ارائه شده. از یک نمونه‌ی ساده شده‌ی آن در برنامه‌ی GitHubFolderDownloader برای دریافت لیستی از فایل‌ها استفاده کردم.
‫۴ سال و ۱۰ ماه قبل، سه‌شنبه ۳۰ مهر ۱۳۹۸، ساعت ۰۵:۴۱
خطای 415 از سمت سرور یعنی unsupported media type. مطلب «جایگزین کردن jQuery با JavaScript خالص - قسمت پنجم - درخواست‌های Ajax» را مطالعه کنید تا با معادل‌های قبلی و جدید fetch api و نحوه‌ی صحیح تنظیم و «کار با JSON Encoding» آشنا شوید (headers: {'Content-Type': 'application/json'}). همچنین می‌تواند مشکل CORS و عدم تنظیم آن هم باشد (اگر برنامه‌ی کلاینت روی پورت x و برنامه‌ی سرور روی پورت y اجرا می‌شود و این دو پورت یکی نیستند).
‫۴ سال و ۱۰ ماه قبل، دوشنبه ۲۹ مهر ۱۳۹۸، ساعت ۱۴:۱۶
امکان دیباگ کردن ریز فعالیت‌های System.Net به صورت زیر وجود دارد:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <system.diagnostics>
   <trace autoflush="true" />
   <sources>
     <source name="System.Net">
       <listeners>
         <add name="MyTraceFile"/>
       </listeners>
     </source>
   </sources>

   <sharedListeners>
     <add
       name="MyTraceFile"
       type="System.Diagnostics.TextWriterTraceListener"
       initializeData="System.Net.trace.log"
               />
   </sharedListeners>

   <switches>
     <add name="System.Net" value="Verbose" />
   </switches>

 </system.diagnostics>
</configuration>
که به فایل app.config و یا web.config قابل افزودن است. به این صورت کلیه هدرهای ارسالی به سرور و ریز فعالیت‌های انجام شده در پشت صحنه‌، در فایلی به نام System.Net.trace.log برای شما ثبت خواهد شد. 
‫۴ سال و ۱۰ ماه قبل، یکشنبه ۲۸ مهر ۱۳۹۸، ساعت ۱۵:۲۵
- در کجا استفاده شود؟ برای شبکه‌ی داخلی؟ قابل استفاده نیست؛ مگر اینکه تک تک کلاینت‌های ریموت، مجوز خود امضا شده‌ی شما را دستی دریافت، دستی نصب و دستی مورد اطمینان اعلام کنند.
- مجوز خود امضاء شده‌ای که قرار است در این قسمت ظاهر شود، باید به این صورت توسط برنامه‌ی openssl تولید شود:
"C:\Program Files\Git\usr\bin\openssl.exe" genrsa -out private.key 2048
"C:\Program Files\Git\usr\bin\openssl.exe" req -new -x509 -key private.key -out publickey.cer -days 1398
"C:\Program Files\Git\usr\bin\openssl.exe" pkcs12 -export -out idp.pfx -inkey private.key -in publickey.cer
و بعد هم فایل pfx نهایی آن در local machine نصب شود (دوبار کلیک بر روی آن) و یا «یک نکته‌ی تکمیلی: UseHttpSys و استفاده‌ی از HTTPS»