مطالب
یکپارچه سازی Angular CLI و ASP.NET Core در VS 2017
در این مطلب مثالی را در مورد نحوه‌ی تنظیمات یک پروژه‌ی خالی ASP.NET Core، جهت استفاده‌ی از یک پروژه‌ی Angular CLI قرار گرفته‌ی در پوشه‌ی آن‌را بررسی خواهیم کرد.

پیشنیازها

 - مطالعه‌ی سری کار با Angular CLI خصوصا قسمت نصب و قسمت ساخت برنامه‌های آن، پیش از مطالعه‌ی این مطلب ضروری است.
 - همچنین فرض بر این است که سری ASP.NET Core را نیز یکبار مرور کرده‌اید و با نحوه‌ی برپایی یک برنامه‌ی MVC آن و ارائه‌ی فایل‌های استاتیک توسط یک پروژه‌ی ASP.NET Core آشنایی دارید.


ایجاد یک پروژه‌ی جدید ASP.NET Core در VS 2017

در ابتدا یک پروژه‌ی خالی ASP.NET Core را در VS 2017 ایجاد خواهیم کرد. برای این منظور:
 - ابتدا از طریق منوی File -> New -> Project (Ctrl+Shift+N) گزینه‌ی ایجاد یک ASP.NET Core Web application را انتخاب کنید.
 - در صفحه‌ی بعدی آن هم گزینه‌ی «empty template» را انتخاب نمائید.


تنظیمات یک برنامه‌ی ASP.NET Core خالی برای اجرای یک برنامه‌ی Angular CLI

برای اجرای یک برنامه‌ی مبتنی بر Angular CLI، نیاز است بر روی فایل csproj برنامه‌ی ASP.NET Core کلیک راست کرده و گزینه‌ی Edit آن‌را انتخاب کنید.
سپس محتوای این فایل را به نحو ذیل تکمیل نمائید:

الف) درخواست عدم کامپایل فایل‌های TypeScript
  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
  </PropertyGroup>
چون نحوه‌ی کامپایل پروژه‌های Angular CLI صرفا مبتنی بر کامپایل مستقیم فایل‌های TypeScript آن نیست و در اینجا از یک گردش کاری توکار مبتنی بر webpack، به صورت خودکار استفاده می‌کند، کامپایل فایل‌های TypeScript توسط ویژوال استودیو، مفید نبوده و صرفا سبب دریافت گزارش‌های خطای بیشماری به همراه کند کردن پروسه‌ی Build آن خواهد شد. بنابراین با افزودن تنظیم TypeScriptCompileBlocked به true، از VS 2017 خواهیم خواست تا در این زمینه دخالت نکند.

ب) مشخص کردن پوشه‌هایی که باید الحاق و یا حذف شوند
  <ItemGroup>
    <Folder Include="Controllers\" />
    <Folder Include="wwwroot\" />
  </ItemGroup>
 
  <ItemGroup>
    <Compile Remove="node_modules\**" />
    <Content Remove="node_modules\**" />
    <EmbeddedResource Remove="node_modules\**" />
    <None Remove="node_modules\**" />
  </ItemGroup>
 
  <ItemGroup>
    <Compile Remove="src\**" />
    <Content Remove="src\**" />
    <EmbeddedResource Remove="src\**" />    
  </ItemGroup>
در اینجا پوشه‌های کنترلرها و wwwroot به پروژه الحاق شده‌اند. پوشه‌ی wwwroot جایی است که فایل‌هایی خروجی را Angular CLI ارائه خواهد کرد.
سپس دو پوشه‌ی node_modules و src واقع در ریشه‌ی پروژه را نیز به طور کامل از سیستم ساخت و توزیع VS 2017 حذف کرده‌ایم. پوشه‌ی node_modules وابستگی‌های Angular را به همراه دارد و src همان پوشه‌ی برنامه‌ی Angular ما خواهد بود.

ج) افزودن وابستگی‌های سمت سرور مورد نیاز
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.1" />
  </ItemGroup>
 
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="1.0.0" />
  </ItemGroup>
 
  <ItemGroup>
    <!-- extends watching group to include *.js files -->
    <Watch Include="**\*.js" Exclude="node_modules\**\*;**\*.js.map;obj\**\*;bin\**\*" />
  </ItemGroup>
