نظرات مطالب
ایجاد کپچایی (captcha) سریع و ساده در ASP.NET MVC 5

ممنون از شما. فقط یک نکته‌ی کوچک در مورد memory stream هست که بهتره درنظر گرفته بشه. در این شیء متدهای ToArray و GetBuffer یکی نیستند. متد GetBuffer حجمی نزدیک به 2 برابر آرایه اصلی رو عموما داره و انتهاش یک سری بایت‌های اضافی هم شاید باشند. اما ToArray اصل دیتا رو بر می‌گردونه.

Note that the buffer contains allocated bytes which might be unused. For example, if the string "test" is written into the MemoryStream object, the length of the buffer returned from GetBuffer is 256, not 4, with 252 bytes unused. To obtain only the data in the buffer, use the ToArray method; however, ToArray creates a copy of the data in memory.

نظرات مطالب
سازماندهی برنامه‌های Angular توسط ماژول‌ها
چند نکته‌ی تکمیلی در مورد بهبود تعاریف Shared Module و Core Module

الف) چگونه از import ثانویه‌ی Core Module در سایر ماژول‌ها جلوگیری کنیم؟
Core Module فقط باید در AppModule برنامه import شود و نه در هیچ‌جای دیگری. برای جلوگیری اتفاقی از این مساله می‌توان سازنده‌ای را به شکل زیر به آن اضافه کرد:
@NgModule({
  imports: [CommonModule, RouterModule],
  exports: [], // components that are used in app.component.ts will be listed here.
  declarations: [], // components that are used in app.component.ts will be listed here.
  providers: [BrowserStorageService, AppConfigService] // global singleton services of the whole app will be listed here.
})
export class CoreModule {
  constructor( @Optional() @SkipSelf() core: CoreModule) {
    if (core) {
      throw new Error("CoreModule should be imported ONLY in AppModule.");
    }
  }
};
روش کار به این صورت است که خود CoreModule را به سازنده‌ی همان کلاس تزریق می‌کنیم! اگر وهله‌ای از آن قابل دسترسی بود، یعنی Angular پیشتر این ماژول را import کرده‌است. در این حالت با صدور خطایی این مشکل را گوشزد می‌کنیم.
از همین روش برای تشخیص singleton بودن یک سرویس نیز می‌توان استفاده کرد. خودش را به خودش تزریق می‌کنیم! اگر تزریقی صورت گرفت، یک خطا را صادر می‌کنیم.


ب) چگونه از وهله سازی مجدد سرویس‌های تعریف شده‌ی در Shared Module در سایر ماژول‌ها جلوگیری کنیم؟
هدف از قسمت providers در Shared Module تنها ارائه‌ی سرویس‌هایی جهت کامپوننت‌های اشتراکی آن است؛ وگرنه سرویس‌های سراسری برنامه در CoreModule تعریف می‌شوند و این ماژول ویژه نیز تنها یکبار و آن‌هم در AppModule برنامه import خواهد شد. اما در مورد Shared Module اینطور نیست و اگر این ماژول در یک lazy loaded module استفاده شود، سرویس‌های آن طول عمر متفاوتی را پیدا خواهند کرد (هر lazy loaded module یک injector و یک طول عمر خاص خودش را تعریف می‌کند).
در این حالت برای اینکه سرویس‌های Shared Module فقط در AppModule وهله سازی شوند و نه در هیچ‌جای دیگری، روش کار به صورت ذیل است:
- ابتدا آرایه‌ی providers را از تعاریف NgModule آن حذف می‌کنیم.
- سپس متد ویژه‌ای را به نام forRoot، به کلاس آن اضافه خواهیم کرد:
@NgModule({
  imports: [CommonModule],
  declarations: [], // common and shared components/directives/pipes between more than one module and components will be listed here.
  exports: [CommonModule], // common and shared components/directives/pipes between more than one module and components will be listed here.
  /* No providers here! Since they’ll be already provided in AppModule. */
})
export class SharedModule {
  static forRoot(): ModuleWithProviders {
    // Forcing the whole app to use the returned providers from the AppModule only.
    return {
      ngModule: SharedModule,
      providers: [ /* All of your services here. It will hold the services needed by `itself`. */]
    };
  }
};
متد forRoot به صورت استاتیک تعریف می‌شود و همچنین خروجی از نوع ModuleWithProviders دارد. توسط ModuleWithProviders سبب خواهیم شد، AppModule، این ماژول را به همراه آرایه‌ی providers آن import کند؛ اما سایر ماژول‌ها خیر.
سایر ماژول‌ها چون دسترسی به آرایه‌ی حذف شده‌ی providers این ماژول را ندارند، دیگر نمی‌توانند سرویس‌های آن‌را وهله سازی کنند. اما AppModule با فراخوانی ()SharedModule.forRoot در لیست import خود، تنها یکبار سبب وهله سازی سرویس‌های آن می‌گردد.
بنابراین در اینجا AppModule باید ()SharedModule.forRoot را import کند. سایر ماژول‌ها فقط SharedModule را import می‌کنند (بدون ذکر متد forRoot). به این ترتیب سرویس‌های آن تنها یکبار توسط AppModule در طول عمر برنامه به اشتراک گذاشته می‌شوند و در این حالت تفاوتی نمی‌کند که SharedModule در یک lazy loaded module استفاده شده‌است یا خیر.

