مطالب
بررسی نحوه‌ی راه اندازی پروژه‌ی Decision
پروژه‌ی Decision را می‌توان چکیده‌ی تمام مطالب سایت دانست که در آن جمع آوری نکات ASP.NET MVC 5.x، EF Code First 6.x، مباحث تزریق وابستگی‌ها، کار با AutoMapper، بوت استرپ 3 و غیره لحاظ شده‌اند. به همین جهت درک آن بدون مطالعه‌ی « تمام » مطالب سایت میسر نیست و همچنین راه اندازی آن.
در این مطلب با توجه به سؤالات زیادی که در مورد صرفا نحوه‌ی اجرای بدون خطای آن وجود داشت، ریز مراحل آن‌را بررسی می‌کنیم.


پیشنیازهای توسعه‌ی برنامه
- با توجه به استفاده از ویژگی‌های C# 6 در این پروژه، حتما نیاز است برای کار و اجرای آن از VS 2015 استفاده کنید.
- همچنین این پروژه از قابلیت «فایل استریم» SQL Server استفاده می‌کند. بنابراین نیاز است نگارش متناسبی از SQL Server را پیشتر نصب کرده باشید (هر نگارشی بالاتر از SQL Server 2005).
- اگر از ReSharper استفاده می‌کنید، به صورت موقت آن‌را به حالت تعلیق درآورید (منوی tools، گرینه‌ی options و انتخاب resharper و سپس suspend کردن آن). این مورد سرعت بازیابی بسته‌های نیوگت را به شدت افزایش می‌دهد.


بازیابی وابستگی‌های نیوگت پروژه

مرسوم نیست چند 10 مگابایت وابستگی‌های پروژه را به صورت فایل‌های باینری، به مخزن کدها ارسال کرد. از این جهت که نیوگت بر اساس مداخل فایل‌های packages.config، قابلیت بازیابی و نصب خودکار آن‌ها را دارد. بنابراین ابتدا package manger console را باز کنید؛ از طریق منوی Tools -> NuGet Package Manager -> Package Manager Console


همانطور که در تصویر مشاهده می‌کنید، نیوگت تشخیص داده‌است که بسته‌هایی برای نصب وجود دارند. بنابراین بر روی دکمه‌ی restore کلیک کنید تا کار دریافت و نصب خودکار این بسته‌ها از اینترنت شروع شود. البته اگر پیشتر این بسته‌ها را در پروژه‌های دیگری نصب کرده باشید، نیوگت از کش موجود در سیستم استفاده خواهد کرد و برای دریافت آن‌ها به اینترنت مراجعه نمی‌کند. ولی در هر حال اتصال به اینترنت ضروری است.

پس از پایان کار بازیابی بسته‌ها، یکبار کل Solution را Build کنید تا مطمئن شوید که تمام بسته‌های مورد نیاز به درستی بازیابی و نصب شده‌اند (Ctrl+Shift+B و یا همان منوی Build و انتخاب گزینه‌ی Build Solution).



تنظیمات رشته اتصالی بانک اطلاعاتی برنامه

پس از Build موفق کل Solution در مرحله‌ی قبل، اکنون نوبت به برپایی تنظیمات بانک اطلاعاتی برنامه است. برای این منظور فایل web.config ذیل را باز کنید:
Decision\src\Decision.Web\Web.config
یک چنین تنظیمی را مشاهده می‌کنید:
  <connectionStrings>
    <clear />
    <add name="DefaultConnection" connectionString="Data Source=.\sqlexpress;Initial Catalog=DecisionDb;Integrated Security = true;MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" />
  </connectionStrings>
از آنجائیکه بر روی سیستم من SQL Server نگارش Developer نصب است و از SQL Server Express استفاده نمی‌کنم، تنظیمات فوق را به نحو ذیل تغییر خواهم داد:
  <connectionStrings>
    <clear />
    <add name="DefaultConnection" connectionString="Data Source=(local);Initial Catalog=DecisionDb;Integrated Security = true;MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" />
  </connectionStrings>