برای اجرای یک برنامه‌ی تک صفحه‌ای وب Angular، صرفا به وابستگی MVC و StaticFiles آن نیاز است.
در اینجا Watcher.Tools هم به همراه تنظیمات آن اضافه شده‌اند که در ادامه‌ی بحث به آن اشاره خواهد شد.


افزودن یک کنترلر Web API جدید

با توجه به اینکه دیگر در اینجا قرار نیست با فایل‌های cshtml و razor کار کنیم، کنترلرهای ما نیز از نوع Web API خواهند بود. البته در ASP.NET Core، کنترلرهای معمولی آن، توانایی ارائه‌ی Web API و همچنین فایل‌های Razor را دارند و از این لحاظ تفاوتی بین این دو نیست و یکپارچگی کاملی صورت گرفته‌است.
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc;
 
namespace ASPNETCoreIntegrationWithAngularCLI.Controllers
{
  [Route("api/[controller]")]
  public class ValuesController : Controller
  {
    // GET: api/values
    [HttpGet]
    [ResponseCache(NoStore = true, Location = ResponseCacheLocation.None)]
    public IEnumerable<string> Get()
    {
      return new string[] { "Hello", "DNT" };
    }
  }
}
در اینجا کدهای یک کنترلر نمونه را جهت بازگشت یک خروجی JSON ساده مشاهده می‌کنید که در ادامه، در برنامه‌ی Angular CLI تهیه شده از آن استفاده خواهیم کرد.


تنظیمات فایل آغازین یک برنامه‌ی ASP.NET Core جهت ارائه‌ی برنامه‌های Angular

در ادامه به فایل Startup.cs برنامه‌ی خالی جاری، مراجعه کرده و آن‌را به نحو ذیل تغییر دهید:
using System;
using System.IO;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
 
namespace ASPNETCoreIntegrationWithAngularCLI
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc();
        }
 
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole();
 
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
 
            app.Use(async (context, next) => {
                await next();
                if (context.Response.StatusCode == 404 &&
                    !Path.HasExtension(context.Request.Path.Value) &&
                    !context.Request.Path.Value.StartsWith("/api/", StringComparison.OrdinalIgnoreCase))
                {
                    context.Request.Path = "/index.html";
                    await next();
                }
            });
 
            app.UseMvcWithDefaultRoute();
            app.UseDefaultFiles();
            app.UseStaticFiles();
        }
    }
}
در اینجا برای ارائه‌ی کنترلر Web API، نیاز به ثبت سرویس‌های MVC است. همچنین ارائه‌ی فایل‌های پیش فرض و فایل‌های استاتیک (همان پوشه‌ی wwwroot برنامه) نیز فعال شده‌اند.
در قسمت app.Use آن، تنظیمات URL Rewriting مورد نیاز جهت کار با مسیریابی برنامه‌های Angular را مشاهده می‌کنید. برای نمونه اگر کاربری در ابتدای کار آدرس /products را درخواست کند، این درخواست به سمت سرور ارسال می‌شود و چون چنین صفحه‌ای در سمت سرور وجود ندارد، خطای 404 بازگشت داده می‌شود و کار به پردازش برنامه‌ی Angular نخواهد رسید. اینجا است که تنظیم میان‌افزار فوق، کار مدیریت خروجی‌های 404 را بر عهده گرفته و کاربر را به فایل index.html برنامه‌ی تک صفحه‌ای وب، هدایت می‌کند. به علاوه در اینجا اگر درخواست وارد شده، دارای پسوند باشد (یک فایل باشد) و یا با api/ شروع شود (اشاره کننده‌ی به کنترلرهای Web API برنامه)، از این پردازش و هدایت به صفحه‌ی index.html معاف خواهد شد.


ایجاد ساختار اولیه‌ی برنامه‌ی Angular CLI در داخل پروژه‌ی جاری

