- در مورد تنظیمات سمت سرور AngularJS 2.0 در ASP.NET Core 1.0، در قسمت «معرفی بسته‌ی نیوگت Microsoft.AspNetCore.SpaServices» بحث شده‌است.
- اما ... Gulp جاوا اسکریپتی اساسا وابستگی خاصی به فناوری‌های سمت سرور ندارد. در اینجا فقط نحوه‌ی مسیردهی این پوشه‌ها مهم هستند (و Task runner آن فقط به این مسایل دقت می‌کند):
در اینجا app/. به این معنا است که محل واقع شدن فایل تنظیمات gulp و همچنین فایل systemjs.config.js، یک سطح بالاتر هستند از پوشه‌ی app (جایی که قرار است فایل‌های اصلی از آن دریافت شوند) و همچنین پوشه‌ی wwwroot ذکر شده (جایی که قرار است فایل‌های نهایی کپی شوند):

- مدام باید developer tools مرورگر را باز نگه دارید و خطاهای اصلی را در آنجا مشاهده کنید (همیشه الزامی است و مهم).
- ممکن است هنوز تعدادی از فایل‌های ts. شما کامپایل نشده‌اند. یکبار از منوی Build گزینه‌ی Clean solution را انتخاب کنید و بعد هم ReBuild از نو انجام شود. در این‌حالت بررسی کنید که آیا تمام فایل‌های js تولید شده‌اند یا خیر (زیاد اتفاق می‌افتد).
- بهتر است از گوگل‌کروم استفاده کنید، چون developer tools آن این امکان را دارد که فایل‌ها را کش نکند که برای حالت توسعه بسیار مفید است (فایلی را تغییر می‌دهید، کامپایل هم شده‌است، اما مرورگر نمونه‌ی قدیمی کش شده را دریافت می‌کند و نه فایل جدید را (این هم زیاد اتفاق می‌افتد)):
 

- همچنین سه فایل آزمایش شده‌ی main.ts ، app.routes.ts و app.component.ts را با نمونه‌های خودتان تطابق دهید.

- فایل‌های بوت استرپ هم در پروژه‌ی اصلی هست دیگه. فایل‌های مشترکی که قرار هست تمام افزونه‌ها ازش استفاده کنند. به علاوه هم سیستم bundling (به صورت توکار) و هم سیستم فوق، اطلاعات رو کش می‌کنند(متد cacheIt). یعنی اینطور نیست که با هر درخواست از View، تمام اسکریپت‌ها و تمام CSSها دوباره خونده میشن.

- مهم این هست که برنامه رو اجرا کنید، این سیستم یکپارچه هست. همینقدر که اسکریپت‌ها یا CSSها در HTML نهایی تولیدی وجود داشته باشند، برنامه کار می‌کنه. اینجا دید سیستمی باید داشته باشید. این یک سیستم هست که از همکاری اجزای مختلف اون یک هدف واحد حاصل میشه.

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

روش‌های زیادی برای دسته بندی، فشرده و یکی سازی فایل‌های CSS و JS هست؛ منجمله:
- بهینه سازی فایلهای js و css در برنامه‌های ASP.NET با استفاده از Combres - قسمت اول   
-  فشرده سازی فایل‌های CSS و JavaScript بصورت خودکار توسط MS Ajax Minifier  
- Adding Bundling and Minification to Web Forms
- Building a basic Web Forms application using Visual Studio 2013 
- Bundling and Minification in ASP.Net 4.5  

سؤال و هدف اصلی بحث جاری این است: «آیا می‌شود دسترسی به فایل‌های قرار گرفته در این پوشه عمومی را کنترل کرد؟ به نحوی که فقط کاربران عضو سایت پس از اعتبارسنجی بتوانند آن‌ها را دریافت کنند؟»
یعنی تمام اینکارها انجام شد تا بتوان دریافت فایل‌های استاتیک را تحت کنترل کامل برنامه و اعتبارسنجی آن قرار داد. اگر نیازی نیست، خوب، مباحث آن‌را پیاده سازی نکنید. همچنین مانند IgnoreRoute نوشته شده در انتهای بحث برای پوشه اسکریپت‌ها یا CSSها، پوشه‌ی مدنظر را از سیستم مسیریابی خارج کنید.

- راه اول: زمانیکه View اصلی در برگیرنده آن نمایش داده می‌شود، کلیه فایل‌های متناظر را هم الحاق کنید تا به صورت خودکار در جزئی از صفحه آن، که بعدا به روز خواهد شد، نیز اعمال شود.
- راه دوم: اصلا از RenderSection در یک partial view که قرار است Ajax ایی بارگذاری شود، استفاده نکنید. معمولی این‌ها را الصاق یا تعریف کنید. مثل تعاریف یک HTML ساده. یک نفر هم اینجا براش HtmlHelper نوشته ولی نکته اصلی یکی است؛ الصاق و تعریف معمولی فایل‌های مورد نیاز.
- همچنین خود jQuery امکان بارگذاری اسکریپت‌ها را به صورت پویا دارد. زمانیکه complete عملیات Ajax ایی رخ‌داد، متد getScript عنوان شده را فراخوانی کنید. برای CSS هم به صورت زیر عمل کنید:

- برای فایل‌های جاوا اسکریپت توصیه من این است:
الف) اگر از Web forms استفاده می‌کنید: استفاده از Script manager (^ و ^)
ب) اگر از MVC استفاده می‌کنید: استفاده از Bundling & minification
در هر دو حالت نحوه ارائه اسکریپت‌ها تحت کنترل برنامه ASP.NET در خواهد آمد و مستقیما و بدون دخالت ASP.NET، توسط IIS توزیع نمی‌شوند.
- برای مپ کردن فایل‌های استاتیک به موتور ASP.NET می‌شود از StaticFileHandler استفاده کرد. اگر کش کردن اطلاعات استاتیک در سمت سرور فعال شود، این مساله بار اضافه‌ای را به سرور تحمیل نخواهد کرد.

- علت اینکه این مطلب رو نوشتم مربوط به زمانی بود که پروژه‌ای از قبل موجود بود با فایل pfx آن و قصد داشتم معادل محافظت نشده فایل pfx آن‌را تولید کنم.
- در مورد تولید فایل‌های pfx و snk یک مطلب نسبتا جامع در سایت داریم.
- به نظر من زمانیکه یک پروژه سورس باز است، امضا کردن اسمبلی‌های آن آنچنان مفهومی ندارد چون دسترسی به سورس و حتی ارائه آن بر اساس اطمینان به جامعه مصرف کننده صورت می‌گیرد. خیلی خیلی کم هستند موارد سوء استفاده از اسمبلی‌های امضاء شده به این صورت. مگر اینکه بحث پروژه کرنل لینوکس با تعداد مصرف کننده بالا و اهمیت امنیتی آن مطرح باشد که نیاز به امضای فایل‌های باینری آن وجود داشته باشد.