حمیدرضا حمیدرضا
مطالب
قسمت دوم -- نگاهی دقیق تر به اولین پروژه VC++ (درک مفهوم فایلهای سرآیند و فضای نام ، ویژگیهای زبان ++C و برخی قوانین برنامه نویسی در ++C)
در این قسمت نگاهی دقیق‌تر به فایلهای سرآیند ، فضای نام ، ویژگیهای زبان ++C  و برخی قوانین برنامه نویسی ++C  خواهیم داشت و همچنین در مورد  اولین پروژه توضیحات جامع‌تری ارائه میکنیم .

یک برنامه مجموعه ای از دستورات است که توسط کامپیوتر اجرا میگردد ، برنامه نویسان برای نوشتن این دستورات از زبانهای برنامه نویسی استفاده میکنند ، برخی از این زبانها مسقیما قابل فهم توسط کامپیوتر بوده و برخی نیاز به ترجمه دارند . زبانهای برنامه نویسی را میتوان به سه دسته تقسیم نمود :
1 -  زبانهای ماشین
2 - زبانهای اسمبلی
3 - زبانهای سطح بالا

زبانهای ماشین :
  زبانی که مستقیما و بدون نیاز به ترجمه قابل فهم توسط کامپیوتر می‌باشد . هر پردازنده یا processor  زبان خاص خود را دارد !... در نتیجه تنوع زبان ماشین بستگی به انواع پردازنده‌های موجود دارد و اگر دو کامپیوتر دارای پردازنده‌های یکسان نباشتد ، زبان ماشین آنها با یکدیگر متفاوت و غیر قابل فهم برای دیگری می‌باشد . زبان ماشین وابسته به ماشین یا Machine independent  می‌باشد . تمامی دستورات در این زبان توالی از 0 و 1 می‌باشند . برنامه‌های اولیه را با این زبان می‌نوشتند در نتیجه نوشتن برنامه سخت و احتمال خطا داشتن در آن زیاد بود . ار آنجا که نوشتن برنامه به این زبان سخت و فهم برنامه‌های نوشته شده به آن دشوار بود ، برنامه نویسان به فکر استفاده از حروف بجای دستورات زبان ماشین افتادند ( پیدایش زبان اسمبلی )

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

زبانهای سطح بالا :
زبانهای سطح بالا قابل فهم بودند و این امکان را داشتند تا چند دستور زبان ماشین یا اسمبلی را بتوان در قالب یک دستور نوشت ( منظور توابع کتابخانه ای در ++C/C) . پس هم فهم ، هم نوشتن برنامه در این زبانها راحت و هم تعداد خطوط کد کمتر شد . این زبانها به زبانهای برنامه نویسی سطح بالا یا High-Level Programming Language  معروفند . البته برنامه نوشته شده در این زبان نیز برای کامپیوتر قابل فهم نبوده و باید به زبان ماشین ترجمه شوند ، این وظیفه بر عهده کامپایلر می‌باشد . اولین زبانهای برنامه نویسی سطح بالا مانند  FORTRAN ، COBOL ، PASCAL و C  می‌باشند . زبان برنامه نویسی ++C تکامل یافته زبان  C  میباشد .
هر یک از زبانهای برنامه نویسی سطح بالا یک روش برنامه نویسی را پشتیبانی میکند به طور مثال زبان C  و  PASCAL  از روشهای برنامه نویسی  ساخت یافته ای و پیمانه ای و زبانهای مانند ++C و JAVA  از روش برنامه سازی شی گرا یا Object Oriented Programming یا به اختصار (OOP) استفاده میکنند . زبان ++C  چون زبان C را بطور کامل در بر  دارد پس از هر سه روش برنامه نویسی ساخت یافته و پیمانه ای و شی گرا استفاده میکند .

تا اینجا با تاریخچه ای از زبانها و مراحل تکامل آنها آشنا شدیم . حال ویژگیها و دلایل استفاده از زبان  ++C  را مرور میکنیم :