اکنون از طریق خط فرمان به پوشه‌ی ریشه‌ی برنامه‌ی ASP.NET Core‌، جائیکه فایل Startup.cs قرار دارد، وارد شده و دستور ذیل را اجرا کنید:
 >ng new ClientApp --routing --skip-install --skip-git --skip-commit
به این ترتیب پوشه‌ی جدید ClientApp، در داخل پوشه‌ی برنامه اضافه خواهد شد که در آن تنظیمات اولیه‌ی مسیریابی Angular نیز انجام شده‌است؛ از دریافت وابستگی‌های npm آن صرفنظر شده و همچنین کار تنظیمات git آن نیز صورت نگرفته‌است (تا از تنظیمات git پروژه‌ی اصلی استفاده شود).
پس از تولید ساختار برنامه‌ی Angular CLI، به پوشه‌ی آن وارد شده و تمام فایل‌های آن را Cut کنید. سپس به پوشه‌ی ریشه‌ی برنامه‌ی ASP.NET Core جاری، وارد شده و این فایل‌ها را در آنجا paste نمائید. به این ترتیب به حداکثر سازگاری ساختار پروژه‌های Angular CLI و VS 2017 خواهیم رسید. زیرا اکثر فایل‌های تنظیمات آن‌را می‌شناسد و قابلیت پردازش آن‌ها را دارد.
پس از این cut/paste، پوشه‌ی خالی ClientApp را نیز حذف کنید.


تنظیم محل خروجی نهایی Angular CLI به پوشه‌ی wwwroot

برای اینکه سیستم Build پروژه‌ی Angular CLI جاری، خروجی خود را در پوشه‌ی wwwroot قرار دهد، تنها کافی است فایل .angular-cli.json را گشوده و outDir آن‌را به wwwroot تنظیم کنیم:
"apps": [
    {
      "root": "src",
      "outDir": "wwwroot",
به این ترتیب پس از هر بار build آن، فایل‌های index.html و تمام فایل‌های js نهایی، در پوشه‌ی wwwroot که در فایل Startup.cs‌، کار عمومی کردن آن انجام شد، تولید می‌شوند.


فراخوانی کنترلر Web API برنامه در برنامه‌ی Angular CLI

در ادامه صرفا جهت آزمایش برنامه، فایل src\app\app.component.ts را گشوده و به نحو ذیل تکمیل کنید:
import { Component, OnInit } from '@angular/core';
import { Http } from '@angular/http'; 
 
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {
  constructor(private _httpService: Http) { }
 
  apiValues: string[] = [];
 
  ngOnInit() {
    this._httpService.get('/api/values').subscribe(values => {
      this.apiValues = values.json() as string[];
    });
  }
}
در اینجا خروجی JSON کنترلر Web API برنامه دریافت شده و به آرایه‌ی apiValues انتساب داده می‌شود.

سپس این آرایه را در فایل قالب این کامپوننت (src\app\app.component.html) استفاده خواهیم کرد:
<h1>Application says:</h1>
<ul *ngFor="let value of apiValues">
  <li>{{value}}</li>
</ul>
<router-outlet></router-outlet>
در اینجا یک حلقه ایجاد شده و عناصر آرایه‌ی apiValues به صورت یک لیست نمایش داده می‌شوند.


نصب وابستگی‌های برنامه‌ی Angular CLI

در ابتدای ایجاد پوشه‌ی ClientApp، از پرچم skip-install استفاده شد، تا صرفا ساختار پروژه، جهت cut/paste آن با سرعت هر چه تمام‌تر، ایجاد شود. اکنون برای نصب وابستگی‌های آن یا می‌توان در solution explorer به گره dependencies مراجعه کرده و npm را انتخاب کرد. در ادامه با کلیک راست بر روی آن، گزینه‌ی restore packages ظاهر می‌شود. و یا می‌توان به روش متداول این نوع پروژه‌ها، از طریق خط فرمان به پوشه‌ی ریشه‌ی پروژه وارد شد و دستور npm install را صادر کرد. بهتر است اینکار را از طریق خط فرمان انجام دهید تا مطمئن شوید که از آخرین نگارش‌های این ابزار که بر روی سیستم نصب شده‌است، استفاده می‌کنید.


روش اول اجرای برنامه‌های مبتنی بر ASP.NET Core و Angular CLI

تا اینجا اگر برنامه را از طریق VS 2017 اجرا کنید، خروجی را مشاهده نخواهید کرد. چون هنوز فایل index.html آن تولید نشده‌است.
بنابراین روش اول اجرای این نوع برنامه‌ها، شامل مراحل ذیل است:
الف) ساخت پروژه‌ی Angular CLI در حالت watch
 > ng build --watch
برای اجرای آن از طریق خط فرمان، به پوشه‌ی ریشه‌ی پروژه وارد شده و دستور فوق را وارد کنید. به این ترتیب کار build پروژه انجام شده و همچنین فایل‌های نهایی آن در پوشه‌ی wwwroot قرار می‌گیرند. به علاوه چون از پرچم watch استفاده شده‌است، با هر تغییری در پوشه‌ی src برنامه، این فایل‌ها به صورت خودکار به روز رسانی می‌شوند. بنابراین این پنجره‌ی خط فرمان را باید باز نگه داشت تا watcher آن بتواند کارش را به صورت مداوم انجام دهد.

ب) اجرای برنامه از طریق ویژوال استودیو
اکنون که کار ایجاد محتوای پوشه‌ی wwwroot برنامه انجام شده‌است، می‌توان برنامه را از طریق VS 2017 به روش متداولی اجرا کرد:


یک نکته: می‌توان قسمت الف را تبدیل به یک Post Build Event هم کرد. برای این منظور باید فایل csproj را به نحو ذیل تکمیل کرد:
<Target Name="AngularBuild" AfterTargets="Build">
    <Exec Command="ng build" />
</Target>
به این ترتیب با هربار Build پروژه در VS 2017، کار تولید مجدد محتوای پوشه‌ی wwwroot نیز انجام خواهد شد.
تنها مشکل روش Post Build Event، کند بودن آن است. زمانیکه از روش ng build --watch به صورت مستقل استفاده می‌شود، برای بار اول اجرا، اندکی زمان خواهد برد؛ اما اعمال تغییرات بعدی به آن بسیار سریع هستند. چون صرفا نیاز دارد این تغییرات اندک و تدریجی را کامپایل کند و نه کامپایل کل پروژه را از ابتدا.


روش دوم اجرای برنامه‌های مبتنی بر ASP.NET Core و Angular CLI

روش دومی که در اینجا بررسی خواهد شد، مستقل است از قسمت «ب» روش اول که توضیح داده شد. برنامه‌های NET Core. نیز به همراه CLI خاص خودشان هستند و نیازی نیست تا حتما از VS 2017 برای اجرای آن‌ها استفاده کرد. به همین جهت وابستگی Microsoft.DotNet.Watcher.Tools را نیز در ابتدای کار به وابستگی‌های برنامه اضافه کردیم.