تنها تغییر صورت گرفته، تنظیم data source است. مابقی موارد یکی است و تفاوتی نمی‌کند.

در این حالت نیاز است بانک اطلاعاتی خالی DecisionDb را خودتان ایجاد کنید. علت آن به AutomaticMigrationsEnabled = false بر می‌گردد؛ که در ادامه توضیح داده شده‌است و همچنین وجود تنظیم ذیل در فایل Decision\src\Decision.Web\App_Start\ApplicationStart.cs
 Database.SetInitializer<ApplicationDbContext>(null);
این تنظیم و نال بودن پارامتر ورودی آن به این معنا است که اولا برنامه یک بانک اطلاعاتی جدید را به صورت خودکار ایجاد نمی‌کند و همچنین کار Migrations خودکار نیست.


ایجاد بانک اطلاعاتی برنامه و تنظیمات آن

پس از آن، نوبت به ایجاد بانک اطلاعاتی برنامه است. چون این برنامه از EF Code first استفاده می‌کند، قادر است بانک اطلاعاتی ذکر شده‌ی در Initial Catalog فوق را به صورت خودکار ایجاد کند (با تمام جداول، روابط و تنظیمات آن‌ها). این اطلاعات هم از پروژه‌ی Decision.DataLayer و پوشه‌ی Migrations آن تامین می‌شوند.
اگر به فایل Decision\src\Decision.DataLayer\Migrations\201602072159421_Initial.cs مراجعه کنید، یکسری تنظیمات دستی را هم علاوه بر کدهای خودکار EF، مشاهده خواهید کرد:
 //. . .
Sql("EXEC sp_configure filestream_access_level, 2");
Sql("RECONFIGURE", true);

Sql("alter database DecisionDb Add FileGroup FileGroupApplicant contains FileStream", true);
Sql("alter database DecisionDb add file ( name = 'ApplicantDocuements'  ,  filename = 'C:\\FileStream\\ApplicantDocuements') to filegroup FileGroupApplicant", true);
//. . .
این‌ها مواردی هستند که کار تنظیمات فایل استریم را به صورت خودکار انجام می‌دهند.
بنابراین نیاز است در درایور C، پوشه‌ی خالی FileStream از پیش تهیه شده باشد (نیازی به ایجاد پوشه‌ی ApplicantDocuements نیست و این پوشه به صورت خودکار ایجاد می‌شود).

و در فایل Decision\src\Decision.DataLayer\Migrations\Configuration.cs مشخص شده‌است که AutomaticMigrationsEnabled = false. به این معنا که تنظیمات فوق به صورت خودکار به بانک اطلاعاتی اعمال نشده و باید چند دستور ذیل را به صورت دستی صادر کنیم:
الف) ابتدا package manager console را مجددا باز کنید و در اینجا default project را بر روی Decision.DataLayer قرار دهید. از این جهت که قرار است اطلاعات migration را از این پروژه دریافت کنیم:


در غیراینصورت پیام خطای No migrations configuration type was found in the assembly را دریافت خواهید کرد.

ب) سپس دستور ذیل را صادر کنید (با این فرض که بانک اطلاعاتی خالی DecisionDb ذکر شده‌ی در قسمت قبل را پیشتر ایجاد کرده‌اید):
 PM> Update-Database -Verbose -ConnectionStringName "DefaultConnection" -StartUpProjectName "Decision.Web"
این تنظیمات به این معنا است که Update-Database را بر اساس اطلاعات پروژه‌ی Decision.DataLayer انجام بده (همان انتخاب default project)؛ اما رشته‌ی اتصالی را از پروژه‌ی Decision.Web و تنظیمات DefaultConnection آن دریافت کن.