زبان C  در سال 1972 توسط دنیس ریچی طراحی شد . زبان C تکامل یافته زبان  BCPL است که طراح آن مارتین ریچاردز می‌باشد ، زبان BCPL نیز از زبان B  مشتق شده است که طراح آن  کن تامسون بود . (خداوند روح دنیس ریچی را همچون هوگو چاوز با مسیح بازگرداند ! ...) .
از این زبان برای نوشتن برنامه‌های سیستمی ، همچون سیستم عامل ، کامپایلر ، مفسر ، ویرایشگر ، برنامه‌های مدیریت بانک اطلاعاتی ، اسمبلر استفاده میکنند .
زبان C  برای اجرای بسیاری از دستوراتش از توابع کتابخانه ای استفاده میکند و بیشتر خصوصیات وابسته به سخت افزار را به این توابع واگذار میکند لذا نرم افزار تولید شده با این زبان به سخت افزار خاصی بستگی ندارد و با اندکی تغییرات می‌توانیم نرم افزار مورد نظر را روی ماشینهای متفاوت اجرا کنیم ، در نتیجه برنامه نوشته شده با C  قابلیت انتقال (Portability) دارند . بعلاوه کاربر میتواند توابع کتابخانه ای خاص خودش را بنویسد و از آنها در برنامه هایش استفاده کند .
برنامه‌های مقصدی که توسط کامپیلرهای C  ساخته میشود بسیار فشرده و کم حجم‌تر از برنامه‌های مشابه در سایر زبانهاست ، این امر باعث افزایش سرعت اجرای آنها میشود .
++C  که از نسل  C  است تمام ویژگیهای ذکر شده بالا را دارد ، علاوه بر آن شی گرا نیز می‌باشد . برنامه‌های شی گرا منظم و ساخت یافته اند و قابل آپدیت هستند و به سهولت تغییر و بهبود می‌یابند و قابلیت اطمینان و پایداری بیشتری دارند .

تحلیل  اولین پروژه :



در اولین پروژه  کد فوق را بکار بردیم ، حال به شرح دستورات آن می‌پردازیم .
#include <iostream>
دستوراتی که علامت # پیش از آنها قرار میگیرد ، دستورات راهنمای پیش پردازنده هستند . این خط یک دستور پیش پردازنده است که توسط پیش پردازنده و قبل از شروع کامپایل ، پردازش میشود . این کد فایل iostream  را به برنامه اضافه میکند . کتابخانه استاندارد  ++C  به چندین بخش تقسیم شده است و هر بخش فایل سرآیند خود را دارد . دلیل قرار گرفتن این دستور در ابتدای برنامه این است  که ، پیش از استفاده از هر تابع و فراخوانی کردن آن در برنامه ، کامپایلر لازم است اطلاعاتی در مورد آن تابع داشته باشد .  در خط کد بالا فایل سرآیند  iostream  استفاده نمودیم زیرا شامل توابع مربوط به I/O  ( ورودی / خروجی ) می‌باشد .

int  main()
{
 
   return 0;
}
دستور فوق بخشی از هر برنامه ++C  است ، main  تابع اصلی هر برنامه ++C است که شروع برنامه از آنجا آغاز می‌شود . کلمه  int  در ابتدای این خط ، مشخص میکند که تابع main پس از اجرا و به عنوان مقدار برگشتی (;return 0)  یک عدد صحیح باز می‌گرداند .

std::cout<<"Hello world ...\n";
دستور فوق یک رشته را در خروجی استاندارد که معمولا صفحه نمایش می‌باشد ارسال میکند . std  یک فضای نام است . فضای نام محدوده ای است که چند موجودیت در آن تعریف شده است . مثلا موجودیت cout  در فضای نام std در فایل سرآیند iostream تعریف شده است .


در زبان ++C  هر دستور به ; (سیموکالن) ختم میشود .


 

‫۱۱ سال و ۸ ماه قبل، یکشنبه ۲۷ اسفند ۱۳۹۱، ساعت ۰۶:۳۰
وحید نصیری وحید نصیری
مطالب
چگونه تشخیص دهیم UI Virtualization در WPF خاموش شده است؟
در مطلب «بهبود کارآیی کنترل‌های لیستی WPF در حین بارگذاری تعداد زیادی از رکوردها» عنوان شد که در حالت فعال بودن UI Virtualization، فقط به تعداد ردیف‌های نمایان، اشیاء متناظری به یک کنترل لیستی اضافه می‌شوند و حالت برعکس آن زمانی است که ابتدا کلیه اشیاء بصری یک لیست تولید شده و سپس لیست نهایی نمایش داده می‌شود.

سؤال: چگونه می‌توان تعداد اشیاء اضافه شده به Visual tree یک کنترل لیستی را شمارش کرد؟