الف) در ادامه، VS 2017 را به طور کامل ببندید؛ چون نیازی به آن نیست. سپس دستور ذیل را در خط فرمان، در ریشه‌ی پروژه‌، صادر کنید:
> dotnet watch run
این دستور پروژه‌ی ASP.NET Core را کامپایل کرده و بر روی پورت 5000 ارائه می‌دهد:
>dotnet watch run
[90mwatch : [39mStarted
Hosting environment: Production
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
به علاوه پارامتر watch آن سبب خواهد شد تا هر تغییری که در کدهای پروژه‌ی ASP.NET Core صورت گیرند، بلافاصله کامپایل شده و قابل استفاده شوند.

ب) در اینجا چون برنامه بر روی پورت 5000 ارائه شده‌است، بهتر است دستور ng serve -o را صادر کرد تا بتوان به نحو ساده‌تری از سرور وب ASP.NET Core استفاده نمود. در این حالت برنامه‌ی Angular CLI بر روی پورت 4200 ارائه شده و بلافاصله در مرورگر نیز نمایش داده می‌شود.
مشکل! سرور وب ما بر روی پورت 5000 است و سرور آزمایشی Angular CLI بر روی پورت 4200. اکنون برنامه‌ی Angular ما، یک چنین درخواست‌هایی را به سمت سرور، جهت دریافت اطلاعات ارسال می‌کند: localhost:4200/api
برای رفع این مشکل می‌توان فایلی را به نام proxy.config.json با محتویات ذیل ایجاد کرد:
{
  "/api": {
    "target": "http://localhost:5000",
    "secure": false
  }
}
سپس دستور ng server صادر شده، اندکی متفاوت خواهد شد:
 >ng serve --proxy-config proxy.config.json -o
در اینجا به ng serve اعلام کرده‌ایم که تمامی درخواست‌های ارسالی به مسیر api/  (و یا همان localhost:4200/api جاری) را به سرور وب ASP.NET Core، بر روی پورت 5000 ارسال کن و نتیجه را در همینجا بازگشت بده. به این ترتیب مشکل عدم دسترسی به سرور وب، جهت تامین اطلاعات برطرف خواهد شد.
مزیت این روش، به روز رسانی خودکار مرورگر با انجام هر تغییری در کدهای قسمت Angular برنامه است.

نکته 1: بدیهی است می‌توان قسمت «ب» روش دوم را با قسمت «الف» روش اول نیز جایگزین کرد (ساخت پروژه‌ی Angular CLI در حالت watch). اینبار گشودن مرورگر بر روی پورت 5000 (و یا آدرس http://localhost:5000) را باید به صورت دستی انجام دهید. همچنین هربار تغییر در کدهای Angular، سبب refresh خودکار مرورگر نیز نمی‌شود که آن‌را نیز باید خودتان به صورت دستی انجام دهید (کلیک بر روی دکمه‌ی refresh پس از هر بار پایان کار ng build).
نکته 2: می‌توان قسمت «الف» روش دوم را حذف کرد (حذف dotnet run در حالت watch). یعنی می‌خواهیم هنوز هم ویژوال استودیو کار آغاز IIS Express را انجام دهد. به علاوه می‌خواهیم برنامه را توسط ng serve مشاهده کنیم (با همان پارامترهای قسمت «ب» روش دوم). در این حالت تنها موردی را که باید تغییر دهید، پورتی است که برای IIS Express تنظیم شده‌است. عدد این پورت را می‌توان در فایل Properties\launchSettings.json مشاهده کرد و سپس به تنظیمات فایل proxy.config.json اعمال نمود.


کدهای کامل این مطلب را از اینجا می‌توانید دریافت کنید: ASPNETCoreIntegrationWithAngularCLI.zip
به همراه این کدها تعدادی فایل bat نیز وجود دارند که جهت ساده سازی عملیات یاد شده‌ی در این مطلب، می‌توان از آن‌ها استفاده کرد:
 - فایل restore.bat کار بازیابی و نصب وابستگی‌های پروژه‌ی دات نتی و همچنین Angular CLI را انجام می‌دهد.
 - دو فایل ng-build-dev.bat و ng-build-prod.bat بیانگر قسمت «الف» روش اول هستند. فایل dev مخصوص حالت توسعه است و فایل prod مخصوص ارائه‌ی نهایی.
 - دو فایل dotnet_run.bat و ng-serve-proxy.bat خلاصه کننده‌ی قسمت‌های «الف» و «ب» روش دوم هستند.
نظرات مطالب
بررسی روش ارتقاء به NET Core 1.1.
پس از به‌روزرسانی و توزیع در IIS با خطای :
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.AspNetCore.Hosting, Version=1.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
   at Sample1.Web.Program.Main(String[] args)
مواجه شدم.

و جهت رفع مشکل :


اما خطا همچنان پابرجاست.

پکیج هایی که باید نصب باشد :


و فایل Project.json:


{
  "dependencies": {
    "Sample1.DataLayer": "1.0.0-*",
    "Sample1.PrsLayer.SysB.UserMg": "1.0.0-*",
    "Sample1.PrsLayer.SysBase": "1.0.0-*",
    "Sample1.PrsLayer.SysS.Setting": "1.0.0-*",
    "Sample1.SrvLayer.SysB.UserMg": "1.0.0-*",
    "Sample1.SrvLayer.SysBase": "1.0.0-*",
    "Sample1.SrvLayer.SysS.Setting": "1.0.0-*",
    "CoreCompat.System.Drawing": "1.0.0-beta006",
    "Sample1.ExternalResources": "1.0.0-*",
    "Sample1.SrvLayer.SysA.BookMg": "1.0.0-*",
    "Sample1.SrvLayer.UploadService": "1.0.0-*",
    "Sample1.PrsLayer.SysA.BookMg": "1.0.0-*",
    "Sample1.IocConfig": "1.0.0-*",
    "Sample1.MapperConfig": "1.0.0-*",
    "Sample1.PrsLayer.SysU.UiMg": "1.0.0-*",
    "Sample1.SrvLayer.SysU.UiMg": "1.0.0-*",
    "Sample1.PrsLayer.SysI.SubscribeNewsletter": "1.0.0-*",
    "Sample1.SrvLayer.SysI.SubscribeNewsletter": "1.0.0-*",
    "Wangkanai.Detection": "1.0.0-*",
    "Wangkanai.Detection.Abstractions": "1.0.0-*",
    "Wangkanai.Detection.Device": "1.0.0-*",
    "Wangkanai.Detection.Engine": "1.0.0-*",
    "Wangkanai.Detection.Platform": "1.0.0-*",
    "Wangkanai.Detection.Browser": "1.0.0-*",
    "StructureMap.Microsoft.DependencyInjection": "1.2.0",
    "CacheManager.Core": "0.9.1",
    "CacheManager.Microsoft.Extensions.Caching.Memory": "0.9.1",
    "CacheManager.Serialization.Json": "0.9.1",
    "Newtonsoft.Json": "9.0.2-beta1",
    "Microsoft.AspNetCore.SpaServices": "1.0.0-beta-000019",
    "AutoMapper": "5.1.1",
    "EFSecondLevelCache.Core": "1.0.1",
    "Microsoft.AspNetCore.Diagnostics.Elm": "0.2.0",
    "Microsoft.AspNetCore.Mvc": "1.1.0",
    "Microsoft.AspNetCore.Mvc.Localization": "1.1.0",
    "Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
    "Microsoft.AspNetCore.Session": "1.1.0",
    "Microsoft.AspNetCore.StaticFiles": "1.1.0",
    "Microsoft.Extensions.Configuration.FileExtensions": "1.1.0",
    "Microsoft.Extensions.Configuration.Json": "1.1.0",
    "Microsoft.Extensions.FileProviders.Embedded": "1.1.0",
    "Microsoft.Extensions.Logging.Console": "1.1.0",
    "Microsoft.Extensions.Logging.Debug": "1.1.0",
    "Microsoft.Net.Http.Headers": "1.1.0",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0",
    "System.Globalization": "4.3.0",
    "System.IO": "4.3.0",
    "System.Linq": "4.3.0",
    "System.Reflection": "4.3.0",
    "System.Runtime": "4.3.0",
    "System.Runtime.Extensions": "4.3.0",
    "System.Runtime.WindowsRuntime": "4.3.0",
    "System.Text.RegularExpressions": "4.3.0",
    "System.Threading.Tasks": "4.3.0",
    "Microsoft.VisualStudio.Web.CodeGenerators.Mvc": {
      "version": "1.1.0-preview4-final",
      "type": "build"
    },
    "Elmah.Io.AspNetCore": "1.0.1-pre-24",
    "Elmah.Io.Extensions.Logging": "1.0.17-pre",
    "Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
      "version": "1.1.0-preview4-final",
      "type": "build"
    }
  },
  "tools": {
    "Microsoft.EntityFrameworkCore.Tools.DotNet": {
      "version": "1.1.0-preview4-final",
      "imports": [
        "portable-net45+win8"
      ]
    },
    "Microsoft.Extensions.SecretManager.Tools": "1.1.0-preview4-final",
    "Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
      "version": "1.1.0-preview4-final",
      "imports": [
        "portable-net45+win8"
      ]
    },
    "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.1.0-preview4-final"
  },
  "frameworks": {
    "netcoreapp1.1": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "type": "platform",
          "version": "1.1.0"
        }
      },
      "imports": [
        "dotnet5.6",
        "portable-net45+win8"
      ]
    }
  },
  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true,
    "embed": "Views/**/*.cshtml,Areas/**/Views/**/*.cshtml",
    "define": [ "DEBUG" ]
  },
  "runtimeOptions": {
    "configProperties": {
      "System.GC.Server": true
    }
  },
  "publishOptions": {
    "include": [
      "wwwroot",
      "Views",
      "Areas/**/Views",
      "appsettings.json",
      "web.config"
    ]
  },
  "configurations": {
    "Release": {
      "buildOptions": {
        "optimize": true,
        "platform": "anycpu"
      }
    }
  },
  "scripts": {
    "precompile": [
      //"dotnet bundle"
    ],
    "prepublish": [
      //"bower install"
    ],
    "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
  }
}
نظرات مطالب
PersianDatePicker یک DatePicker شمسی به زبان JavaScript که از تاریخ سرور استفاده می‌کند

