محزونی محزونی
اشتراک‌ها
اشتراک کد بین ASP.NET و ASP.NET Core

مهاجرت برنامه ای که چندین سال از عمر آن می‌گذرد اغلب راحت نیست. با استفاده از امکانات دات نت 6 می‌توان این مهاجرت را ساده‌تر کرد

اشتراک کد بین ASP.NET و ASP.NET Core
‫۲ سال و ۶ ماه قبل، سه‌شنبه ۹ فروردین ۱۴۰۱، ساعت ۰۱:۳۴
محزونی محزونی
اشتراک‌ها
باگ های پرتکرار در IDisposable

اینترفیس System.IDisposable  یکی از پایه‌ترین اینترفیس‌ها در دات نت است. مسئولیت اصلی در زمان استفاده از این ایتنرفیس رهاسازی منابعی است که به صورت unmanaged در برنامه استفاده میکنیم. ساده‌تر از این امکان پذیر نیست یا ...؟

باگ های پرتکرار در IDisposable
‫۳ سال و ۶ ماه قبل، دوشنبه ۹ فروردین ۱۴۰۰، ساعت ۰۰:۵۴
محزونی محزونی
اشتراک‌ها
استفاده از nosdb در دات نت

این دیتابیس که در رده‌ی دیتابیس‌های nosql است به همراه ویژگی‌های خوبی مانند سرعت بالا و اپن سورس و ... در دسترس برنامه نویسان دات نت است.

استفاده از nosdb در دات نت
‫۸ سال قبل، جمعه ۳۰ مهر ۱۳۹۵، ساعت ۰۴:۱۶
کوکبی کوکبی
نظرات مطالب
مدیریت رجیستری در #C
ممنونم
با وجود دات نت و معماری جدید برنامه ها، معمولا در چه شرایطی استفاده از رجیستری دلیل قانع کننده ای داره؟ و اون دلیل قانع کننده چیه؟
‫۱۰ سال و ۱۱ ماه قبل، یکشنبه ۲۴ آذر ۱۳۹۲، ساعت ۱۶:۰۳
وحید نصیری وحید نصیری
نظرات مطالب
چگونه پروژه‌های Angular ی سبکی داشته باشیم - قسمت اول
مشکلی اصلی که در اینجا وجود دارد این است که چرا کامپایلر فعلی Angular (یعنی تا نگارش 7 آن)، قادر نیست وابستگی‌هایی را که در برنامه ارجاعی به آن‌ها وجود ندارند، در بسته یا بسته‌های کامپایل شده‌ی نهایی لحاظ نکند؟ این مشکل قرار است در نگارش 8 آن با ارائه‌ی یک کامپایلر جدید به نام Ivy که مدت زیادی است مشغول به کار بر روی آن هستند، برطرف شود:
The cool thing about Ivy versus the older compilers, however, is that it’s “ tree-shaking friendly ,” which basically means that it automatically removes unused bits of code (including unused Angular features!), shrinking your bundles.  
‫۵ سال و ۶ ماه قبل، دوشنبه ۱۹ فروردین ۱۳۹۸، ساعت ۱۵:۲۹
وحید نصیری وحید نصیری
اشتراک‌ها
انتخاب الگوریتم‌های هش سریع

این هش‌ها برای کارهای امن استفاده نمی‌شوند و صرفا کاربردهایی جهت تولید بانک‌های اطلاعاتی فوق سریع (key/value stores)، سیستم‌ها کش (تولید سریع کلید منحصربفرد) و یا جاهائیکه کارآیی بسیار مهم است، دارند. البته به نظر در حال حاضر xxHash از تمام این‌ها سریعتر است. یک نمونه پیاده سازی xxHash سریع در دات نت.