شبیه به افزونه FireBug فایرفاکس، برنامه‌ای به نام Snoop نیز جهت WPF تهیه شده است که با تزریق خود به درون پروسه برنامه، امکان بررسی ساختار Visual tree کل یک صفحه را فراهم می‌کند. برای دریافت آن به آدرس ذیل مراجعه نمائید:

پس از دریافت، ابتدا مثال انتهای بحث «بهبود کارآیی کنترل‌های لیستی WPF در حین بارگذاری تعداد زیادی از رکوردها» را اجرا کرده و سپس برنامه Snoop را نیز جداگانه اجرا نمائید. اگر نام برنامه WPF مورد نظر، در لیست برنامه‌های تشخیص داده شده توسط Snoop ظاهر نشد، یکبار بر روی دکمه Refresh آن کلیک نمائید. پس از آن برنامه نمایش لیست‌ها را در Snoop انتخاب کرده و دکمه کنار آیکن minimize کردن Snoop را کشیده و بر روی پنجره برنامه رها کنید. شکل زیر ظاهر خواهد شد:


بله. همانطور که ملاحظه می‌کنید، در برگه Slow version به علت فعال نبودن مجازی سازی UI، تعداد اشیاء موجود در Visual tree کنترل لیستی، بالای 10 هزار مورد است. به همین جهت بارگذاری آن بسیار کند انجام می‌شود.
اکنون همین عملیات کشیدن و رها کردن دکمه بررسی Snoop را بر روی برگه دوم برنامه انجام دهید:


در اینجا چون مجازی سازی UI فعال شده است، فقط به تعداد ردیف‌های نمایان به کاربر، اشیاء لازم جهت نمایش لیست، تولید و اضافه شده‌اند که در اینجا فقط 188 مورد است و در مقایسه با 10 هزار مورد برگه اول، بسیار کمتر می‌باشد و بدیهی است در این حالت مصرف حافظه برنامه بسیار کمتر بوده و همچنین سرعت نمایش لیست نیز بسیار بالا خواهد بود.
‫۱۱ سال و ۳ ماه قبل، سه‌شنبه ۲۲ مرداد ۱۳۹۲، ساعت ۱۶:۳۰
وحید نصیری وحید نصیری
مطالب
Minimal API's در دات نت 6 - قسمت اول - معرفی
یکی از مهم‌ترین تغییرات دات نت 6، ارائه‌ی Minimal API's به همراه آن است که نسبت به MVC و سایر مشتقات ASP.NET Core، کمتر به همراه پیش‌فرض‌های نظری خاص و بسیار مقید و متعصبانه (opinionated) است؛ که این مورد خود مزیتی است جهت انجام امور متداول، به نحوی دیگر و دلخواه و با آزادی عمل بیشتری در طراحی endpoints مورد نیاز و کل برنامه. خصوصا این سبک جدید، با معماری برش‌های عمودی (vertical slices) ارائه شده‌ی توسط نویسنده‌ی AutoMapper، هماهنگی خاصی دارد و اینطور به نظر می‌رسد که جهت ساده سازی طراحی برنامه‌های ASP.NET Core با معماری CQRS ارائه شده‌است. با وجود Minimal API's می‌توان از دو لایه‌ی متداول برنامه‌ها رها شد: لایه‌ی سرویس‌ها و لایه‌ی مخازن یا Repositories. در معماری برش‌های عمودی، برنامه به ویژگی‌های خاصی (Features) تقسیم شده و هر ویژگی، متکی به خود طراحی می‌شود. زمانیکه از هندلرها برای هر Command و Query معماری CQRS استفاده می‌کنیم، این‌ها مختص به یک ویژگی متکی به خود طراحی می‌شوند و به همراه تمام اطلاعات و اعمال مرتبط هستند و دیگر در این حالت، وجود لایه‌های سرویس و مخزن، بی‌معنا و غیرضروری می‌شوند.

در ادامه قصد داریم تمام این موارد را مانند Minimal API's و معماری برش‌های عمودی به همراه CQRS، در طی یک سری و یک پروژه‌ی عملی ساخت یک Blog به نام MinimalBlog، بررسی کنیم. البته هدف ما در اینجا صرفا ساخت backend ساختار یافته‌ی این برنامه‌است؛ منهای UI آن. هدف اصلی ما از این سری، ارائه‌ی یک معماری، جهت کار با Minimal API's است.


دریافت کدهای کامل این سری

جهت مرور سریعتر و ساده‌تر این سری، کدهای کامل آن‌را از اینجا می‌توانید دریافت کنید: MinimalBlog.zip