مشکل از این مثال یا این تقویم یا هیچکدوم نیست. مشکل از اینجا است که در حین Post، سیستم بایندینگ MVC میاد نگاه می‌کنه چه خواصی رو در کلاس PostViewModel داری (اسم این کلاس مهم نیست). زمانی که در اون خاصیت AddDate رو پیدا نکرد، خوب ... همه چیز تموم میشه. خاصیتی رو پیدا نکرده که اطلاعات دریافتی رو بهش بایند کنه، بنابراین خاصیت‌های شیء تو در تویی که درست کردی، خالی باقی می‌مونه. این نوع View مدل بیشتر برای حالت Get استفاده میشه نه حالت Post. برای حالت Get ایی که قراره در یک صفحه چند منبع داده رو به قسمت‌های مختلف اون بایند کنی.

البته MVC می‌تونه به یک شیء تو در تو هم اطلاعات رو در حالت Post بایند کنه. اینطوری model=> model.Post.AddDate (دو تا دات داره نه یکی). خودت باید دستی این چند سطح رو مشخص کنی (در متدهای For دار).

نظرات اشتراک‌ها
چگونه بفهمیم فایل انتخابی واقعا عکسه یا نه ؟
برای کد زیر یک هشدار صادر میشه. 
Image.FromStream(file.OpenReadStream());
متن هشدار: 
This call site is reachable on all platforms. 'Image.FromStream(Stream)' is only supported on: 'windows'
در جستجویی که انجام دادم پیشنهاد مایکروسافت استفاده از ImageSharp ، SkiaSharp ، Microsoft.Maui.Graphics  به جای System.Drawing برای حالت cross platform هست. 
اشتراک‌ها
آشنایی با CORS یا Cross-origin resource sharing
CORS کوتاه‌شده‌ی عبارت Cross-origin resource sharing است. محل کاربرد CORS در مرورگرهای مدرن و برای بررسی اجازه‌ی دسترسی از راه دور به منابع و سرویس‌های تحت وب است. برای مثال در حالت عادی امکان استفاده از فایل‌های فونت از روی یک سرور دیگر وجود ندارد یا امکان ارسال یک درخواست AJAX از روی دامنه‌ای غیر از دامنه‌ی فعلی ناممکن است.CORS ابزاری است که روشی برای حذف این محدودیت در اختیار برنامه‌نویسان قرار می‌دهد.
آشنایی با CORS یا Cross-origin resource sharing
نظرات مطالب
انجام کارهای زمانبندی شده در برنامه‌های ASP.NET توسط DNT Scheduler
سلام و خسته نباشید؛  زمانی که در ترد ایجاد شده ، خطایی رخ می‌دهد در هاست‌های اشتراکی app pool ظاهرا 20 تا40 دقیقه طول می‌کشد تا این ترد را ببندد و این باعث down  شدن سیستم طی 20 تا 40 دقیقه می‌شود باید چکار کنیم که در try cash خودمان بتوانیم ترد موجود را بندیم و در کل بر این مورد مدیریت کامل داشته باشیم ؟
خطای در یافتی من بیشتر از 100 باز در یک روز در یکی از وظیفه‌های تعریف شده :
a task was canceled
نکته : فقط روی هاست این مشکل به وجود می‌اید و در لوکال مشکلی ندارم حتی بالای 2 ساعت هم چک شده بدون خطا .
نکته 2 : دات نت فریورک سرور 4.5 هست ولی من با 4.6 برنامه را در لوکال اجرا می‌کنم.
نظرات مطالب
کمی درباره دستورات using
یک نکته اضافه در مورد فایل class.cs در ابتدای مقاله.
مدتی هست که من هر موقع کلاسی به خصوص برای بخش مدل‌ها ایجاد میکنم مرتب هر کلاسی را باید یک public را بنویسم چون به طور پیش فرض کلاس هایی که دات نت ایجاد میکند private هستند.
برای حل این مشکل در فایل class عبارت public را قبل از کلمه class به آن اضافه کنید:

class $safeitemrootname$
    {
    }

========= To

public class $safeitemrootname$
    {
    }

احتمالا این معضل خیلی‌ها هست چون نوشتن تعداد کلاس‌های عمومی بیشتر از خصوصی است
نظرات مطالب
Embed کردن SQL Server Express 2008 در یک برنامه

بهترین کار برای نصب خودکار فایلهای مورد نیاز جهت اجرای برنامه‌های مبتنی بر دات نت ، استفاده از نرم افزارهای ساخت Setup می‌باشد. از قبیل

1- InstallShield

2- InstallAware

3- Advanced Installer

مورد اول ، از قدیمی‌ترین نرم افزارها و  حرفه ای می‌باشد. ولی متاسفانه در تهیه نسخه به روز آن کمی دچار مشکل خواهید شد.

مورد دوم ادعای مقایسه با اینستال شیلد را دارد .از عیوبی که من در استفاده از این نرم افزار دیدم میتوان به حجم بالای نرم افزار اصلی اشاره کرد که بیش از دو گیگابایت است و هر دفعه نسخه جدید اومد شما باید مجدداٌ این حجم را دانلود کنید.

مورد سوم که بهترین گزینه نیز می‌باشد ، بسیار خوش دست و سبک می‌باشد. و به راحتی تمام موارد مورد نیاز جهت اجرای برنامه‌های شما را نصب می‌نماید.