من در این حالت پیام خطای Update-Database : The term 'Update-Database' is not recognized as the name of a cmdlet را دریافت کردم.
راه حل: یکبار ویژوال استودیو را بسته و مجددا باز کنید تا کار نصب بسته‌ها و بارگذاری تمام وابستگی‌های آن‌ها به درستی صورت گیرد. این خطا به این معنا است که هرچند NuGet کار نصب EF را انجام داده‌است، اما هنوز اسکریپت‌های پاورشل آن که دستوراتی مانند Update-Database را اجرا می‌کنند، بارگذاری نشده‌اند. راه حل آن بستن و اجرای مجدد ویژوال استودیو است.
پس از اجرای مجدد ویژوال استودیو و انتخاب default project صحیح (مطابق تصویر فوق)، مجددا دستور Update-Database  فوق را صادر کنید (با پارامترهای ویژه‌ی آن).
با صدور این دستور، پیام خطای ذیل را دریافت کردم:
 The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework'
registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded.
برای رفع آن نیاز است EF را یکبار دیگر نصب کنید:
 PM> Update-Package -Reinstall "EntityFramework" -ProjectName "Decision.DataLayer"
در ادامه مجددا کل Solution را Build کنید؛ چون Migrations بر اساس اطلاعات اسمبلی‌های کامپایل شده‌ی پروژه کار می‌کند.
اینبار دستور update-database فوق (با پارامترهای ویژه‌ی آن) بدون مشکل اجرا شد و بانک اطلاعاتی مربوطه تشکیل گردید.




اکنون برنامه قابل اجرا است و در این حالت است که می‌توان دکمه‌ی F5 را جهت اجرای برنامه فشرد. البته در این حالت بر روی پروژه‌ی Decision.Web کلیک راست کرده و گزینه‌ی set as startup project را نیز انتخاب کنید و سپس F5:



لطفا سؤالاتی را که مرتبط با «راه اندازی» این پروژه نیستند، در قسمت بازخوردهای اختصاصی آن مطرح کنید.
مطالب
بیرون نگاه داشتن پکیج های NuGet از سورس کنترل Git
ابزار NuGet بسیار کار آمد و مفید است. یکی از مشکلات رایج هنگامی پیش می‌آید که پروژه را بهمراه بسته‌های نصب شده به سورس کنترل push می‌کنید. با این کار حجم زیادی از فایل‌ها را به مخزن سورس کنترل آپلود می‌کنید و هنگام clone کردن پروژه توسط هر شخصی، این اطلاعات باید دریافت شوند. بد‌تر از این هنگامی است که برخی از بسته‌ها از سورس حذف می‌شوند و باید به اعضای تیم پروژه اطلاع دهید که چه بسته‌هایی باید دریافت و نصب شوند.

برای رفع این موارد به NuGet Package Restore وارد شوید.


به ویژوال استودیو اجازه دهید بسته‌های NuGet را در صورت لزوم احیا کند
پیش از آنکه بتوانیم از قابلیت Package Restore استفاده کنیم باید آن را روی ماشین خود فعال کنیم. این کار روی هر ماشین باید انجام شود (per-machine requirement). بدین منظور به منوی Tools -> Options -> Package Manager بروید.

در دیالوگ باز شده تنظیمات مربوطه را مانند تصویر زیر بروز رسانی کنید.

حال که ماشین ما برای بازیابی خودکار بسته‌های NuGet پیکربندی شده است، باید این قابلیت را برای Solution مورد نظر هم فعال کنیم.


فعال سازی NuGet Package Restore برای پروژه‌ها

بدین منظور روی Solution کلیک راست کنید و گزینه Enable Package Restore را انتخاب نمایید.

این کار ممکن است چند ثانیه زمان ببرد. پس از آنکه ویژوال استودیو پردازش‌های لازم را انجام داد، می‌توانید ببینید که پوشه جدیدی در مسیر ریشه پروژه ایجاد شده است.