انتخاب الگوریتم‌های هش سریع
‫۹ سال و ۹ ماه قبل، چهارشنبه ۲۴ دی ۱۳۹۳، ساعت ۱۵:۳۷
وحید نصیری وحید نصیری
مطالب
first chance exception چیست؟
چند سال قبل یک datapicker تقویم شمسی را برای سیلورلایت تهیه کردم. بعد از آن نسخه‌ی WPF آن هم به پروژه اضافه شد. تا اینکه مدتی قبل مشکل عدم کار کردن آن در یک صفحه‌ی دیالوگ جدید در ویندوز 8 گزارش شد. در حین برطرف کردن این مشکل، مدام سطر ذیل در پنجره‌ی output ویژوال استودیو نمایش داده می‌شد:
 A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
البته برنامه بدون مشکل کار می‌کرد و صفحه‌ی نمایش Exception در VS.NET ظاهر نمی‌شد.


سؤال: first chance exception چیست؟

وقتی استثنایی در یک برنامه رخ می‌دهد، به آن یک first chance exception می‌گویند. این اولین شانسی است که سیستم به شما می‌دهد تا استثنای رخ داده را مدیریت کنید. اگر کدهای برنامه یا ابزاری (یک try/catch یا دیباگر) این اولین شانس را ندید بگیرند، یک second chance exception رخ می‌دهد. این‌جا است که برنامه به احتمال زیاد خاتمه خواهد یافت.
مشاهده‌ی پیام‌های A first chance exception در پنجره‌ی output ویژوال استودیو به این معنا است که استثنایی رخ داده، اما توسط یک استثناءگردان مدیریت شده‌است. بنابراین در اکثر موارد، موضوع خاصی نیست و می‌توان از آن صرفنظر کرد.


سؤال: چگونه می‌توان منشاء اصلی پیام رخ‌دادن یک first chance exception را یافت؟

ویژوال استودیو در پنجره‌ی output، مدام پیام رخ‌دادن first chance exception را نمایش می‌دهد؛ اما واقعا کدام قطعه از کدهای برنامه سبب بروز آن شده‌اند؟ به صورت پیش فرض صفحه‌ی نمایش استثناءها در VS.NET زمانی نمایان می‌شود که استثنای رخ داده، مدیریت نشده باشد. برای فعال سازی نمایش استثناهای مدیریت شده باید تنظیمات ذیل را اعمال کرد:
- به منوی Debug | Exceptions مراجعه کنید.
- گره Common Language Runtime Exceptions را باز کنید.
- سپس گروه System آن‌را نیز باز کنید.
- در اینجا بر اساس نوع استثنایی که در پنجره‌ی output نمایش داده می‌شود، آن استثناء را یافته و Thrown آن‌را انتخاب کنید.


اینبار اگر برنامه را اجرا کنید، دقیقا محلی که سبب بروز استثنای ArgumentOutOfRangeException شده در VS.NET گزارش داده خواهد شد.
‫۱۰ سال و ۱ ماه قبل، دوشنبه ۳۱ شهریور ۱۳۹۳، ساعت ۱۵:۴۰
رضا بازرگان رضا بازرگان
نظرات اشتراک‌ها
معرفی کتابخانه‌ی DNTCaptcha.Core
سلام؛ برای گرافیک شما از یک پکیج به نام CoreCaompat استفاده کردین/ از اونجایی که این برنامه رو با استاندارد نوشتین تا بشه تو دانت فریمورک هم ازش استفاده کرد. ا ز اونجایی که  Systme.Drawing تو دات نت فریمورک وجود داره علنا استفاده از coreCompat.Drawing غیر ممکن می‌شه. یعنی از این لایبرری فقط می‌شه تو اپ هایی با دات نت کور استفاده کرد. چه راهی  وجود داره که تو دات نت فریمورک هم از این استفاده کرد؟
‫۷ سال و ۳ ماه قبل، شنبه ۱۷ تیر ۱۳۹۶، ساعت ۲۱:۲۲
وحید نصیری وحید نصیری
مطالب
بررسی بهبودهای پروسه‌ی Build در دات‌نت 8

