- مخزن کد: RemovePdfLinks
- فایلهای اجرایی
IRISCMS.zip
https://github.com/MehdiSaeedifar/iriscms
EF Code First #12
- همچنین سورس کامل پروژه در انتهای بحث پیوست شده و یا در این مخزن کد نیز موجود است: UoW-Sample
منابع یافتن فایلهای تعاریف نوعها
- بزرگترین مخزن کد فایلهای تعاریف نوعهای TypeScript، در سایت Github و در مخزن کد DefinitelyTyped قابل مشاهده است:
https://github.com/DefinitelyTyped/DefinitelyTyped
- همچنین ابزار دیگری به نام «Typings type definition manager» نیز میتواند برای این منظور بکار رود.
- علاوه بر اینها، بستههای npm نیز میتوانند به همراه تعاریف فایلهای .d.ts باشند.
مفهوم Ambient Modules
پروژههای TypeScript عموما به همراه تعداد زیادی ماژول هستند. به این ترتیب هر ماژول نیاز به d.ts. فایل مخصوص خودش خواهد داشت که نگهداری آنها مشکل خواهد بود. به همین جهت یک Solution متشکل از تعدادی ماژول، میتواند تمام تعاریف نوعها را در یک تک فایل d.ts. نگهداری کند که به آن Ambient Module نیز میگویند. برای نمونه فایل d.ts. ذیل را درنظر بگیرید:
// cardCatalog.d.ts declare module "CardCatalog"{ export function printCard(callNumber: string): void; }
سپس برای استفادهی از این فایل d.ts. خواهیم داشت:
// app.ts /// <reference path="cardCatalog.d.ts" /> import * as catalog from "CardCatalog";
بررسی مخرن DefinitelyTyped
DefinitelyTyped مخزن کد عظیمی از فایلهای تعاریف نوعهای TypeScript است. هرچند دریافت این فایلها از مخزن کد Github آن مانند سایر فایلهای متداول آن سایت، اما چندین روش دیگر نیز برای کار با این مخزن کد وجود دارد:
- استفاده از NuGet. تقریبا تمام فایلهای d.ts. آن به صورت یک بستهی نیوگت مجزا نیز وجود دارند.
- استفاده از برنامهی tsd. این برنامه یا type definition manager، به صورت اختصاصی برای کار با این نوع فایلها طراحی شدهاست.
- استفاده از برنامهی typings. این برنامه نیز یک type definition manager دیگر است. مزیت آن کار با چندین منبع مجزای ارائهی فایلهای d.ts. است که DefinitelyTyped تنها یکی از آنها است.
یک مثال: دریافت مستقیم و افزودن فایل d.ts. مربوط به کتابخانهی جاوا اسکریپتی lodash از مخزن کد DefinitelyTyped
در ادامه قصد داریم فایل تعاریف نوعهای کتابخانهی معروف lodash را به پروژهی جدیدی در VSCode اضافه کنیم. قدم اول، نصب خود کتابخانه است؛ از این جهت که فایلهای d.ts.، فاقد هرگونه پیاده سازی هستند.
در مطلب «چرا TypeScript» نحوهی کار با npm را جهت به روز رسانی کامپایلر TypeScript پیش فرض VSCode ملاحظه کردید. در اینجا نیز از npm برای نصب lodash استفاده میکنیم:
ابتدا خط فرمان را گشوده و سپس به پوشهی پروژهی خود وارد شوید. سپس دو دستور ذیل را صادر کنید:
npm init -f npm install lodash --save
در ادامه به مخزن کد DefinitelyTyped وارد شده و پوشهی مربوط به lodash را با جستجو پیدا کنید:
https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/lodash
در این پوشه تنها به فایل lodash.d.ts آن نیاز است. روی لینک این فایل کلیک کرده و سپس در صفحهی باز شده، بر روی دکمهی raw کلیک نمائید. این فایل نهایی را در ریشهی پروژهی جاری ذخیره کنید.
https://github.com/DefinitelyTyped/DefinitelyTyped/raw/master/lodash/lodash.d.ts
اگر به انتهای فایل lodash.d.ts دقت کنید، تعریف ambient module آن چنین شکلی را دارد و export آن lo dash است:
declare module "lodash" { export = _; }
/// <reference path="lodash.d.ts" />
import * as _ from "lodash";
let snakeCaseTitle = _.snakeCase("test this"); console.log(snakeCaseTitle);
برای گرفتن خروجی از این مثال همانند قبل، ابتدا Ctrl+Shift+P را فشرده و سپس انتخاب tasks:Run build task< و در ادامه فشردن F5 برای اجرا برنامه، نیاز است صورت گیرند:
مدیریت فایلهای تعاریف نوعها با استفاده از tsd
tsd یک برنامهی خط فرمان است که کار یافتن و دریافت فایلهای d.ts. را ساده میکند. این برنامه منحصرا با مخزن کد DefinitelyTyped کار میکند و پس از دریافت هر فایل d.ts.، ارجاعی به آنرا در فایل tsd.json در ریشهی پروژه ذخیره میکند. همچنین یک تک فایل tsd.d.ts حاوی تعاریف Triple-Slash Directiveها را نیز تولید میکند که در ادامه میتوان تنها این فایل را به فایلهای مدنظر الحاق کرد.
البته باید دقت داشت که این برنامه در ابتدای سال 2016 منسوخ شده اعلام گردید و با برنامهی typings جایگزین شدهاست؛ هرچند هنوز هم مفید است و قابل استفاده.
روش دریافت tsd را در سایت definitelytyped.org میتوانید مشاهده کنید:
http://definitelytyped.org/tsd
نصب آن نیز به صورت یک بستهی npm است:
npm install tsd -g
https://github.com/Definitelytyped/tsd#readme
برای مثال برای نصب فایل تعاریف نوعهای lodash، ابتدا به پوشهی پروژه از طریق خط فرمان وارد شده و سپس دستور ذیل را صادر کنید:
D:\Prog\1395\VSCodeTypeScript>tsd install lodash --save
[ERR!] Error: connect ECONNREFUSED 10.10.34.36:443
اگر موفق به اجرای این دستور شدید، پوشهی جدید typings در ریشهی پروژه ایجاد خواهد شد. داخل آن فایل tsd.d.ts را نیز میتوان مشاهده کرد که حاوی تعاریف فایلهای نوعهای دریافت شدهاست. از این پس در ابتدای فایلهای ts، بجای تعریف جداگانهی این فایلها، تنها میتوان نوشت:
/// <reference path="./typings/tsd.d.ts" />
مدیریت فایلهای تعاریف نوعها با استفاده از typings
برنامهی typings نیز بسیار شبیه به برنامهی tsd است؛ با این تفاوت که منابع آن منحصر به مخزن کد definitelytyped نیست.
مخزن کد این برنامه در گیتهاب قرار دارد: https://github.com/typings/typings
و نصب آن با استفاده از دستور ذیل است:
npm install typings --global
typings install lodash --ambient --save
typings ERR! caused by Unable to connect to "https://raw.githubusercontent.com/DefinitelyTyped/DefinitelyTyped/299b5caa22876ef27dc8e9a5b7fd7bf93457b6f4/lodash/lodash-3.10.d.ts" typings ERR! caused by connect ECONNREFUSED 10.10.34.36:443
/// <reference path="./typings/main.d.ts" />
برای مثال پروژه "unhaddins" را در نظر بگیرید. این پروژه یک سری افزونه را جهت کار سادهتر با NHibernate ارائه داده است. برای مثال چگونه با WPF یا WCF و امثال آن بتوان به سادگی با NHibernate ارتباط برقرار کرد. این پروژه خروجی قابل دریافتی ندارد؛ به عبارتی یک سری سورس کد است. دریافت یک مخزن کد هم که از گوگل کد در این سمت مشکل است ... اما راه بهتری هم وجود دارد. یکی از خواص کار با سورس کنترلها، امکان تهیه یک clone از یک مخزن کد است. تمام پروژههای موجود در گوگل کد هم به این شکل با SVN در دسترس هستند:
برای نمونه، در سایت https://bitbucket.org ثبت نام کنید. سپس گزینه ایجاد یک مخزن جدید را انتخاب کرده:
و در صفحهی باز شده، گزینهی Import from Subversion را انتخاب کنید:
در اینجا Url خواسته شده باید شبیه به همان آدرس trunk فوق باشد و اگر تیک private فعال باشد (که هست)، دیگران امکان دسترسی به مخزن کد شما را نخواهند داشت. البته این تنظیم پس از دریافت، در برگهی Admin مخزن ایجاد شده نیز قابل تغییر است.
به علاوه سایت github.com هم هر چند بر اساس Git کار میکند، اما امکان تهیه یک کپی مطابق اصل از یک مخزن کد SVN را هم دارد؛ به شرح زیر:
یک اکانت رایگان در GitHub درست کنید. بعد یک مخزن خالی جدید را ایجاد کرده و در همان صفحه روی لینک Import a Subversion Repository کلیک کنید و آدرس svn مورد نظر را بدهید.
البته GitHub در دریافت پروژه unhaddins موفق عمل نکرد، اما bitbucket خیلی سریع کل آنرا دریافت نمود.
معرفی Bit Platform
وب اسمبلی چیست؟
<BlazorMode> ... </BlazorMode> <WebAppDeploymentType> ... </WebAppDeploymentType>
- وجود سیستم Exception handling در سرور و کلاینت (این موضوع به گونه ای بر اساس Best Practiceها پیاده سازی شده که اپلیکیشن را از بروز هر خطایی که بخواهد موجب Crash کردن برنامه شود ایزوله کرده)
- وجود سیستم User Authentication بر اساس JWT که شما در همان ابتدا که از این تمپلیت پروژه جدیدی میسازید صفحات SignIn ، SignUp را خواهید داشت.
- پکیج Bit Blazor UI که بالاتر درمورد آن صحبت کرده ایم از همان ابتدا در TodoTemplate نصب و تنظیم شده تا بتوانید به راحتی صفحات جدید با استفاده از آن بسازید.
- کانفیگ استاندارد Swagger در سمت سرور.
- ارسال ایمیل در روند SignUp.
- وجود خاصیت AutoInject برای سادهسازی تزریق وابستگی ها.
- و بسیاری موراد دیگر که در داکیومنتهای پروژه میتوانید آنهارا ببینید.
- شما میتوانید این پروژه را در گیتهاب مشاهده کنید.
- برای اشکالات یا قابلیت هایی که میخواهید برطرف شود Issue ثبت کنید.
- پروژه را Fork کنید و Star دهید.
- ایشوهایی که وجود دارد را برطرف کنید و Pull Request ارسال کنید.
- برای در جریان بودن از روند توسعه در جلسات برنامه ریزی (Planning Meeting) و گزارشات هفتگی (Standup Meeting ) که همه اینها در Microsoft Teams برگزار میشود شرکت کنید.
نیاز به یک Dispatcher برای تعامل با بیش از یک مخزن حالت
در اینجا برای نمونه دو مخزن حالت تعریف شدهاند؛ اما روش تعامل با این مخازن حالت، دیگر مانند قبل نیست. برای نمونه در اثر تعامل یک کاربر با View ای خاص، رخدادی صادر شده و اینبار مدیریت این رخداد توسط یک Action (که عموما یک پیام رشتهای است)، به Dispatcher مرکزی ارسال میشود (و نه مستقیما به مخزن حالت خاصی). اکنون این Dispatcher، اکشن رسیده را به مخازن کد مشترک به آن ارسال میکند تا عمل متناسب با آن اکشن درخواستی را انجام دهند. مابقی آن همانند قبل است که پس از تغییر حالت در هر کدام از مخازن حالت، کار به روز رسانی UI، در کامپوننتهای مشترک صورت خواهد گرفت. بدیهی است در اینجا مخازن حالت، مجاز به صرفنظر کردن از یک اکشن خاص هستند و الزامی به پیاده سازی آن ندارند. هدف اصلی این است که اگر اکشنی قرار بود در تمام مخازن حالت پیاده سازی شود و حالتهای آنها را تغییر دهد، روشی را برای مدیریت آن داشته باشیم.
بنابراین اگر به این الگوی جدید دقت کنید، چیزی نیست بجز یک الگوی Observer دو سطحی:
الف) Dispatcher ای (Subject) که مشترکهایی را مانند مخازن حالت دارد (Observers).
ب) مخازن حالتی (Subjects) که مشترکهایی را مانند کامپوننتها دارند (Observers).
اگر پیشتر با React کار کرده باشید، این الگو را تحت عناوینی مانند Flux و یا Redux میشناسید و در اینجا میخواهیم پیاده سازی #C آنرا بررسی کنیم:
در الگوی Flux، در اثر تعامل یک کاربر با کامپوننتی، اکشنی به سمت یک Dispatcher ارسال میشود. سپس Dispatcher این اکشن را به مخزن حالتی جهت مدیریت آن ارسال میکند که در نهایت سبب تغییر حالت آن شده و به روز رسانی UI را در پی خواهد داشت.
پیاده سازی یک Dispatcher برای تعامل با بیش از یک مخزن حالت
پیش از هر کاری نیاز است قالب اکشنهای ارسالی را که قرار است توسط مخازن حالت مورد پردازش قرار گیرند، مشخص کنیم:
namespace BlazorStateManagement.Stores { public interface IAction { public string Name { get; } } }
namespace BlazorStateManagement.Stores.CounterStore { public class IncrementAction : IAction { public const string Increment = nameof(Increment); public string Name { get; } = Increment; } public class DecrementAction : IAction { public const string Decrement = nameof(Decrement); public string Name { get; } = Decrement; } }
پس از تعریف ساختار یک اکشن، اکنون نوبت به پیاده سازی راه حلی برای ارسال آن به تمام مخازن حالت برنامه است:
using System; namespace BlazorStateManagement.Stores { public interface IActionDispatcher { void Dispatch(IAction action); void Subscribe(Action<IAction> actionHandler); void Unsubscribe(Action<IAction> actionHandler); } public class ActionDispatcher : IActionDispatcher { private Action<IAction> _actionHandlers; public void Subscribe(Action<IAction> actionHandler) => _actionHandlers += actionHandler; public void Unsubscribe(Action<IAction> actionHandler) => _actionHandlers -= actionHandler; public void Dispatch(IAction action) => _actionHandlers?.Invoke(action); } }
این سرویس را نیز با طول عمر Scoped به سیستم تزریق وابستگیهای برنامه معرفی میکنیم که سبب میشود تا پایان عمر برنامه (بسته شدن مرورگر یا ریفرش کامل صفحهی جاری)، در حافظه باقی مانده و وهله سازی مجدد نشود. به همین جهت تزریق آن در مخازن حالت مختلف برنامه، دقیقا حالت یک Dispatcher اشتراکی را پیدا خواهد کرد.
namespace BlazorStateManagement.Client { public class Program { public static async Task Main(string[] args) { var builder = WebAssemblyHostBuilder.CreateDefault(args); // ... builder.Services.AddScoped<IActionDispatcher, ActionDispatcher>(); // ... } } }
استفاده از IActionDispatcher در مخازن حالت برنامه
در ادامه میخواهیم مخازن حالت برنامه را تحت کنترل سرویس IActionDispatcher قرار دهیم تا کاربر بتواند اکشنی را به Dispatcher ارسال کند و سپس Dispatcher این درخواست را به تمام مخازن حالت موجود، جهت بروز واکنشی (در صورت نیاز)، اطلاعات رسانی نماید.
برای این منظور سرویس ICounterStore قسمت قبل ، به صورت زیر تغییر میکند که اینترفیس IDisposable را پیاده سازی کرده و همچنین دیگر به همراه متدهای عمومی افزایش و یا کاهش مقدار نیست:
using System; namespace BlazorStateManagement.Stores.CounterStore { public interface ICounterStore : IDisposable { CounterState State { get; } void AddStateChangeListener(Action listener); void BroadcastStateChange(); void RemoveStateChangeListener(Action listener); } }
using System; namespace BlazorStateManagement.Stores.CounterStore { public class CounterStore : ICounterStore { private readonly CounterState _state = new(); private bool _isDisposed; private Action _listeners; private readonly IActionDispatcher _actionDispatcher; public CounterStore(IActionDispatcher actionDispatcher) { _actionDispatcher = actionDispatcher ?? throw new ArgumentNullException(nameof(actionDispatcher)); _actionDispatcher.Subscribe(HandleActions); } private void HandleActions(IAction action) { switch (action) { case IncrementAction: IncrementCount(); break; case DecrementAction: DecrementCount(); break; } } public CounterState State => _state; private void IncrementCount() { _state.Count++; BroadcastStateChange(); } private void DecrementCount() { _state.Count--; BroadcastStateChange(); } public void AddStateChangeListener(Action listener) => _listeners += listener; public void RemoveStateChangeListener(Action listener) => _listeners -= listener; public void BroadcastStateChange() => _listeners.Invoke(); public void Dispose() { Dispose(disposing: true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if (!_isDisposed) { try { if (disposing) { _actionDispatcher.Unsubscribe(HandleActions); } } finally { _isDisposed = true; } } } } }
- با توجه به اینکه CounterStore یک سرویس ثبت شدهی در سیستم است، میتواند از مزیت تزریق سایر سرویسها در سازندهی خودش بهرهمند شود؛ مانند تزریق سرویس جدید IActionDispatcher.
- پس از تزریق سرویس جدید IActionDispatcher، متدهای Subscribe آنرا در سازندهی کلاس و Unsubscribe آنرا در حین Dispose سرویس، فراخوانی میکنیم. البته فراخوانی و یا پیاده سازی Unsubscribe و Dispose در اینجا غیرضروری است؛ چون طول عمر این کلاس با طول عمر برنامه یکی است.
- بر اساس این الگوی جدید، هر اکشنی که به سمت Dispatcher مرکزی ارسال میشود، در نهایت به متد HandleActions یکی از مخازن حالت تعریف شده، خواهد رسید:
private void HandleActions(IAction action) { switch (action) { case IncrementAction: IncrementCount(); break; case DecrementAction: DecrementCount(); break; } }
@inject ICounterStore CounterStore @code { private void IncrementCount() { CounterStore.IncrementCount(); }
- ابتدا در انتهای فایل Client\_Imports.razor، فضای نام سرویس جدید IActionDispatcher را اضافه میکنیم:
@using BlazorStateManagement.Stores
// ... @inject IActionDispatcher ActionDispatcher @code { private void IncrementCount() { ActionDispatcher.Dispatch(new IncrementAction()); }
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: BlazorStateManagement-Part-2.zip
در تصویر بالا هری و سالی، یک کپی از مخزن موجود را گرفته و سپس هر کدام جداگانه بر روی کپیهای خودشان مشغول به کار میشوند. سپس سالی کارش را زودتر به اتمام رسانده و مخزن را به روز میکند. بعد از آن، هری هم کارش به پایان میرسد و قصد به روز کردن مخزن را دارد ولی سیستم به او اجازه این کار را نمیدهد؛ چون این مخزن آن مخزن نیست که هری قبلا از آن کپی گرفته است. آن مخزن بعد از به روزرسانی سالی تغییر یافته است. پس او مجبور است تا تغییرات جدید مخزن را دریافت کرده و کپی خودش را به روز کند. پس از آن میتواند کپی خودش را بر روی مخزن اعمال کند (با فرض اینکه تغییرات جدید هیچ تصادمی با تغییراتی که روی کپی خودش اعمال کرده است ندارند).
سناریو بالا با احتساب وجود تصادم
اگر همین سناریوی بالا را فرض کنیم که تغییراتی که هری روی فایلها داده است همان تغییراتی است که سالی قبلا روی مخزن اصلی روی همان فایلها اعمال کرده است، آیا در این حالت دریافت به روزرسانیهای جدید باعث ایجاد تصادم میشود؟
هری درخواست ادغام آخرین تغییرات مخزن را با کپی خودش میکند. از آنجا که فایل A تصادم دارد یک فلگ flag از این وضعیت میگیرد. حال هری میتواند تفاوتهای ایجاد شده را ببیند و بین آنها یکی را انتخاب کند. در این وضعیت هری همپوشانیهای کدها را برطرف میکند و شاید هم بحثی در مورد این تصادم با سالی داشته باشد تا بهترین تغییر کد انتخاب گردد و نهایتا به روشی کاملا امن و مطمئن، با مخزن اصلی ادغام میشود.
پی نوشت : نرم افزارها نمیتوانند موضوع تصادم را به طور خودکار اعمال کنند. از آنجا که نیاز به تصمیم گیری و درک هوشمند دارد این کار به صورت انسانی باید بررسی گردد.
Roslyn #4
Compilation API، یک abstraction سطح بالا از فعالیتهای کامپایل Roslyn است. برای مثال در اینجا میتوان یک اسمبلی را از Syntax tree موجود، تولید کرد و یا جایگزینهایی را برای APIهای قدیمی CodeDOM و Reflection Emit ارائه داد. به علاوه این API امکان دسترسی به گزارشات خطاهای کامپایل را میسر میکند؛ به همراه دسترسی به اطلاعات Semantic analysis. در مورد تفاوت Syntax tree و Semantics در قسمت قبل بیشتر بحث شد.
با ارائهی Roslyn، اینبار کامپایلرهای خط فرمان تولید شده مانند csc.exe، صرفا یک پوسته بر فراز Compilation API آن هستند. بنابراین دیگر نیازی به فراخوانی Process.Start بر روی فایل اجرایی csc.exe مانند یک سری کتابخانههای قدیمی نیست. در اینجا با کدنویسی، به تمام اجزاء و تنظیمات کامپایلر، دسترسی وجود دارد.
کامپایل پویای کد توسط Roslyn
برای کار با API کامپایل، سورس کد، به صورت یک رشته در اختیار کامپایلر قرار میگیرد؛ به همراه تنظیمات ارجاعاتی به اسمبلیهایی که نیاز دارد. سپس کار کامپایلر شروع خواهد شد و شامل مواردی است مانند تبدیل متن دریافتی به Syntax tree و همچنین تبدیل مواردی که اصطلاحا به آنها Syntax sugars گفته میشود مانند خواص get و set دار به معادلهای اصلی آنها. در اینجا کار Semantic analysis هم انجام میشود و شامل تشخیص حوزهی دید متغیرها، تشخیص overloadها و بررسی نوعهای بکار رفتهاست. در نهایت کار تولید فایل باینری اسمبلی، از اطلاعات آنالیز شده صورت میگیرد. البته خروجی کامپایلر میتواند اسمبلیهای exe یا dll، فایل XML مستندات اسمبلی و یا فایلهای .netmudule و .winmdobj مخصوص WinRT هم باشد.
در ادامه، اولین مثال کار با Compilation API را مشاهده میکنید. پیشنیاز اجرای آن همان مواردی هستند که در قسمت قبل بحث شدند. یک برنامهی کنسول سادهی .NET 4.6 را آغاز کرده و سپس بستهی نیوگت Microsoft.CodeAnalysis را در آن نصب کنید. در ادامه کدهای ذیل را به پروژهی آماده شده اضافه کنید:
static void firstCompilation() { var tree = CSharpSyntaxTree.ParseText("class Foo { void Bar(int x) {} }"); var mscorlibReference = MetadataReference.CreateFromFile(typeof (object).Assembly.Location); var compilationOptions = new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary); var comp = CSharpCompilation.Create("Demo") .AddSyntaxTrees(tree) .AddReferences(mscorlibReference) .WithOptions(compilationOptions); var res = comp.Emit("Demo.dll"); if (!res.Success) { foreach (var diagnostic in res.Diagnostics) { Console.WriteLine(diagnostic.GetMessage()); } } }
متدهای تعریف شده توسط Compilation API به یک s جمع، ختم میشوند؛ به این معنا که در اینجا در صورت نیاز، چندین Syntax tree یا ارجاع را میتوان تعریف کرد.
پس از وهله سازی Compilation API و تنظیم آن، اکنون با فراخوانی متد Emit، کار تولید فایل اسمبلی نهایی صورت میگیرد. در اینجا اگر خطایی وجود داشته باشد، استثنایی را دریافت نخواهید کرد. بلکه باید خاصیت Success نتیجهی آنرا بررسی کرده و درصورت موفقیت آمیز نبودن عملیات، خطاهای دریافتی را از مجموعهی Diagnostics آن دریافت کرد. کلاس Diagnostic، شامل اطلاعاتی مانند محل سطر و ستون وقوع مشکل و یا پیام متناظر با آن است.
معرفی مقدمات Semantic analysis
Compilation API به اطلاعات Semantics نیز دسترسی دارد. برای مثال آیا Type A قابل تبدیل به Type B هست یا اصلا نیازی به تبدیل ندارد و به صورت مستقیم قابل انتساب هستند؟ برای درک بهتر این مفهوم نیاز است یک مثال را بررسی کنیم:
static void semanticQuestions() { var tree = CSharpSyntaxTree.ParseText(@" using System; class Foo { public static explicit operator DateTime(Foo f) { throw new NotImplementedException(); } void Bar(int x) { } }"); var mscorlib = MetadataReference.CreateFromFile(typeof (object).Assembly.Location); var options = new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary); var comp = CSharpCompilation.Create("Demo").AddSyntaxTrees(tree).AddReferences(mscorlib).WithOptions(options); // var res = comp.Emit("Demo.dll"); // boxing var conv1 = comp.ClassifyConversion( comp.GetSpecialType(SpecialType.System_Int32), comp.GetSpecialType(SpecialType.System_Object) ); // unboxing var conv2 = comp.ClassifyConversion( comp.GetSpecialType(SpecialType.System_Object), comp.GetSpecialType(SpecialType.System_Int32) ); // explicit reference conversion var conv3 = comp.ClassifyConversion( comp.GetSpecialType(SpecialType.System_Object), comp.GetTypeByMetadataName("Foo") ); // explicit user-supplied conversion var conv4 = comp.ClassifyConversion( comp.GetTypeByMetadataName("Foo"), comp.GetSpecialType(SpecialType.System_DateTime) ); }
برای مثال نتیجهی بررسی آخرین تبدیل انجام شده در تصویر فوق مشخص است. با توجه به تعریف public static explicit operator DateTime در سورس کد مورد آنالیز، این تبدیل explicit بوده و همچنین user defined. به علاوه متدی هم که این تبدیل را انجام میدهد، مشخص کردهاست.