روش تعریف متد forRoot توسط سیستم مسیریابی Angular نیز استفاده می‌شود و یک الگوی پذیرفته شده در بین توسعه دهندگان Angular است. برای مثال ()RouterModule.forRoot در AppModule تعریف می‌شود و ()RouterModule.forChild برای سایر ماژول‌ها.

نمونه‌ای از AppModule ، ShardModule و CoreModule
اشتراک‌ها
پیش نمایش JetBrains Rider

Rider is a full featured, cross platform .NET IDE based on ReSharper and IntelliJ. The front end and user interface is built on the proven IntelliJ platform, just like WebStorm or IntelliJ IDEA, and can run on Windows, Linux and Mac. But the engine that drives all of your favourite JetBrains IDE features is ReSharper, running as an out of process language server.

پیش نمایش JetBrains Rider
اشتراک‌ها
معرفی XAML Islands v1

XAML Islands enable .NET and native Win32 applications to host UWP XAML controls. You can enhance the experience and functionality of your existing desktop applications with the latest UI innovations previously only available for UWP apps.  

معرفی XAML Islands v1
اشتراک‌ها
شرکت در نظرسنجی رسمی Entity Framework Core
The team behind Entity Framework Core thanks you for your interest in our product. I am a Senior Program Manager for .NET data at Microsoft and work closely with the EF Core team. As part of our ongoing effort to improve the experience of working with data in .NET, we developed a short survey to learn more about how you work with data. It should only take a few minutes of your time. 
شرکت در نظرسنجی رسمی Entity Framework Core
اشتراک‌ها
مروری بر قالب ساخت نصاب در Visual Studio 2019

thanks to a new feature added in Visual Studio 2019 16.1, we can combine the best of both worlds when it comes to support the App Installer technology: the easiness of automatically generating an .appinstaller file as part of the package creation process and the flexibility of the new update features added in Windows 10 1903. 

مروری بر قالب ساخت نصاب در Visual Studio 2019
مطالب
آشنایی با ساختار IIS قسمت دوم
در قسمت قبلی گفتیم که IIS از تعدادی کامپوننت تشکیل شده است و به یکی از آن‌ها به نام Http.sys پرداختیم. در این قسمت قصد داریم به WWW Services بپردازیم.

اجازه بدهید قبل از هر چیزی به دو مفهوم اصلی در IIS بپردزیم :

1. Worker Process

2. Application Pool

پروسه‌های کارگر  w3wp.exe  وظیفه‌ی اجرای برنامه‌های asp.net را در IIS ، به عهده دارند. این پروسه‌ها مسئولیت پردازش تمامی درخواست و پاسخ‌ها از/به کلاینت را دارند. هر کاری که باید در asp.net انجام بشود، توسط این‌ها صورت می‌گیرد. به بیان ساده‌تر این پروسه‌ها قلب برنامه‌های ASP.Net بر روی IIS هستند .