همانطور که می‌بینید فایلی با نام NuGet.exe در این پوشه قرار دارد که باید به سورس کنترل آپلود شود. هنگامیکه شخصی پروژه شما را از سورس کنترل دریافت کند و بخواهد پروژه را Build کند، بسته‌های مورد نیاز توسط این ابزار بصورت خودکار دریافت و نصب خواهند شد.

مرحله بعد حذف کردن تمام بسته‌های NuGet از سورس کنترل است. برای اینکار باید فایل gitignore. را ویرایش کنید. فرض بر این است که سورس کنترل شما Git است، اما قواعد ذکر شده برای دیگر فریم ورک‌ها نیز صادق است. تنها کاری که باید انجام دهید این است که به سورس کنترل خود بگویید چه چیز هایی را در بر گیرد و از چه چیزهایی صرفنظر کند.

ویرایش فایل gitignore. برای حذف بسته‌ها و شامل کردن NuGet.exe

یک پروژه معمولی ASP.NET MVC 5 که توسط قالب استاندارد VS 2013 ایجاد می‌شود شامل 161 فایل از بسته‌های مختلف می‌شود (در زمان تالیف این پست). این مقدار قابل توجهی است که حجم زیادی از اطلاعات غیر ضروری را به مخزن سورس کنترل اضافه می‌کند. با استفاده از نسخه پیش فرض فایل gitignore. (یا فایل‌های مشابه دیگر برای سورس کنترل‌های مختلف مثل TFS) تعداد فایل هایی که در کل به مخزن سورس کنترل ارسال می‌شوند بیش از 200 آیتم خواهد بود. قابل ذکر است که این تعداد فایل شامل فایل‌های اجرایی (binary) و متعلق به ویژوال استودیو نیست. به بیان دیگر نزدیک به 75% از فایل‌های یک پروژه معمولی ASP.NET MVC 5 که توسط VS 2013 ساخته می‌شود را بسته‌های NuGet تشکیل می‌دهد، که حالا می‌توانند بجای ارسال شدن به مخزن سورس کنترل، بصورت خودکار بازیابی و نصب شوند.

برای حذف این فایل‌ها از سورس کنترل، فایل gitignore. را ویرایش می‌کنیم. اگر از سورس کنترل‌های دیگری استفاده میکنید نام این فایل hgignore. یا tfsignore. یا غیره خواهد بود. محتوای فایل شما ممکن است با لیست زیر متفاوت باشد اما جای نگرانی نیست. تنها تغییرات اندکی بوجود خواهیم آورد و مابقی محتویات فایل مهم نیستند.

چشم پوشی از پوشه Packages

فایل gitignore. را باز کنید و برای نادیده گرفتن پوشه بسته‌های NuGet در سورس، خط زیر را به آن اضافه کنید.

packages*/

استثنایی برای در نظر گرفتن NuGet.exe ایجاد کنید
به احتمال زیاد فایل gitignore. شما از فایل هایی با فرمت .exe چشم پوشی می‌کند. برای اینکه بسته‌های NuGet بتوانند بصورت خودکار دریافت شوند باید استثنایی تعریف کنیم. فایل gitignore. خود را باز کنید و به دنبال خط زیر بگردید.
*.exe
سپس خط زیر را بعد از آن اضافه کنید. دقت داشته باشید که ترتیب قرارگیری این دستوارت مهم است.
*.exe
!NuGet.exe
دستورات بالا به Git می‌گوید که فایل‌های .exe را نادیده بگیرد؛ اما برای فایل NuGet.exe استثناء قائل شود.
انجام مرحله بالا انتخابی (optional) است. اگر کسی که پروژه را از مخزن سورس کنترل دریافت می‌کند قابلیت Package Restore را روی Solution فعال کند ابزار NuGet.exe دریافت می‌شود. اما با انجام این مراحل دیگر نیازی به این فعالسازی نخواهد بود، پس در کار اعضای تیم هم صرفه جویی کرده اید.