در نگارش‌های اخیر دات‌نت، NET CLI. به همراه تغییرات قابل توجهی بوده‌است که در این مطلب و نظرات آن، موارد مهم این تغییرات را بررسی خواهیم کرد.

console logger بهبود یافته‌ی دات‌نت 8

یکی از تغییرات بسیار جالب توجه و مفید NET CLI. در دات‌نت 8، امکان دسترسی به خروجی لاگ‌های ساختار یافته‌ی اعمال خط فرمان آن است:

اگر پروژه‌ی خود را با استفاده از دستور dotnet build، کامپایل می‌کنید، خروجی پیش‌فرض این دستور خط فرمان، کلی و بدون ارائه‌ی جزئیات است؛ اما می‌توان آن‌را در دات‌نت 8، به شکل تصویر فوق، تغییر داد و به این مزایا رسید:

  • امکان مشاهده‌ی زمان کامپایل هر قسمت به صورت جداگانه
  • امکان مشاهده‌ی پویای درصد انجام عملیات
  • امکان مشاهده‌ی جزئیات کامپایل هر target framework به صورت مجزا
  • دسترسی به یک خروجی رنگی و زیباتر

این خروجی را که به صورت پیش‌فرض فعال نیست، می‌توان به دو صورت:

الف) سراسری و با اجرای دستور PowerShell زیر:

[Environment]::SetEnvironmentVariable("MSBUILDTERMINALLOGGER", "auto", "User")

که متغیر محیطی MSBUILDTERMINALLOGGER را به auto تنظیم می‌کند،

ب) و یا با استفاده از سوئیچ tl-- به ازای هر دستور dotnet build، به صورت جداگانه‌ای فعال کرد:

dotnet build --tl

یک نکته: این قابلیت جالب و مهم، در دات نت 9، به صورت پیش‌فرض فعال است و نیازی به تنظیم خاصی ندارد.

‫۲ ماه قبل، پنجشنبه ۲۵ مرداد ۱۴۰۳، ساعت ۱۲:۵۰
وحید نصیری وحید نصیری
مطالب
چطور مسیریابی‌های ASP.NET MVC را دیباگ کنیم؟
سؤال: من برای تهیه sitemap برنامه، یک route سفارشی نوشته‌ام تا یک فایل xml ایی را که در وب سرور، وجود خارجی ندارد، در آدرس‌های سایت قابل دسترسی کند. برای مثال:
            routes.MapRoute(
                "SiteMap_route", // Route name
                "sitemap.xml", // URL with parameters
                new { controller = "Sitemap", action = "index", name = UrlParameter.Optional, area = "" } // Parameter defaults
            );
با استفاده از این مسیریابی خاص، قرار است هر زمانیکه آدرس http://site/sitemap.xml در مرورگر وارد شد، برنامه در پشت صحنه، به صورت خودکار به کنترلر sitemap و اکشن متد index آن مراجعه کرده و یک محتوای پویای XML ایی را تولید کند و بازگشت دهد. اما ... کار نمی‌کند! یعنی آدرس یاد شده اصلا پاسخ نمی‌دهد. چرا؟ نحوه‌ی ثبت مسیریابی سفارشی تعریف شده نیز به صورت زیر است:
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
            );

            routes.MapRoute(
                "SiteMap_route", // Route name
                "sitemap.xml", // URL with parameters
                new { controller = "Sitemap", action = "index", name = UrlParameter.Optional, area = "" } // Parameter defaults
            );
        }
پاسخ: اگر با تقدم و تاخر و معنای مسیریابی‌های تعریف شده آشنایی داشته باشید، شاید بلافاصله بتوانید مشکل را حدس بزنید. اما اگر تعداد مسیریابی‌های سفارشی تعریف شده زیاد باشد، اینکار ساده نیست و حتما نیاز به ابزار دیباگ دارد تا بتوان تشخیص داد که در صفحه جاری کدامیک از مسیریابی‌های تعریف شده کار را تمام کرده‌اند و نوبت به دیگری نرسیده است.

