نظرات مطالب
آشنایی با قابلیت FileStream اس کیوال سرور 2008 - قسمت سوم
سلام
ممنون از مطلب مفیدتون
یک سؤالی که برام پیش اومده اینه که ، این فایل‌ها که در مسیر مشخص شده ذخیره شدن ، موندگار هستن یا موقتی اند ؟
 
نظرات مطالب
SignalR
سلام
یعنی مسیر و محتوای signalr/hubs در هتگام اجرا تولید میشه؟
من مثال شما رو دنبال کردم ولی خروجی مورد نظر رو نگرفتم
نظرات مطالب
بررسی دقیق‌تر صفحات آبی ویندوز
مشکل RAM هست: (یکی از RAM های شما معیوب است)
KERNEL_MODE_EXCEPTION_NOT_HANDLED win32k.sys
توضیحات بیشتر: (+)
یکبار دیگر با این برنامه تست کنید:
memtest

و بله. در ویندوز هفت پیش فرض آن مسیر SystemRoot\MEMORY.DMP است.
پاسخ به بازخورد‌های پروژه‌ها
خطای null
نیازی به نصب ندارند. فقط مسیر فونت را باید صحیح مقدار دهی کنید.
مثال‌های زده شده فونت را از پوشه fonts سیستم می‌خوانند. این پوشه را تغییر دهید به یک پوشه‌ی دیگر.
پاسخ به بازخورد‌های پروژه‌ها
گزارش خطا
نه. به عمد این بررسی را قرار دادم؛ چون نصاب فایل‌های VSIX اگر طول مسیر بیشتر از حدی باشد، متوقف می‌شود و کار نمی‌کند. یعنی محدودیت اصلی از طرف خود مایکروسافت است.
پاسخ به بازخورد‌های پروژه‌ها
استفاده از فونت های مختلف در گزارش
برای این حالت که فونت BNazanin بر روی سرور وجود ندارد آیا لازم است که من فونت BNazanin را درون یک فولدر در وب سایت خودم قرار دهم و در اینجا مسیر فونت رو از وب سایت خودم انجام دهم؟
نظرات مطالب
سازماندهی برنامه‌های 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
مطالب
نحوه‌ی پردازش |DataDirectory| در Entity framework
جهت تعیین مسیر فایل بانک اطلاعاتی برنامه در رشته‌های اتصالی، عموما توصیه می‌شود که از |DataDirectory| استفاده شود. برای مثال:
 AttachDBFilename=|DataDirectory|\database.mdf
اما ... این |DataDirectory| دقیقا چگونه محاسبه می‌شود؟
اگر به سورس EF مراجعه کنیم، متد DbProviderServices.ExpandDataDirectory پیاده سازی مرتبط را به همراه دارد:
 // find the replacement path
var rootFolderObject = AppDomain.CurrentDomain.GetData("DataDirectory");
به این معنا که DataDirectory می‌تواند یکی از ثوابت AppDomain جاری باشد و مسیر جایگزین آن به این نحو محاسبه و تعیین می‌گردد.


مقدار DataDirectory در برنامه‌های وب

در برنامه‌های ASP.NET مقدار DataDirectory یک AppDomain از پیش تعیین شده‌است و دقیقا به مسیر کامل پوشه‌ی استاندارد App_Data ختم می‌شود.


مقدار DataDirectory در برنامه‌های دسکتاپ

در برنامه‌های غیر وب، مقدار DataDirectory یک AppDomain تعیین نشده و نال است. برای رفع این مشکل کافی است در آغاز برنامه، DataDirectory را برای مثال به نحو زیر مقدار دهی کرد:
 AppDomain.CurrentDomain.SetData("DataDirectory", AppDomain.CurrentDomain.BaseDirectory);

چند نکته‌ی تکمیلی
با مطالعه‌ی سورس EF می‌توان دریافت که:
- پس از |DataDirectory| تنها یک \ باید قرار گیرد.
- اگر مسیر ذکر شده پس از |DataDirectory| یک مسیر نسبی مانند \.. باشد، مورد قبول واقع نشده و یک استثناء صادر می‌شود. جمع  |DataDirectory| و مسیر پس از آن باید یک مسیر کامل را تشکیل دهند.
نظرات مطالب
احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular - قسمت ششم - کار با منابع محافظت شده‌ی سمت سرور
یک نکته‌ی تکمیلی: بهبود کنترل نمایش و مخفی سازی قسمت‌های مختلف