نظرات مطالب
سایت‌های مهمی که از ASP.NET MVC استفاده می‌کنند
بعید می‌دونم. علتش به توسعه پذیری SharePoint بر می‌گرده که بر اساس معماری وب فرم‌ها از ابتدا طراحی شده. اگر بروند سراغ MVC تمام افزونه‌های قبلی از کار می‌افته یا به شدت مشکل پیدا می‌کنند. ضمن اینکه SharePoint پلتفرم واقعا عظیمی است. خیلی هزینه‌بر است تبدیل آن.
برای مثال شاید همین سوال در مورد IE هم باشد. چرا IE رو با دات نت نمی‌نویسند؟ علتش این است که بعد از این همه سال میلیون‌ها دلار خرج code base آن شده. دور ریختن و دل کندن از آن واقعا سخت است.
مطالب
طول و عرض WPF

شاید بد نباشد این فناوری را از دیدگاه مدت زمانی که باید به آن تسلط پیدا کرد، بررسی نمود:



بله، مشکل در طول و عرض WPF بوده و مدت زمان یادگیری و تسلط کامل به آن، از فناوری‌های قبلی مطرح در دات نت فریم ورک بسیار بیشتر می‌باشد. (تعداد کلاس‌های آن تقریبا مساوی مجموع تعداد کلاس‌های نگارش 2 WinForms و ASP.Net است!)

در مقایسه با WinForms و ASP.Net هم موارد زیر قابل تامل است:
ASP.NET 2.0 شامل 1098 public types و 1551 classes است.
WinForms 2.0 شامل 777 public types و 1500 classes می‌باشد.
سیلورلایت 2 را هم که در تصویر مشاهده می‌کنید. شامل 376 public types و 335 classes است.

ماخذ