اطلاع رسانی به اعضای تیم و مشتریان بالقوه
دیگر نیاز نیست بسته‌های NuGet را به مخزن سورس کنترل ارسال کنیم. اما باید به مخاطبین خود اطلاع دهید تا پیکربندی‌های لازم برای استفاده از قابلیت Package Restore را انجام دهند (مثلا در فایل README.txt پروژه).
اشتراک‌ها
روش غیرفعال کردن موقتی ReSharper

اگر در حین کار با nuget و صدور فرمان update-package آن، nuget مدام هنگ می‌کند، مشکل از تداخل ReSharper با آن است. از طریق منوی Tools | Options | ReSharper می‌توان ReSharper را به صورت موقت غیرفعال کرد.

روش غیرفعال کردن موقتی ReSharper
اشتراک‌ها
Entity Framework Core 7 نسخه نهایی

Entity Framework Core (EF Core) 7 is available on NuGet today!

EF Core 7 is the successor to EF Core 6, and can be referred to as EF7 for brevity. EF Core 7 contains many features that help in porting “classic” EF6 applications to use EF7. As such, we encourage people to upgrade existing classic EF applications to use EF7 where possible. See Porting from EF6 to EF Core for more information. 

Entity Framework Core 7 نسخه نهایی
مطالب
ساخت Nuget Manager شخصی
یکی از راحت‌ترین راه‌های افزودن پکیج‌های برنامه نویسی به پروژه‌های دات نت، از طریق Nuget میباشد. این ابزار به قدری راحت است که من تصمیم گرفتم پکیج‌های تیممان را از طریق این سیستم دریافت کنیم. مزیت آن هم این است که بچه‌های تیم همیشه به پکیج‌ها دسترسی راحت‌تری دارند و هم اینکه در آینده به روز رسانی ساده‌تری خواهند داشت. با توجه به اینکه سایت اصلی تنها پکیج‌های عمومی را پشتیبانی می‌کند و چیزی تحت عنوان پکیج‌های شخصی ندارد، پس باید خودمان این سرویس را راه اندازی کنیم. برای راه اندازی این سیستم می‌توان آن را بر روی سیستم شخصی قرار داد و یا اینکه به صورت اینترنتی بر روی یک سرور به آن دسترسی داشته باشیم. در این مقاله این دو روش را بررسی میکنم:

پی نوشت: برای داشتن نیوگت شخصی سایت‌های نظیر Nuget Server و Myget ( به همراه پشتیبانی از مخازن npm و Bower ) هم این سرویس را ارائه میکنند. ولی باید هزینه‌ی آن را پرداخت کنید. البته سایت GemFury مخازن رایگان مختلفی چون Nuget را نیز پشتیبانی می‌کند.


نصب بر روی یک سیستم شخصی یا لوکال


در اولین قدم، شما باید یک دایرکتوری را در سیستم خود درست کنید تا پکیج‌های خود را داخل آن قرار دهید. پنجره‌ی Package manager Settings را باز کنید و در آن گزینه‌ی Package Sources را انتخاب کنید. سپس در کادر باز شده،  بر روی دکمه‌ی افزودن، در بالا کلیک کنید تا در پایین کادر، از شما نام محل توزیع بسته و آدرس آن را بپرسد:


بعد از ورود اطلاعات، بر روی دکمه‌ی Update کلیک کنید. از این پس این دایرکتوری، منبع پکیج‌های شماست و برای دریافت پکیج‌ها از این آدرس می‌توانید از طریق منوی کشویی موجود در کنسول، پکیج جدید خودتان را انتخاب کنید:


اگر میخواهید می‌توانید این دایرکتوری را به اشتراک بگذارید تا دیگر افراد حاضر در شبکه‌ی محلی هم بتوانند آن را به عنوان منبع توزیع خود به سیستم اضافه کنند.