پروژه‌هایی که برنامه‌ی MinimalBlog را تشکیل می‌دهند

برنامه‌ی MinimalBlog، تنها از سه پروژه‌ی زیر تشکیل می‌شود:
MinimalBlog.Api: این پروژه از نوع minimal API's است که توسط دستور جدید «dotnet new webapi --use-minimal-apis» آغاز خواهد شد و به صورت پیش‌فرض به همراه پشتیبانی از OpenAPI نیز هست. البته اگر از VS2022 استفاده می‌کنید، در حین آغاز یک پروژه‌ی Web API جدید، تیک مربوط به use controllers را در UI بردارید تا از Minimal API's استفاده شود.
MinimalBlog.Dal: که Dal در اینجا مخفف data access layer است و یک class library می‌باشد و با دستور dotnet new classlib آغاز می‌شود.
MinimalBlog.Domain: نیز یک class library است و با دستور dotnet new classlib آغاز می‌شود.

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


بررسی ساختار ابتدایی پروژه‌ی MinimalBlog.Api

در اینجا تنها تک فایل Program.cs، به همراه تنظیمات برنامه قابل مشاهده‌است و فایل Starup.cs از آن حذف شده‌است (اطلاعات بیشتر). این فایل نیز بر مبنای مفهوم top level programs طراحی شده‌است و به همراه تعریف class و یا فضای نامی نیست:
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
همانطور که ملاحظه می‌کنید، تمام اتفاقات در همین تک فایل رخ می‌دهند. برای مثال سرویس‌های مورد نیاز برنامه به مجموعه‌ی builder.Services اضافه می‌شوند؛ شبیه به کاری که پیشتر در فایل Startup.cs و متد ConfigureServices آن انجام می‌دادیم.

پس از آن به تعاریف زیر می‌رسیم؛ تعاریف میان افزارهایی که پیشتر در متد Configure کلاس Startup انجام می‌شدند، الان همگی در تک فایل Program.cs قرار دارند:
var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
البته هنوز هم می‌توان در صورت نیاز به همان ساختار کلاس Startup پیشین نیز رسید.


در انتهای این فایل نیز تعاریف پیش‌فرض زیر قرار دارند:
var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast =  Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateTime.Now.AddDays(index),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast");

app.Run();

record WeatherForecast(DateTime Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}
در اینجا متد متد MapGet یک endpoint را تعریف کرده و سپس اکشنی را به آن انتساب می‌دهد. یعنی اگر آدرس weatherforecast/ درخواست شود، lambda expression تعریف شده، اجرا می‌شود. هدف از ارائه‌ی Minimal API نیز همین است تا بتوان با حداقل کدنویسی، سریعا به نتیجه‌ی مدنظر خود رسید.
در همین حال اگر برنامه‌ی Api را اجرا کنیم، به تصویر زیر خواهیم رسید:


در ادامه کدهای موجود در این فایل را Refactor کرده و به کلاس‌های دیگری منتقل می‌کنیم؛ چون اگر قرار باشد در طول زمان تمام endpoints مدنظر را در همینجا تعریف کنیم، کنترل برنامه از دست خارج خواهد شد.


غنی سازی Solution و کامپایلر #C با استفاده از فایل‌های editorconfig. و Directory.Build.props

در مورد این دو فایل در مطلب «غنی سازی کامپایلر C# 9.0 با افزونه‌ها » بیشتر بحث شده‌است. هدف از آن‌ها، اعمال یکسری تنظیمات سراسری، به تمام پروژه‌های یک solution به صورت یک‌دست است؛ مانند تنظیمات کامپایلر جهت نمایش اخطارها به صورت خطاها، تعریف usingهای سراسری سی‌شارپ 10 و یا اعمال Roslyn analyzers به تمام پروژه‌ها. این دو فایل را به همراه پروژه‌ی پیوست می‌توانید دریافت کنید و ... باید جزء استاندارد تمام پروژه‌های جدید باشند. چون وجود آن‌ها سبب خواهد شد که به شدت کیفیت کدهای نهایی افزایش یابند و مبتنی بر یکسری best practices شوند.
‫۲ سال و ۶ ماه قبل، سه‌شنبه ۲۴ اسفند ۱۴۰۰، ساعت ۱۳:۵۵
وحید نصیری وحید نصیری
مطالب
رسم گراف