Application Pool:این پول‌ها در واقع ظرفی یا در برگیرنده ای برای پروسه‌های کارگر به حساب می‌آیند. این پول‌ها پروسه‌های کارگر را از هم جدا و دسته بندی می‌کنند تا قابلیت اعتماد، امنیت و در دسترس بودن بدهند. موقعی که یک پروسه یا حتی یک پول دچار مشکل می‌شود، این اطمینان داده می‌شود که تاثیری بر دیگر پول‌ها یا پروسه‌های کارگر، ندارد. یعنی موقعی که یک web application  دچار مشکل شود، هیچ تاثیری بر اجرای  web application‌های دیگر ندارد. به یک application pool با چند پروسه کارگر  web garden  میگویند. 


World Wide WebPublishing Services
یکی از قدیمی‌ترین امکانات موجود در IIS هست که از نسخه 7 به بعد، کار خود را با یک سروریس جدید به اسم Windows Process Activation Service یا به اختصار WAS که به صورت local system بر روی پروسه Svchost.exe با یک کد باینری یکسان اجرا می‌شود، شریک شده است. ممکن است در بعضی جاها WWW Service به صورت W3SVC هم نوشته شود.

اصلا این WWW Service چه کاری انجام می‌دهد و به چه دردی می‌خورد؟
این سرویس در سه بخش مهم  IIS 6 به فعالیت می‌پردازد:
  • HTTP administration and configuration
  •  Performance monitoring
  • Process management

HTTP Administration and Configuration 

سرویس WWW وظیفه خواندن اطلاعات پیکربندی IIS از متابیس را بر عهده دارد و از این اطلاعات خوانده شده برای پیکربندی و به روز کردن Http.sys استفاده می‌کند. به غیر از این کار، وظیفه آغاز و توقف و نظارت یا مانیتورینگ و همچنین مدیریت کامل پروسه‌های کارگر در زمینه http request را هم عهده دار است.

Performance Monitoring 
سرویس WWW بر کارآیی وب سایت‌ها و کش IIS نظارت می‌کند و البته یک شمارنده کارآیی performance counter هم ایجاد می‌کند. کار شمارنده کارآیی این است که اطلاعات یک سرویس یا سیستم عامل یا یک برنامه کاربردی را جمع آوری می‌کند تا به ما بگوید که این بخش‌ها به چه میزانی بهینه کار خود را انجام می‌دهند و به ما کمک می‌کنند که سیستم را به بهترین کارآیی برسانیم. سیستم عامل، شبکه و درایورها، داده‌های شمارشی را تهیه و در قالب یک سیستم نظارتی گرافیکی به کارشناس سیستم یا شبکه نشان می‌دهند. برنامه نویس‌ها هم از این طریق می‌توانند برنامه‌های خود را بنویسند که در اینجا لیستی از شمارنده‌ها در دانت نت را می‌توانید ببینید و بیشتر آن‌ها از طریق فضای نام system.diagnostic در دسترس هستند.

Process Management 
سرویس www مدیریت application pool و پروسه‌های کارگر را هم به عهده دارد. این مدیریت شامل شروع و توقف و بازیابی پروسه‌های کارگر می‌شود. به علاوه اینکه این سرویس کار نظارت بر صحت انجام عملیات پروسه‌های کارگر را هم جز وظایف خود می‌داند. وقتی که چندین بار کار پروسه‌های کارگر در یک دوره زمانی که در فایل پیکربندی مشخص شده با مشکل مواجه شود، از شروع یک پروسه کارگر دیگر جلوگیری می‌کند.

در نسخه‌های جدیدتر IIS چکاری بر عهده WWW Service است؟
در IIS7 به بعد، دیگر مدیریت پروسه‌های کارگر را به عهده ندارد؛ ولی به جای آن سمتی جدید را به اسم listener adapter، دریافت کرده است که یک listener adapter برای http listener یعنی Http.sys است. اصلی‌ترین وظیفه فعلی را که انجام می‌دهد پیکربندی Http.sys می‌باشد. موقعی که اطلاعات پیکربندی به روز می‌شوند باید این تغییرات بر روی Http.sys اعمال شوند. دومین وظیفه آن این است موقعی که درخواست جدیدی وارد صف درخواست‌ها می‌شود این مورد را به اطلاع WAS برساند.
WAS در قسمت سوم این مقاله توضیح داده خواهد شد.