<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های آرمین شعیبی</title>
        <link>https://virgool.io/feed/@ArminSh</link>
        <description>Software Engineer At Alibaba.ir</description>
        <language>fa</language>
        <pubDate>2026-06-07 04:38:01</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/421184/avatar/2jIKgR.png?height=120&amp;width=120</url>
            <title>آرمین شعیبی</title>
            <link>https://virgool.io/@ArminSh</link>
        </image>

                    <item>
                <title>آموزش gRPC در ASP.NET Core - قسمت دوم</title>
                <link>https://virgool.io/dotnetzoom/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-grpc-%D8%AF%D8%B1-aspnet-core-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-rtafqie0sxa0</link>
                <description>آموزش gRPC در ASP.NET Core - قسمت دوم https://vrgl.ir/U1mV1 در این قسمت میخواهیم با تعریف message و service و rpc method آشنا بشیم، همچنین انواع Data Type ها در Protocol Buffer یاد میگیریم.و فایل های ایجاد شده توسط Protobuf Compiler را به صورت کامل بررسی میکنیم.تعریف و استفاده از enum ها را هم یاد میگیریم.به طور کلی 2 نوع رویکرد (approach) برای ساخت و طراحی API وجود دارد.Code FirstDesign First (Contract First)فریمورک gRPC  برای ساخت API های RPC از رویکرد دوم یا همان contract-first استفاده میکند، این رویکرد نسبت به code-first جدیدتر، بهتر، پایدارتر و تمیزتر است.همانطور که در قسمت اول گفته شد:در ابتدا باید برای هر سرویس gRPC یک قرارداد ایجاد کنیم، این قرارداد در یک فایل با فرمت proto. قرار میگیرد. از این قرارداد (contract) میتوان به چند شکل مختلف استفاده کرد:به شکل مستند (document): فایل های proto. دارای syntax آسان و به زبان انسان نزدیک هستند، پس در نتیجه با یک نگاه به این فایل ها میتوان متوجه شد که یک سرویس gRPC چه متدهایی را ارائه میکند.به شکل Blue Print: فایل های proto. را میتوانیم با استفاده از Protobuf Compiler به زبان های برنامه نویسی مختلف Compile و از آن ها در برنامه خودمان استفاده کنیم.پس فایل های proto. در آن واحد هم Document و هم Blue Print هستند.این فایل ها را دقیقا مثل یک Interface سی شارپی فرض کنید.به طور معمول یک فایل proto:دارای چند Message است، که به عنوان ورودی و خروجی متد ها قرار می گیرند.دارای یک Service است، که امضاء متد های RPC در آن قرار می گیرند.در ابتدا یک پروژه ASP.NET Core میسازیم.بعد از اینکه پروژه ساخته شد، باید در آن پکیج Grpc.AspNetCore را نصب کنیم.Install-Package Grpc.AspNetCore -Version 2.35.0 /* Package Manager Console */