کتابخانه‌های زیادی برای رسم گراف وجود دارند منجمله mxGraph که برای استفاده غیرتجاری رایگان و سورس باز است. mxGraph نگارش‌های PHP ، Java‌ و JavaScript ایی نیز دارد که به همراه بسته مربوطه ارائه می‌شوند.
پس از دریافت آن، در فولدری به نام dotnet می‌توانید سورس کتابخانه مربوط به دات نت فریم ورک آن‌را دریافت کنید.
فایل پروژه‌ی VS.Net را در آن فولدر نخواهید یافت. حتی آن‌را کامپایل هم نکرده‌اند. (احتمالا به این دلیل که کسی نپرسد این پروژه با چه محصولی تولید شده و آیا لایسنس استفاده از آن را دارید یا خیر. این هم یک روش است ...)
برای کامپایل آن، یک پروژه library جدید را در VS.Net آغاز کرده و پوشه‌های موجود در پوشه‌ی dotnet را به آن افزوده و سپس آن‌را کامپایل کنید تا فایل mxGraph.dll تولید شود.

یک مثال ساده از نحوه‌ی استفاده‌ی آن به صورت زیر است که فایل test.png را تولید خواهد کرد.
using System;
using System.Drawing;
using System.Windows.Forms;
using com.mxgraph;
using System.Drawing.Imaging;

       void Test1()
       {
           // Creates graph with model
           mxGraph graph = new mxGraph();
           Object parent = graph.GetDefaultParent();

           // Adds cells into the graph
           graph.Model.BeginUpdate();
           try
           {
               Object v1 = graph.InsertVertex(parent, null, "سلام", 20, 20, 80, 30, "strokeColor=#FFCF8A;fillColor=#FFCF8A;gradientColor=white;fontBold=true;fontFamily=tahoma;rounded=true;shadow=true;shape=ellipse");
               Object v2 = graph.InsertVertex(parent, null, "!دنیای ظالم", 200, 150, 80, 30, "rounded=true;shadow=true;fontFamily=tahoma");
               Object e1 = graph.InsertEdge(parent, null, "e1", v1, v2, "fontFamily=tahoma");
           }
           finally
           {
               graph.Model.EndUpdate();
           }

           mxCellRenderer.CreateImage(graph, null, 1,
                                      Color.White, true, null).Save("test.png", ImageFormat.Png);
       }




و یا اگر قصد داشته باشید که از آن در ASP.Net استفاده کنید، یک generic handler را به پروژه خود افزوده (مثلا ImageHandler.ashx) و کد آن‌را برای مثال به صورت زیر تغییر دهید:

using System;
using System.Web;
using com.mxgraph;
using System.Drawing;
using System.Web.Services;
using System.IO;
using System.Drawing.Imaging;