یک روش «نمایش و یا مخفی کردن قسمت‌های مختلف صفحه بر اساس نقش‌های کاربر وارد شده‌ی به سیستم» را در مطلب جاری مطالعه کردید. روش دیگر اینکار، تهیه‌ی یک دایرکتیو و سپس اعمال آن به المان‌های مختلف صفحه است. به علاوه با توجه به اینکه Auth Service ما رخ‌داد خروج کاربر را نیز گزارش می‌کند، روش ارائه شده‌ی در اینجا نیاز به اندکی بهبود هم دارد:
  ngOnInit() {
    this.isAdmin = this.authService.isAuthUserInRole("Admin");
    this.isUser = this.authService.isAuthUserInRole("User");
  }
نتیجه‌ی این بررسی، حتی با خروج کاربر نیز تغییری نخواهد کرد و ثابت است. بنابراین بهتر است مشترک this.authService.authStatus شد و نسبت به رخ‌دادهای صادر شده‌ی توسط سرویس اعتبارسنجی، همانند کامپوننت هدر، واکنش نشان داد.
برای پیاده سازی آن و همچنین کپسوله سازی این عملیات تکراری، دایرکتیو جدیدی را در مسیر src\app\shared\directives\is-visible-for-auth-user.directive.ts ایجاد می‌کنیم:
import { Directive, ElementRef, Input, OnDestroy, OnInit } from "@angular/core";
import { Subscription } from "rxjs/Subscription";

import { AuthService } from "../../core/services/auth.service";

@Directive({
  selector: "[isVisibleForAuthUser]"
})
export class IsVisibleForAuthUserDirective implements OnInit, OnDestroy {

  private subscription: Subscription;

  @Input() isVisibleForRoles: string[];

  constructor(private elem: ElementRef, private authService: AuthService) { }

  ngOnDestroy(): void {
    this.subscription.unsubscribe();
  }

  ngOnInit(): void {
    this.subscription = this.authService.authStatus$.subscribe(status => this.changeVisibility(status));
    this.changeVisibility(this.authService.isAuthUserLoggedIn());
  }

  private changeVisibility(status: boolean) {
    const isInRoles = !this.isVisibleForRoles ? true : this.authService.isAuthUserInRoles(this.isVisibleForRoles);
    this.elem.nativeElement.style.display = isInRoles && status ? "" : "none";
  }
}
در اینجا علاوه بر بررسی isAuthUserLoggedIn و isAuthUserInRoles، نسبت به تغییرات this.authService.authStatus نیز واکنش نشان داده می‌شود.

سپس تعریف آن‌را به قسمت‌های declarations و exports مربوط به SharedModule اضافه می‌کنیم:
import { IsVisibleForAuthUserDirective } from "./directives/is-visible-for-auth-user.directive";

@NgModule({
  declarations: [
    IsVisibleForAuthUserDirective
  ],
  exports: [
    IsVisibleForAuthUserDirective
  ]
})
export class SharedModule {}

اکنون ماژول Dashboard برای استفاده‌ی از این امکانات تنها کافی است SharedModule را دریافت کند (یا هر ماژول دیگری نیز به همین ترتیب است):
import { SharedModule } from "../shared/shared.module";

@NgModule({
  imports: [
    SharedModule
  ]
})
export class DashboardModule { }

پس از آن برای مخفی سازی یک المان از دید کاربران وارد نشده‌ی به سیستم، فقط کافی است دایرکتیو isVisibleForAuthUser را به المان اعمال کنیم:
<div class="alert alert-info" isVisibleForAuthUser>
      Is-Visible-For-AuthUser
</div>
و یا اگر نیاز به اعمال نقش‌ها نیز وجود داشت می‌توان از خاصیت isVisibleForRoles آن استفاده کرد:
<div class="alert alert-success" isVisibleForAuthUser [isVisibleForRoles]="['Admin','User']">
      Is-Visible-For-Roles = ['Admin','User']
</div>

خلاصه‌ی این تغییرات به کدهای نهایی این سری اعمال شده‌اند.