یک نکته‌ی تکمیلی

کتابخانه‌ی « DNTScanner.Core » امکان کار با اسکنر را در برنامه‌های NET 4x‌. و همچنین NET Core. ویندوزی میسر می‌کند. روشی که در آن مورد استفاده قرار گرفته، مشکلات مطرح شده‌ی در نظرات مطلب جاری را مانند عدم امکان استفاده‌ی از آن، در سرویس‌های پس‌زمینه را ندارد؛ از این جهت که برای دسترسی به اسکنر، هیچ نوع UI ای را نمایش نمی‌دهد و تمام تنظیمات آن با کدنویسی است.

مثال‌ها
- روش استفاده از آن در برنامه‌های کنسول
- روش استفاده‌ی از آن در یک برنامه‌ی وب ASP.NET Core که قسمت اسکنر آن به صورت یک کلاینت کنسول تهیه شده‌است و ارتباط بین این دو از طریق SignalR.Core برقرار می‌شود.

با فرض اینکه ILogger یکی از وابستگی‌های ضروری کلاس موردنظر بوده است، هدف، برخورد defensive و متوجه شدن مشکلات ناشی از عدم ثبت صحیح سرویس مذکور در سیستم DI یا همان IoC Container و رفع آن می‌باشد. با این حال اگر بحث Logging یکی از وابستگی‌های اختیاری کلاس شما بود، استفاده از Null Object Pattern پیشنهاد می‌شود. 

یک نکته‌ی تکمیلی
اگر پس از مهاجرت به VS 2017، خطای ذیل را در حین اجرای مهاجرت‌ها مشاهده کردید:
الف) اسمبلی‌های ختم به Design و Tools باید دارای ویژگی "PrivateAssets="All شوند (میدان دید محدود به اسمبلی جاری) تا مشکلات circular dependency را ایجاد نکنند. یک نمونه 
ب) اگر در دستورات شما «configuration Release--» وجود دارد، آن‌را حذف کنید و نیازی به آن نیست؛ چون به صورت خودکار توسط MSBuild مدیریت می‌شود.

نمونه‌ای از تغییرات مورد نیاز جهت رفع این مشکل

متاسفانه این پیاده سازی خیلی قدیمه و مشکلات جدی هم داره، مثلا لینک ارتباط به سوکت رو با http شروع کردند در حالی که باید با ws باشه! نمیدونم بر چه اساسی چنین اشتباهاتی رو در کدنویسی رها کردند.

در تلریک:
می‌توانید گزارش هایی با منبع داده‌های متنوع که در زمان اجرا تولید می‌شوند، ایجاد نمایید.
می‌توانید پیاده سازی و تولید توابع جمعی سفارشی با قابلیت استفاده در سایر گزارشات ایجاد نمایید.
می‌توانید یک گزارش ایجاد نمایید که هم در محیط وب و هم در محیط ویندوز قابل نمایش باشد.
می‌توانید گزارشی داشته باشید از یونیکد بخوبی پشتیبانی می‌کند و مصائب و مشکلات کمتری در زبانهای راست به چپ دارد.
می‌توانید از کتابخانه‌های دیگر جهت تولید گزارش نیز بهره ببرید.
می‌توانید مراحل تولید گزارش را بصورت کدنویسی در کنترل داشته باشید.
نکات فوق، حاصل تجربه من با گزارش ساز تلریک است.

در انتهای سطر دوم مطلب، به این کتابخانه اشاره شده‌است. این مشکلات را دارد:
- چون از روش LINQ to Objects برای تهیه معادل رشته‌ای کوئری درخواستی استفاده می‌کند (دقیقا این روش: ^) قادر نیست Includeها و جوین‌های EF را پردازش کند و در این حالت برای تمام جوین‌ها یک هش مساوی را در سیستم خواهید داشت.
- چون قادر نیست cache dependencies را از کوئری به صورت خودکار استخراج کند، شما نیاز خواهید داشت تا پارامتر تگ‌های آن‌را به صورت دستی به ازای هر کوئری تنظیم کنید. این‌کار به صورت خودکار در پروژه‌ی جاری انجام می‌شود. cache dependencies به این معنا است که کوئری جاری به چه موجودیت‌هایی در سیستم وابستگی دارد. از آن برای به روز رسانی کش استفاده می‌شود. برای مثال اگر یک کوئری به سه موجودیت وابستگی دارد، با تغییر یکی از آن‌ها، باید کش غیرمعتبر شده و در درخواست بعدی مجددا ساخته شود.

- راه حل‌های مبتنی بر سشن، از Classics ASP دهه نود به ارث رسیده‌اند. عملا با پیشرفت‌هایی که حاصل شده نیازی به بسیاری از آن‌ها نیست. مصرف حافظه بالایی دارند و همچنین با ری‌استارت شدن برنامه در سرور، تمام سشن‌ها از بین خواهند رفت. این مشکلات در Forms Authentication وجود ندارند.
- قدمت Forms Authentication به ASP.NET 1.x بر می‌گردد. می‌توانید در این مورد در سایت‌های دیگر نیز بیشتر تحقیق کنید که آیا مشکل حادی از سال 2001 تا الان گزارش شده یا خیر.
- کلید رمزنگاری این کوکی‌ها در سمت سرور قرار دارد و تنها یک راه برای دسترسی به آن‌ها هست؛ دسترسی به سرور. در این حالت عملا کل سیستم مورد حمله قرار گرفته و یک کوکی شاید اهمیت خاصی نداشته باشد.
- ضمنا طول مدت زمان معتبر بودن اطلاعات Forms Authentication و دائمی بودن و نبودن کوکی‌های آن قابل تنظیم است (بحث شده در مطلب فوق).

همه این روش هارو دیدم که بعضی هاشون از جاوااسکریپت هم استفاده میکنند. ولی این روشها مشکلات زیادی دارن. شیرپوینت فقط یک سایت ساده نیست، Object Model داره کلی سرویس داره، فرم اینوپس و... . شیرپوینت میتونه همزمان از چند تا تقویم پشتیبانی بکنه. این روش‌ها خیلی سرسری مشکلو حل میکنن درکل نمیشه با این روشها یک راه کار درست حسابی ارائه داد.