برای این منظور می‌توان از افزونه‌ای به نام RouteDebug نوشته یکی از اعضای سابق تیم ASP.NET MVC استفاده کرد:
کار کردن با آن نیز بسیار ساده است.
الف) ارجاعی را به اسمبلی RouteDebug.dll (حاصل از کامپایل پروژه فوق) به پروژه جاری ASP.NET MVC خود اضافه کنید.
ب) سپس به فایل Global.asax.cs خود مراجعه و در سطر آخر متد Application_Start آن، فراخوانی ذیل را اضافه نمائید:
 RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);
اکنون هر صفحه و آدرسی را که باز کنید، بجای محتوای اصلی صفحه، مسیریابی‌های فعال و برنده آن‌را مشاهده خواهید کرد. برای مثال در صفحه اول برنامه داریم:


نکته مهمی که در این تصویر باید به آن دقت داشت، اولین True سبز رنگی است که نمایش می‌دهد. یعنی اولین مسیریابی که کار هدایت و نمایش صفحه جاری را برعهده دارد. در اجرای عادی ASP.NET MVC، همینجا کار پردازش سیستم مسیریابی صفحه جاری خاتمه خواهد یافت و نوبت به سایرین نخواهد رسید.
در مورد صفحه sitemap.xml چطور؟ اگر این آدرس را در مرورگر، بدون فعال سازی افزونه RouteDebug وارد کنیم، پیام 404 را دریافت می‌کنیم. اگر افزونه را فعال کنیم، اینبار به صفحه زیر خواهیم رسید:


بله. همانطور که مشاهده می‌کنید، مسیریابی پیش فرض، اینبار نیز برنده بوده است و اولین تطابق صورت گرفته با آن صورت می‌گیرد. بنابراین اصلا کار به استفاده از مسیریابی سفارشی تعریف شده توسط ما نخواهد رسید.
بنابراین محل تعریف این مسیریابی را اکنون به پیش از مسیریابی پیش فرض انتقال می‌دهیم:
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                "SiteMap_route", // Route name
                "sitemap.xml", // URL with parameters
                new { controller = "Sitemap", action = "index", name = UrlParameter.Optional, area = "" } // Parameter defaults
            );

            routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
            );      
        }
در ادامه اگر مجددا مسیر sitemap.xml را درخواست کنیم، به تصویر ذیل خواهیم رسید:


بله. با این تنظیم صورت گرفته، اینبار دیگر سیستم مسیریابی، برای تفسیر مسیر سفارشی تعریف شده، به سراغ مسیریابی پیش فرض نخواهد رفت و کار همینجا خاتمه می‌یابد.

سؤال: آیا اینکار تداخلی در عملکرد اصلی برنامه ایجاد نمی‌کند؟ مثلا اگر به مسیر index کنترلر home مراجعه کنیم، مشکلی نخواهد بود؟
پاسخ: خیر. برای آزمایش آن باز هم به افزونه RouteDebug مراجعه خواهیم کرد:


همانطور که مشخص است، مسیریابی برنده در این حالت، همان مسیریابی پیش فرض است و نه مسیریابی سفارشی آدرس خاص sitemap.xml سایت.


یک نکته تکمیلی
افزونه گلیمپس نیز امکان دیباگ Routeها را دارد؛ اما توانایی بررسی مشکلات Routing یک خطای 404 مانند مثال فوق را حداقل تا زمان نگارش این مطلب ندارد و همان افزونه RouteDebug یاد شده، بهتر عمل می‌کند.
‫۱۰ سال و ۱۲ ماه قبل، چهارشنبه ۸ آبان ۱۳۹۲، ساعت ۱۲:۲۵