dotnet add package Grpc.AspNetCore --version 2.35.0 /* .NET CLI  */سپس یک Folder به نام Protos در پروژه ایجاد کنید و در آن یک Protocol Buffer File به نام ticket_api.proto بسازید. (نام فایل حتما به صورت lower_snake_case باشد.)در این مرحله که فایل ticket_api.proto ساخته شد، در آن 2 خط کد مشاهده میکنیم.خط اول مربوط به ورژن Protocol Buffers است و حتما باید مقدارش مساوی با proto3 باشد.خط دوم به ما اجازه میدهد namespace کلاس هایی که بعدا از روی این فایل ticket_api.proto ساخته میشوند را به صورت صریح مشخص کنیم. https://gist.github.com/ArminShoeibi/56fa55dade70906fedf7d38c8f497ab1 در فایل های proto. ای که قرار است برای زبان #C کامپایل شوند میتوانیم دو option قرار دهیم.option csharp_namespaceoption optimize_for https://gist.github.com/ArminShoeibi/1548f9f96b19f22de328ca09cb84dd0b پیام ( Message ) چیست ؟پیام را دقیقا مثل یک DTO فرض کنید، وقتی یک message تعریف میکنیم، در اخر توسط Protobuf Compiler تبدیل به یک کلاس معمولی #C می شود.Message ها در ورودی و خروجی متدهای RPC استفاده می شوند، در واقع داده ها را بین Client و Server جا به جا میکنند.پیام (message) فقط می تواند دارای فیلد باشد و از خود هیچ رفتاری ندارد.نحوه تعریف Message نوشتن کلمه کلیدی messageتخصیص یک نام (Identifier) به آن (به صورت PascalCase نوشته شود.)نوشتن پراپرتی (فیلد) های مورد نیاز و تخصیص شماره به آن ها (نام فیلد ها به صورت lower_snake_case نوشته شود.) https://gist.github.com/ArminShoeibi/ea5fdf68478cbf2223cbb20cd9d71690 شماره فیلد (Field Number) چیست ؟شماره فیلد یکی از مهم ترین بخش های Protocol Buffer است، تخصیص شماره به فیلد های یک message اجباری است.وقتی که داده هایمان توسط Protocol Buffer به آرایه ای از byte ها(binary format) سریالایز میشوند، از این اعداد برای شناسایی فیلد ها استفاده میشود.در JSON  اشیا به صورت Key-Value Pair هستند و Key ها هم به صورت string هستند، ولی در proto به جای استفاده از string به عنوان Key از اعداد استفاده میشود به دلیل حجم کمتر.شماره فیلد های 1 تا 15 حجمشان یک byte است، در هر message از شماره 1 تا 15 را باید  به فیلد های پر مصرف و پر کاربرد اختصاص بدهیم. برای مثال در یک message بیست (20) فیلد داریم، بهتر است که حتما شماره 1 تا 15 را به فیلدهایی اختصاص بدهیم که بیشتر در Client و Server استفاده میشوند، برای مثال 5 فیلد از آن 20 فیلد مربوط به Audit هستند و خیلی کم استفاده میشوند یا اصلا استفاده نمیشوند ولی در message وجود دارند، در این صورت نباید شماره 1 تا 15 را به آن فیلد های Audit اختصاص بدهیم.چون شماره فیلد های 1 تا 15 حجمشان یک byte است بهتر است حتما فیلد های پر استفاده از این اعداد استفاده کنند. شماره فیلدهای 16 تا 2047  حجم شان دو byte است. از عدد های بالاتر هم می توانید استفاده کنید ولی پیشنهاد میشود اینکار را نکنید.انواع Data Type های Value Type در Messageبه طور پیشفرض پانزده  Data Type از نوع Value Type در فایل proto. وجود دارد و ما میتوانیم از آن ها برای فیلد هایمان استفاده کنیم.در تصویر پایین مشاهده میکنید که 15 عدد Data Type از نوع Value Type در یک فایل proto. قابل استفاده است، و این 15 عدد در آخر به 9 عدد Data Type در سی شارپ تبدیل میشوند.در کد و تصویر  زیر همانطور که مشاهده میکنید، از هر پانزده Data Type موجود در یک message استفاده کردیم. https://gist.github.com/ArminShoeibi/0204502b76cc3ec2fcdd34c6cd92c035 &quot;محمد جواد ابراهیمی&quot;:در اینجا چند نکته درباره نوع داده های protobuf حائز اهمیت هست:1️⃣ نوع های unsigned که تکلیفشون معلومه، فقط اعداد مثبت رو قبول میکنن مثلا نوع uint32 به uint درسی شارپ ترجمه میشه و فقط میتونه اعداد مثبت رو داشته باشه.2️⃣ نوع int32 به int در سی شارپ ترجمه میشه و میتونه هم اعداد منفی و هم مثبت رو داشته باشه ولی برای اعداد منفی غیر بهینه عمل میکنه چرا که اعداد منفی رو به 10 بایت انکود میکنه که مشابه یک عدد مثبت خیلی بزرگ رفتار میشه باهاش.3️⃣ نوع sint32 به int در سی شارپ ترجمه میشه و میتونه هم اعداد منفی و هم مثبت رو داشته باشه ولی برای اعداد منفی خیلی بهتر عمل میکنه چرا که از الگوریتم ZigZag استفاده میکنه و اعداد منفی رو به اعداد مثبت زیگ زاگی انکود میکنه به این صورت که عدد 1- میشه 1؛ عدد 1 میشه 2؛ عدد 2- میشه 3؛ عدد 3+ میشه 41-  ---&gt;  11+  ---&gt;  22-  ---&gt;  32+  ---&gt;  4...2147483647+  ---&gt;  42949672942147483648-  ---&gt;  4294967295در نتیجه برای اعداد منفی فضا و پردازش کمتری رو میطلبه ولی برای اعداد مثبت فضا و پردازش بیشتری رو میطلبه? نتیجه گیری:✅ از uint32  استفاده کنید اگر اعداد تون  &quot;فقط مثبت&quot; هستند.✅ از sint32 استفاده کنید اگر به مثبت و منفی نیاز دارید ولی اعداد تون &quot;معمولا منفی&quot; هستند.✅ از int32 استفاده کنید اگر به مثبت و منفی نیاز دارید ولی اعداد تون &quot;به ندرت منفی&quot; هستند.?نکته:✅ همین قضیه برای int64 و sint64 و uint64 هم صدق میکنه.✅ نوع های fixed هم طولشون ثابت هست (بر خلاف نوع های غیر fixed که طولشون متغیر varint هست) مثلا نوع fixed32 و sfixed32 همیشه 4 بایت اشغال میکنند و نوع های fixed64 و sfixed64 هم همیشه 8 بایت.سرویس (Service) چیست ؟سرویس (service) را دقیقا مثل یک Interface سی شارپی فرض کنید که فقط در آن امضای Method ها را قرار می دهیم، و فقط هم محل قرارگیری  امضای Method هایمان است.به متد هایی که در سرویس قرار میگیرند RPC Method می گویند.نحوه تعریف سرویس (service)نوشتن کلمه کلیدی serviceتخصیص یک نام به آن (به صورت PascalCase نوشته شود.)نوشتن متدهای مورد نیاز (همراه با پیشوند rpc) https://gist.github.com/ArminShoeibi/d9892d24254396f1c703057415204043 حالا که message  و service و rpc method های مورد نیاز را ساختیم، باید این فایل proto. را به صورت Server ای Compile کنیم.? نکته: یک فایل proto. را میتوان به 2 صورت Compile کرد.1. کامپایل مخصوص Client2. کامپایل مخصوص Serverکامپایل فایل ticket_api.proto به صورت Server و بررسی فایل های ایجاد شده توسط protoc در پروژه Serverابتدا وارد Connected Services پروژه GrpcServer می شویم.سپس بر روی دکمه Add کلیک میکنیم.و در مرحله بعدی گزینه gRPC را انتخاب میکنیم.سپس بر روی دکمه Browse کلیک میکنیم و فایل ticket_api.proto را در FileDialog انتخاب میکنیم.و بعد نوع کلاس هایی که قرار است توسط protoc ایجاد شوند را بر روی Server قرار میدهیم.در مرحله بعدی بر روی دکمه Close کلیک میکنیم و سپس پروژه را Save میکنیم.بعد از اینکه عمل Save را انجام دادید باید پروژه مورد نظر یا سولوشن را Build کنید.در مراحل بالا دقیقا چه کاری کردیم ؟در تصاویر بالا فایل ticket_api.proto را به صورت Server برای پروژه مان Compile کردیم و در این حین در پشت صحنه اتفاق هایی افتاد.مقدار Build Action فایل ticket_api.proto به Protobuf Compiler تغییر کرد.کلاس هایی از روی این فایل مخصوص به Grpc Server تولید شد.حالا بعد از هر بار تغییر فایل ticket_api.proto و Build کردن پروژه، کلاس های تولید شده آپدیت و ویرایش میشوند.در این مرحله میخواهیم فایل ها و کلاس هایی که توسط کامپایل شدن فایل ticket_api.proto ساخته شدند را بررسی کنیم.در ابتدا بر روی پروژه کلیک چپ کنید و سپس گزینه Show All Files را Enable کنید.سپس در Solution Explorer وارد مسیر obj/Debug/net5.0/Protos شوید.مشاهده میکنید که 2 فایل در آن با فرمت cs. وجود دارد.فایل اول بدون پسوند Grpc که محل قرارگیری message ها است، message ها توسط protoc به کلاس های معمولی سی شارپ تبدیل میشوند.فایل دوم با پسوند Grpc که محل قرارگیری service است و متد CreateTicket در آن قرار گرفته است.نام این 2 فایل از روی نام ticket_api.proto برداشته شده است، Protobuf Compiler این نام را از فرمت lower_snake_case به PascalCase تغییر داده و از آن برای این 2 فایل سی شارپی استفاده کرده است.وقتی که یک فایل proto. مخصوص به Server کامپایل میشود، متدهای قرار گرفته در service را باید حتما override و سپس Implement کنیم.این متد ها در یک کلاسی به نام ServiceName+Base قرار گرفته اند، دقیقا protoc نام Service را بر میدارد و یک پسوند Base به آن اضافه میکند.در اینجا سرویسی که در فایل ticket_api.proto قرار داده بودیم نامش TicketService بود و الان باید توقع این را داشته باشیم که protoc یک کلاس به نام TicketServiceBase برای ما ایجاد کرده باشد. پس همیشه در سمت سرور باید کلاسی که نامش از نام سرویس + Base تشکیل شده است را استفاده کنیم.تا الان چه کارهایی انجام دادیم:ساخت پروژه ASP.NET Coreنصب پکیج Grpc.AspNetCoreایجاد فایل ticket_api.proto تعریف message و serviceکامپایل فایل ticket_api.proto به صورت Serverکامپایل فایل ticket_api.proto به صورت Client و بررسی فایل های ایجاد شده توسط protoc در پروژه Clientابتدا در همان Solution یک پروژه Console میسازیم.به این پروژه پسوند GrpcClient را میدهیم.سپس باید در پروژه کنسولی که به عنوان GrpcClient ساختیم، 3 عدد پکیج نصب کنیم.Install-Package Grpc.Tools -Version 2.35.0NuGet Gallery | Grpc.Net.ClientFactory 2.35.0NuGet Gallery | Google.Protobuf 3.14.0Install-Package Grpc.Tools -Version 2.35.0
Install-Package Google.Protobuf -Version 3.14.0
Install-Package Grpc.Net.ClientFactory -Version 2.35.0در این مرحله باید فایل ticket_api.proto را هم در این پروژه به صورت Client کامپایل کنیم، دقیقا طبق همان مراحل بالا از بخش Connected Service این فایل را کامپایل میکنیم.وقتی که مراحل بالا انجام شد، یک Link از فایل ticket_api.proto که در پروژه GrpcServer قرار گرفته بود به پروژه GrpcClient ایجاد میشود.می توانید این Link را در فایل csproj پروژه GrpcClient مشاهده کنید.راه دیگری هم وجود دارد که می توانیم در ابتدا یک کپی از فایل ticket_api.proto بگیریم و سپس یک Folder به نام Protos در پروژه GrpcClient بسازیم و سپس آن فایل را paste کنیم، و بعد از روی آن فایل مراحل Connected Service را انجام دهیم.خب بعد از اینکه مراحل Connected Service تمام شد، و یک link از فایل ticket_api.proto در پروژه GrpcClient ایجاد شد، سپس باید فایل های ایجاد شده توسط protoc را بررسی کنیم.اول Show All Files را برای پروژه GrpcClient را Enable کنید.سپس همانطور که مشاهده میکنید، همان 2 فایلی که در پروژه Server ایجاد شدند، در این پروژه هم ایجاد شدند دقیقا با همان نام و فرمت.فایل اول دارای Message ها است.فایل دوم دارای service  است.فایل دوم یعنی TicketApiGrpc دارای یک کلاس است که نامش از نام سرویس + Client تشکیل میشود. یعنی service ما که در فایل ticket_api.proto قرار گرفته بود نامش TicketService بود، الان باید توقع داشته باشیم که کلاسی به نام TicketServiceClient را برای ما ایجاد شده باشد.وظیفه Client این است که یک نمونه از کلاس TicketServiceClient بسازد و متدهای موجود در آن را فراخوانی کند و از آن ها استفاده کند.خب کل فرق کامپایل به صورت Client و به صورت Server رو میتونید در تصویر زیر مشاهده کنید.بررسی Enumeration در Protobufدر فایل proto. می توانیم Enum های دلخواه خودمان را تعریف کنیم و از آن ها به عنوان یک Data Type برای فیلد هایمان استفاده کنیم.نحوه تعریف Enumنوشتن کلمه کلیدی enumتخصیص نام به enum صورت PascalCaseتعریف constant ها به صورت UPPERCASE و تخصیص عدد به آن هانکته: Enum را می توانیم در 2 جا تعریف کنیم.1. در داخل message2. در بیرون messageاگر یک enum فقط قرار است در داخل یک message استفاده شود، پس آن را در داخل همان message تعریف می کنیم.ولی اگر قرار است در چند message از آن استفاده بشود آن را در بیرون message ها تعریف میکنیم.در کد و تصویر زیر مشاهده می کنید که TicketStatus را بیرون از message ها تعریف کردیم و از آن در داخل TicketCreationResultDto استفاده کردیم.در تصویر و کد زیر مشاهده میکنید که TicketStatus را در داخل message تعریف کردیم.همانطور که در زبان #C می توانیم  در هر enum چند فیلد با نام های مختلف و مقدار مساوی داشته باشیم، می توانیم همین رفتار را  هم در enum های Protobuf  داشته باشیم.ولی باید این ویژگی را در enum های Protobuf به صورت صریح فعال کنیم.سورس کد پروژه: https://github.com/ArminShoeibi/DNZ.TicketingSystem مقالات بیشتر در کانال دات نت زومhttps://t.me/DotNetZoom</description>
                <category>آرمین شعیبی</category>
                <author>آرمین شعیبی</author>
                <pubDate>Tue, 09 Feb 2021 22:43:04 +0330</pubDate>
            </item>
                    <item>
                <title>آموزش gRPC در ASP.NET Core - قسمت اول</title>
                <link>https://virgool.io/dotnetzoom/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-grpc-%D8%AF%D8%B1-aspnet-core-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-or6ti2wsqb33</link>
                <description>آموزش gRPC در ASP.NET Coreجی آر پی سی(gRPC) چیست ؟جی آر پی سی(gRPC) یک فریمورک رایگان، قدرتمند، مدرن، پر سرعت و متن بازِ RPC است.به طور کلی 3 نوع مدل برای طراحی API وجود دارد.SOAPRESTRPC (Remote procedure call)فریمورک gRPC به ما اجازه میدهد که API هایی از نوع RPC بسازیم.این  نوع API ها به Client ها اجازه میدهند که متدهای قرار گرفته در Server را در برنامه خودشان فراخوانی کنند به شکلی که انگار متدها واقعا در برنامه خودشان پیاده سازی شده است.مثال:در تصویر زیر برنامه Server دارای یک متد به نامGetOrder است.public Order GetOrder(int num);حالا gRPC چیکار میکنه دقیقا ؟ اجازه میده به Client ها که دقیقا این متد رو داخل برنامه خودشون فراخوانی کنن و از خروجی اش استفاده کنن.مکانیزم RPCمزایای فریمورک gRPCتسهیل ایجاد ارتباط بین Microservice ها.پر سرعت است.استفاده از HTTP/2 به عنوان Transfer Protocol.پشتیبانی از Client Streamingپشتیبانی از Server Streamingپشتیبانی از Bidirectional Streamingاز XML و JSON سریع تر، سبک تر، ساده تر است.به دلیل Serialize کردن داده ها به binary data format حجم Payload خیلی کمی دارد.امکان استفاده در بیشتر زبان های برنامه نویسی( Polyglot )پروتکل بافر (Protocol Buffer) چیست ؟پروتکل بافر یک سریالایزرِ Binary است.فریمورک gRPC  به صورت پیش فرض برای Serialize کردن  داده ها از Protcol Buffer استفاده میکند.پروتکل بافر داده ها را به آرایه ای یا استریمی از byte ها تبدیل میکند، و به همین دلیل سبک تر و سرعتش نسبت به JSON و XML بالاتر است.فایل  تنظیماتی proto. چیست ؟فریمورک gRPC برای ساخت API ها از رویکرد contract-first استفاده میکند.رویکرد contract-first چیست ؟در این روش،  ابتدا قبل از کد نوشتن باید متدهایی که قرار است در API مان ارائه بدهیم را به صورت کامل همراه با پارامتر هایشان را بنویسیم و سپس آن ها را پیاده سازی میکنیم.در فریمورک gRPC متد هایمان را باید در یک service قرار بدهیم، و پارامتر های آن ها را باید به صورت message تعریف کنیم، و سپس آن ها را در یک فایل با فرمت proto. قرار دهیم.message را دقیقا مثل DTO های خودمان تصور کنید.فایل proto محل قرارگیری متد ها و پارامتر هایی  است که قراره در API مان به سرویس گیرندگان ارائه کنیم.(  فایل ها proto را مثل یک قرارداد بین Client ها و Server ها تصور کنید ).در قسمت های بعدی به صورت کامل و عمیق با فایل های تنظیماتی proto آشنا می شویم.ساخت اولین پروژه با gRPC در ASP.NET Coreدر ادامه قصد داریم که یک پروژه خیلی ساده را با فریمورک gRPC و ASP.NET Core پیاده سازی کنیم.در این پروژه Server یک متد به نام Sum برای جمع دو عدد با نوع داده long به Client ارائه میکند و Client می تواند با فراخوانی این متد در برنامه خودش از پیاده سازی آن استفاده کند.در ابتدا یک پروژه ASP.NET Core به صورت Empty میسازیم. سپس باید پکیج Grpc.AspNetCore را نصب کنیم.Install-Package Grpc.AspNetCore -Version 2.34.0در مرحله بعدی طبق رویکرد contract-first اول باید متدها و پارامتر هایی که میخواهیم به بیرون ارائه کنیم را در یک فایل proto بنویسیم.یک فولدر به نام Protos میسازیم و در آن یک فایل proto به نام calculator اضافه میکنیم.سپس باید در فایل ساخته شده متد ها و پارامتر های آن ها را بنویسیم.همانطور که مشاهده میکنید متد Sum یک ورودی به نام SumRequest دارد و یک خروجی از نوع SumResponse https://gist.github.com/ArminShoeibi/0ed2d7fe6b12d29fbab752b30f66ca30 وقتی که قرارداد رو نوشتیم، باید آن را توسط Protobuf Compiler کامپایل کنیم، در قسمت های بعدی در مورد این کامپایلر صحبت خواهیم کرد.وارد Properties فایل calculator.proto می شویم.مقدار BuildAction را بر روی Protobuf Compiler قرار دهید.سپس مقدار gRPC Stub Classes را بر روی Server Only قرار دهید.سپس پروژه را Build کنید.( خیلی مهم) وقتی که مرحله بالا را انجام دهید، Protobuf Compiler از روی آن فایل calculator.proto برای شما دو عدد فایل سی شارپی با فرمت cs ایجاد میکند.(در مورد این 2 فایل در قسمت های بعدی به صورت کامل صحبت خواهیم کرد.) الان فقط برای پیاده سازی متد Sum در برنامه سرور باید از کلاس CalculatorServiceBase ارث بری کنیم، این کلاس در یک کلاس Static به نام CalculatorService قرار گرفته است.پس یک فولدر به نام GrpcServices  ایجاد کنید و در آن یک کلاس به نام CalculatorGrpcService بسازید و سپس از کلاس CalculatorServiceBase  ارث بری کنید.حالا باید متد Sum را پیاده سازی کنیم، Protobuf Compiler این متد را به صورت  virtual در کلاس CalculatorServiceBase قرار داده است و ما باید آن را override کنیم.بعد از اینکه متد Sum رو override کردیم باید منطق خودمون در اون پیاده سازی کنیم. https://gist.github.com/ArminShoeibi/61561512c7b6207f0c9ba0c7b6a595b2 حالا که متد Sum تکمیل شد باید سرویس gRPC رو به DI Container  پروژه مون اضافه کنیم.سپس میان افزار UseHttpsRedirection  را هم اضافه می کنیم.(خیلی مهم)و سپس کلاس CalculatorGrpcService رو هم در endpoint ها ثبت می کنیم. https://gist.github.com/ArminShoeibi/6980cb25e9951210fe56e5dd34057bf0 بعد از این مرحله باید اجرای پروژه مون رو به دست Kestrel بسپاریم، چون IIS هنوز از gRPC پشتیبانی نمیکنهنکته: اگر سیستم عامل تان ویندوز 10 هست و Build آن 20300.1000  و یا بالاتر است، همچنان میتوانید از IIS استفاده کنید و پروژه را با آن اجرا کنید.همچنین پروژه باید بر روی In-process hosting قرار گرفته باشد.طبق تصویر اجرای پروژه را به عهده Kestrel بزارید.خب الان پروژه سرور مان تکمیل شد و در اصل یک متد RPC به بیرون ارائه میکنه.الان وقت ساختن یک پروژه Client است که بتواند از این متد Sum استفاده کند، در همان سولوشن یک پروژه Console اضافه کنید.سپس 3 پکیج در آن نصب کنید.Install-Package Grpc.Tools -Version 2.34.0