namespace test
{
   [WebService(Namespace = "http://tempuri.org/")]
   [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
   public class ImageHandler : IHttpHandler
   {
       public void ProcessRequest(HttpContext context)
       {
           // Creates graph with model
           mxGraph graph = new mxGraph();
           Object parent = graph.GetDefaultParent();

           // Adds cells into the graph
           graph.Model.BeginUpdate();
           try
           {
               Object v1 = graph.InsertVertex(parent, null, "سلام", 20, 20, 80, 30, "strokeColor=#FFCF8A;fillColor=#FFCF8A;gradientColor=white;fontBold=true;fontFamily=tahoma;rounded=true;shadow=true;shape=ellipse");
               Object v2 = graph.InsertVertex(parent, null, "!دنیای ظالم", 200, 150, 80, 30, "rounded=true;shadow=true;fontFamily=tahoma");
               Object e1 = graph.InsertEdge(parent, null, "e1", v1, v2, "fontFamily=tahoma");
           }
           finally
           {
               graph.Model.EndUpdate();
           }

           Image image = mxCellRenderer.CreateImage(graph, null, 1, Color.White, true, null);

           // Render BitMap Stream Back To Client
           MemoryStream memStream = new MemoryStream();
           image.Save(memStream, ImageFormat.Png);

           memStream.WriteTo(context.Response.OutputStream);
       }

       public bool IsReusable
       {
           get
           {
               return false;
           }
       }
   }

}
اکنون نحوه استفاده از این handler در یک صفحه وب به صورت زیر است:
<img src="ImageHandler.ashx" />

‫۱۵ سال و ۶ ماه قبل، پنجشنبه ۷ خرداد ۱۳۸۸، ساعت ۰۰:۰۴
وحید نصیری وحید نصیری
مطالب
به روز رسانی قسمت assemblyBinding فایل‌های config توسط NuGet
زمانیکه پروژه‌ی شما وابستگی‌های متعددی داشته باشد، احتمال برخوردن به یک چنین خطایی بسیار محتمل است:
 Could not load file or assembly Newtonsoft.Json or one of its dependencies. The system cannot find the file specified.
کتابخانه‌ی Newtonsoft.Json جزو پروژه‌هایی است که مدام به روز رسانی و نگهداری می‌شود. در این بین ممکن است وابستگی A از نگارش 4.5 آن استفاده کند و وابستگی B بر اساس نگارش 4.7 آن کامپایل شده باشد و وابستگی جدیدی از نگارش 6 آن استفاده کند. در یک چنین حالتی زمانیکه پروژه‌ی شما آخرین نگارش JSON.NET را به همراه داشته باشد، وابستگی‌های A و B پیام یافت نشدن نگارش‌های خاص کتابخانه‌ی Newtonsoft.Json را صادر خواهند کرد و در این حالت، برنامه در همان ابتدای کار کرش می‌کند. برای رفع این مشکل می‌توان به دات نت گفت که تمام درخواست‌های مرتبط با JSON.NET را به اسمبلی خاصی هدایت و پردازش کن. به این قابلیت assembly redirects گفته می‌شود و به نحو ذیل در فایل‌های کانفیگ برنامه (app.config یا web.config) قابل تعریف است:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- ... -->
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>
به این ترتیب تمام اسمبلی‌هایی که بر اساس نگارش قدیمی JSON.NET کامپایل شده‌اند، باور خواهند کرد که نگارش 6 آن، همان نگارشی است که باید با آن کار کنند.


به روز رسانی قسمت assembly redirects توسط NuGet

البته اگر بسته‌ی جدیدی را توسط نیوگت نصب کنیم، این assembly redirects به صورت خودکار توسط آن اضافه خواهند شد اما ... گاهی ممکن است موارد قدیمی را به روز نکند یا موردی فراموش شوند یا حتی اگر اطلاعاتی را پیشتر از وب یافته‌اید، دارای خطای تایپی باشند. برای یک چنین مواردی اگر با خطای Could not load file or assembly ابتدای بحث مواجه شدید، مراحل ذیل را طی کنید تا بتوانید قسمت assembly redirects را بازسازی کنید:
الف) به فایل config برنامه مراجعه کرده و کلا قسمت assemblyBinding آن‌را حذف کنید.
ب) سپس دستور ذیل را در کنسول پاورشل نیوگت اجرا کنید:
 PM> Get-Project -All | Add-BindingRedirect
این دستور به تمام پروژه‌های موجود در solution جاری مراجعه کرده و قسمت assemblyBinding آن‌ها را بر اساس آخرین اطلاعات پروژه‌ها و وابستگی‌های آن‌ها به روز می‌کند.
‫۹ سال و ۷ ماه قبل، چهارشنبه ۱۹ فروردین ۱۳۹۴، ساعت ۱۲:۳۵
وحید نصیری وحید نصیری
مطالب
بلاگ‌ها و مطالب مطالعه شده در هفته قبل (هفته دوم آبان)

وبلاگ‌ها و سایت‌های ایرانی


Visual Studio


امنیت


ASP. Net


طراحی وب


اس‌کیوال سرور


به روز رسانی‌ها


ابزارها


سی‌شارپ

  • تازه‌های سی شارپ 4 ، واژه کلیدی dynamic ، قسمت‌های یک و دو و سه

عمومی دات نت


CPP


دلفی


ویندوز


Office

  • آشنایی با یک سری از اصطلاحات outlook 2007 برای برنامه نویس‌ها. (اگر قصد داشته باشید یک add-in را برای outlook 2007 با استفاده از امکانات VSTO توسعه دهید، آشنایی با این اصطلاحات بسیار ضروری خواهد بود)

متفرقه