مرحله‌ی بعدی این است که از طریق ابزار خط فرمان نیوگت نسخه 3.3 پکیج‌هایتان را به دایرکتوری مربوطه انتقال دهید. نحوه‌ی صدا زدن این دستور به شکل زیر است:
nuget init e:\nuget\ e:\nuget\test
این دستور تمام پکیج‌هایی را که شما در مسیر اولی قرار داده‌اید، به داخل دایرکتوری test منتقل می‌کند. ولی اگر قصد دارید که فقط یکی از پکیج‌ها را به این دایرکتوری انتقال دهید از دستور زیر استفاده کنید:
nuget add GMap.Net.1.0.1.nupkg -source e:\nuget\test
اینبار با کلمه‌ی رزرو شده‌ی add و بعد از آن نام پکیچ، دایرکتوری منبع را به آن معرفی می‌کنیم.


ساخت منبع راه دور (اینترنت)


شما با استفاده از ویژوال استودیو و انجام چند عمل ساده می‌توانید پکیج‌های خودتان را مدیریت کنید. برای شروع، یک پروژه‌ی تحت وب خام (Empty) را ایجاد کنید و در کنسول Nuget دستور زیر را وارد کنید:
Install-Package NuGet.Server
شما با نصب این بسته و وابستگی‌هایش، به راحتی یک سیستم مدیریت بسته را دارید. ممکن است مدتی برای نصب طول بکشد و در نهایت از شما بخواهد که فایل web.config را رونویسی کند که شما اجازه‌ی آن را صادر خواهید کرد. بعد از اتمام نصب، فایل web.config را گشوده و در خط زیر، خصوصیت Value را به یک دایرکتوری که دلخواه که مدنظر شماست تغییر دهید. این آدرس دهی می‌تواند به صورت مطلق باشد، یا آدرس مجازی آن را وارد کنید؛ یا اگر هم خالی بگذارید به طور پیش فرض دایرکتوری Packages را در نظر میگیرد:
<appSettings>
    <!-- Set the value here to specify your custom packages folder. -->
    <add key="packagesPath" value="×\Packages" />
</appSettings>
حال فایل‌های دایرکتوری محلی خود را به دایرکتوری Packages انتقال دهید و سپس سایت را بر روی IIS، هاست نمایید. از این پس منبع شما به صورت آنلاین مانند آدرس زیر در دسترس خواهد بود.
(هر محلی که نصب کنید طبق الگوی مسیریابی، آدرس nuget را در انتها وارد کنید)
Dotnettips.info/nuget

در صورتی که قصد دارید مستقیما بسته‌ای را به سمت سرور push کنید، از یک رمز عبور قدرتمند که آن را می‌توانید در web.config، بخش apiKey وارد نمایید، استفاده کنید. اگر هم نمی‌خواهید، می‌توانید در تگ RequiredApiKey در خصوصیت Value، مقدار false را وارد نمایید.
برای اینکار می‌توانید از دستور زیر استفاده کنید:
nuget push GMap.Net.1.0.1.nupkg -source http://Dotenettips.info/nuget (ApiKey)
البته اگر قبل از دستور بالا، دستور زیر را وار کنید، دیگر نیازی نیست تا برای دستورات بعدی تا مدتی ApiKey را وارد نمایید.
nuget setapikey -source https://www.dntips.ir/Nuget (ApiKey)
نظرات مطالب
EF Code First #4
فایل‌های مرتبط با migrations فقط از طریق NuGet به همراه بسته EF دریافت می‌شوند. بنابراین داشتن فایل‌های DLL مربوط به EF کافی نیست. بعد از آن، این فرامین از طریق پاورشل خود NuGet در vs.net باید اجرا شوند.
در کل اگر می‌خواهید بدانید این بسته درست نصب شده یا نه، دستور زیر را در پاورشل خود NuGet اجرا کنید:
Get-Package