Install-Package Grpc.Net.Client -Version 2.34.0
Install-Package Google.Protobuf -Version 3.14.0فایل های proto قراردادی هستند که باید هم در Server وجود داشته باشند و هم در Client و به 2 صورت مختلف هم Compile می شوند.1.کامپایل مخصوص Server2.کامپایل مخصوص Clientسپس باید فایل proto ای که در سرور قرار گرفته است را در Client هم اضافه کنیم، به صورت زیر اینکار را انجام دهید.بعد از اینکه فایل اضافه شد، Solution را یکبار Build کنید.(خیلی مهم)در این مرحله  باید بتونیم متد Sum رو در برنامه Console ای که ساختیم استفاده کنیم.ابتدا لازم است که یک ارتباط با سرور برقرار کنیم و سپس میتوانیم متد Sum را در برنامه خودمان فراخوانی کنیم، آرگومان ورودی اش را باید حتما بهش پاس بدیم. https://gist.github.com/ArminShoeibi/837347164542cba523e49ebc5143649a خب الان که هم سرور و هم کلاینت کدهاشون رو نوشتیم باید فقط اجراشون کنیم.ولی اول باید ترتیب اجرای پروژه ها را  تنظیم کنیم و سپس اجرایشان کنیم.بعد از اینکه ترتیب اجرا پروژه ها را تنظیم کردید، روی Start کلیک کنید.در ادامه اگر HTTPS certificate بر روی سیستم تون نصب نشده باشه، این پیام رو خواهید دید، بر روی Yes کلیک کنید.و  دوباره بر روی Yes کلیک کنید، تا پروژه ها اجرا شوند.و همینطور که می بینید، 2 عدد  از سمت کلاینت به سرور ارسال شد   و سرور و جواب جمع  دو عدد رو بهمون داد و ما جواب رو چاپ کردیم.در قسمت های بعدی به طور کامل و عمیق در مورد تمامی اجزای gRPC و کامپایلر آن یعنی protoc صحبت خواهیم کرد.سورس کد پروژه: https://github.com/ArminShoeibi/DNZ.Calculator-gRPC مقالات بیشتر در کانال دات نت زومhttps://t.me/DotNetZoom</description>
                <category>آرمین شعیبی</category>
                <author>آرمین شعیبی</author>
                <pubDate>Mon, 11 Jan 2021 19:20:27 +0330</pubDate>
            </item>
            </channel>
</rss>