‫۱۵ سال و ۱۳ ماه قبل، جمعه ۱۷ آبان ۱۳۸۷، ساعت ۰۳:۴۶
وحید نصیری وحید نصیری
بازخوردهای دوره
آشنایی با مدل برنامه نویسی TAP
خیر. بسته‌ی async آن برای دات نت 4.5 کامپایل شده و از اسمبلی‌های دات نت 4.5 استفاده می‌کند. علت هم این‌جا است که متدهای async مربوط به ADO.NET با دات نت 4.5 معرفی شدند و زیر ساخت async مربوط به EF را تشکیل می‌دهند.
‫۹ سال و ۱۲ ماه قبل، جمعه ۲ آبان ۱۳۹۳، ساعت ۲۳:۵۳
وحید نصیری وحید نصیری
مطالب
شروع به کار با EF Core 1.0 - قسمت 3 - انتقال مهاجرت‌ها به یک اسمبلی دیگر
در قسمت قبل، تغییرات Migrations، در EF Core 1.0 بررسی و گردش کاری آن به همراه مثال‌هایی ارائه شدند. در این قسمت یک سری از نکات تکمیلی EF Core Migrations را بررسی خواهیم کرد.


انتقال Context و Migrations به یک اسمبلی دیگر

تا اینجا اگر مثال بررسی شده را دنبال کرده باشید، دو پوشه‌ی Entities و Migrations را به همراه فایل‌‌های موجودیت‌ها، Context برنامه و Migrations آن‌ها، در همان پروژه‌ی اصلی برنامه، خواهید داشت:


در ادامه قصد داریم بانک اطلاعاتی آزمایشی برنامه را drop کرده، پوشه‌ی Migrations را حذف و صرفا دو فایل ApplicationDbContextSeedData و DBInitialization آن‌را نگه داریم.
کلاس Person را به اسمبلی جدید Entities و کلاس ApplicationDbContext را به اسمبلی جدید DataLayer منتقل می‌کنیم:


اسمبلی جدید Core1RtmEmptyTest.Entities از نوع NET Core Class Library. است و صرفا حاوی کلاس‌های موجودیت‌های برنامه‌است.
اسمبلی جدید Core1RtmEmptyTest.DataLayer نیز از نوع NET Core Class Library. بوده و حاوی تعاریف Context برنامه، به همراه Migrations و تنظیمات آن خواهد بود.

تا اینجا با این نقل و انتقالات، نیاز است وابستگی‌های DataLayer را اصلاح کنیم. بنابراین فایل project.json آن‌را گشوده و به نحو ذیل تکمیل نمائید:
{
  "version": "1.0.0-*",

    "dependencies": {
        "Core1RtmEmptyTest.Entities": "1.0.0-*",
        "Microsoft.EntityFrameworkCore": "1.0.0",
        "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0",
        "Microsoft.Extensions.Configuration.Abstractions": "1.0.0",
        "NETStandard.Library": "1.6.0"
    },

  "frameworks": {
    "netstandard1.6": {
      "imports": "dnxcore50"
    }
  }
}
به این صورت ارجاعی به اسمبلی Core1RtmEmptyTest.Entities به پروژه اضافه شده‌است (تا کلاس Person در ApplicationDbContext شناسایی شود) به همراه وابستگی‌های EF و SQL Server که مورد نیاز Context برنامه هستند.
وابستگی Microsoft.Extensions.Configuration.Abstractions برای کار با IConfigurationRoot اضافه شده‌است (دسترسی به تنظیمات برنامه از طریق تزریق وابستگی‌ها).

به علاوه اکنون به پروژه‌ی وب اصلی مراجعه کرده و فایل project.json آن‌را جهت افزودن ارجاعاتی به این دو اسمبلی جدید، ویرایش کنید:
{
    "dependencies": {
        // same as before
        "Core1RtmEmptyTest.Entities": "1.0.0-*",
        "Core1RtmEmptyTest.DataLayer": "1.0.0-*"
    }
}
به این ترتیب Startup برنامه می‌تواند محل جدید کلاس ApplicationDbContext را شناسایی کند و برنامه کامپایل شود.


فعال سازی Migrations و قرار دادن فایل‌های آن در اسمبلی Core1RtmEmptyTest.DataLayer

در ادامه اگر مانند قسمت قبل بخواهیم مهاجرت‌ها را اضافه کنیم، به خطای ذیل خواهیم رسید:
D:\Prog\1395\Core1RtmEmptyTest\src\Core1RtmEmptyTest>dotnet ef migrations add InitialDatabase
Your target project 'Core1RtmEmptyTest' doesn't match your migrations assembly 'Core1RtmEmptyTest.DataLayer'.
Either change your target project or change your migrations assembly.
برای حل این مشکل، بجای اینکه دستور فوق را از مسیر src\Core1RtmEmptyTest صادر کنیم که همان ریشه‌ی اصلی پروژه‌ی وب است، اینبار باید دستور را از ریشه‌ی پروژه DataLayer صادر کنیم. اما اگر چنین کاری را انجام دهیم، پیام یافتن نشدن فایل اجرایی ابزارهای خط فرمان EF را دریافت می‌کنیم:
D:\Prog\1395\Core1RtmEmptyTest\src\Core1RtmEmptyTest.DataLayer>dotnet ef migrations add InitialDatabase
No executable found matching command "dotnet-ef"
علت اینجا است که باید مجددا فایل Core1RtmEmptyTest.DataLayer\project.json را گشوده و این ابزارها را در آن فعال کنیم:
{
     // same as before

    "tools": {
        "Microsoft.EntityFrameworkCore.Tools": {
            "version": "1.0.0-preview2-final",
            "imports": [
                "portable-net45+win8"
            ]
        }
    },

     // same as before
}
پس از فعال سازی ابزارهای EF در پروژه‌ی DataLayer، اکنون باز هم موفق به اجرای دستور فوق نخواهیم شد:
D:\Prog\1395\Core1RtmEmptyTest\src\Core1RtmEmptyTest.DataLayer>dotnet ef migrations add InitialDatabase
Could not invoke this command on the startup project 'Core1RtmEmptyTest.DataLayer'.
This preview of Entity Framework tools does not support commands on class library projects in ASP.NET Core and .NET Core applications.
عنوان می‌کند که پروژه‌ی startup را نمی‌تواند پیدا کند، برای حل این مشکل، دستور را به نحو ذیل ویرایش کنید:
 D:\Prog\1395\Core1RtmEmptyTest\src\Core1RtmEmptyTest.DataLayer>dotnet ef --startup-project ../Core1RtmEmptyTest/ migrations add InitialDatabase
Done. To undo this action, use 'dotnet ef migrations remove'
در اینجا با ذکر صریح startup-project، عملیات تولید فایل‌های Migrations با موفقیت انجام شدند:



اعمال کلاس‌های Migrations تولید شده به بانک اطلاعاتی

پس از تولید موفقیت آمیز فایل‌های مهاجرت، برای اعمال آن‌ها به بانک اطلاعاتی، اینبار نیز دستور را از همان پوشه‌ی DataLayer با پارامتر پروژه‌ی آغازین اجرا می‌کنیم:
D:\Prog\1395\Core1RtmEmptyTest\src\Core1RtmEmptyTest.DataLayer>dotnet ef --startup-project ../Core1RtmEmptyTest/ database update
Applying migration '13950527070105_InitialDatabase'.
Done.
در اینجا نیز ذکر پارامتر startup-project جهت اجرای موفقیت آمیز دستور الزامی است.


بنابراین به صورت خلاصه

- ابتدا قسمت tools تنظیمات پروژه‌ی data layer را برای فعال سازی دستورات خط فرمان EF ویرایش کنید.
- سپس از طریق خط فرمان به پوشه‌ی data layer وارد شوید. اینبار باید دستورات EF را از ریشه‌ی این پوشه، بجای پوشه‌ی اصلی برنامه صادر کرد.
- در اینجا دستورات افزودن مهاجرت‌ها و به روز رسانی بانک اطلاعاتی، همانند قبل هستند. فقط ذکر محل واقع شدن پوشه‌ی آغازین برنامه توسط پارامتر startup-project الزامی است.
‫۸ سال و ۲ ماه قبل، چهارشنبه ۲۷ مرداد ۱۳۹۵، ساعت ۱۷:۱۰
عالیجاه عالیجاه
بازخوردهای پروژه‌ها
خطا در اجرای برنامه

با عرض سلام و خسته نباشید من با اجرای برنامه با خطای زیر مواجه می‌شم (ویندوز 7 و دات نت فریمورک 4 رو هم نصب کردم) :

و همینطور در زمانی که برنامه را در ویژوال استودیو اجرا می‌کنم خطای زیر را می‌دهد:

Unknown build error, 'Could not load file or assembly 'file:///C:\Users\VAHID\Downloads\DNTProfiler-1.8.1129.0\DNTProfiler-1.8.1129.0\DNTProfiler\obj\Release\DNTProfiler.exe' or one of its dependencies. The module was expected to contain an assembly manifest.' 

‫۸ سال و ۷ ماه قبل، جمعه ۲۸ اسفند ۱۳۹۴، ساعت ۲۱:۴۶