‫۳ سال و ۱ ماه قبل، پنجشنبه ۲۴ تیر ۱۴۰۰، ساعت ۱۶:۰۵
- توکن‌ها را عموما در مرورگر ذخیره می‌کنند تا در آینده قابل بازیابی باشد. اطلاعات بیشتر در مورد ذخیره سازی سمت کلاینت: «معرفی Local Storage و چند کتابخانه مرتبط» و «ذخیره سازی اطلاعات در مرورگر توسط برنامه‌های Angular»   
- نمونه مثال بازگشت از درگاه بانکی و کار با توکن‌ها در سری Blazor سایت مطرح شده
‫۳ سال و ۱ ماه قبل، پنجشنبه ۲۴ تیر ۱۴۰۰، ساعت ۱۶:۰۲
خیر. همینقدر که کاربر برای دفعه‌ی بعدی به توکن خودش دسترسی نداشته باشد، یعنی نمی‌تواند لاگین کند. به همین جهت از session storage می‌توان استفاده کرد. اطلاعات بیشتر در مورد ذخیره سازی سمت کلاینت: «معرفی Local Storage و چند کتابخانه مرتبط» و «ذخیره سازی اطلاعات در مرورگر توسط برنامه‌های Angular»    
‫۳ سال و ۱ ماه قبل، پنجشنبه ۲۴ تیر ۱۴۰۰، ساعت ۰۳:۰۹
همان مطلب LocalDB FAQ را پیگیری کنید، به صورت اصولی به این موضوع پرداخته شده. LocalDB یک محصول مستقل هست و نصب و راه اندازی ساده‌ای دارد. مطلب یاد شده را پیگیری کنید، محل نصب محلی، روش یافتن شماره نگارش نصب شده و همچنین لینک دریافت نگارش‌های جدیدتر را هم مشاهده خواهید کرد؛ به همراه روش عیب‌یابی و نصب مجدد.
‫۳ سال و ۱ ماه قبل، یکشنبه ۲۰ تیر ۱۴۰۰، ساعت ۱۶:۵۴
نمونه‌ای از راه اندازی یک برنامه‌ی Blazor WASM در IIS

الف) به قسمت application pools در IIS Manager مراجعه کرده و گزینه‌ی add application pool را انتخاب کنید. سپس یک نمونه‌ی جدید را برای مثال به نام no-managed ایجاد کنید که net clr version. آن به گزینه‌ی no managed code اشاره می‌کند.
ب) پس از publish برنامه مطابق مطلب فوق (برای مثال با اجرای دستور dotnet publish -c Release) و معرفی مسیر پوشه‌ی publish به IIS (برای مثال به عنوان یک Application جدید ذیل default web site با کلیک راست بر روی default web site و انتخاب گزینه‌ی Add application)، این application pool جدید را به برنامه‌ی خود در IIS نسبت دهید. برای اینکار basic settings سایت را باز کرده و بر روی دکمه‌ی select که در کنار نام application pool هست، کلیک کرده و گزینه‌ی no-managed قسمت الف را انتخاب کنید.

نکته 1: برنامه‌های blazor wasm، یا standalone هستند و یا hosted. مورد standalone یعنی کاری به Web API ندارد و به خودی خود، به صورت یک سایت استاتیک قابل مشاهده‌است. حالت hosted یعنی به همراه web api هم هست و توسط دستور برای مثال «dotnet new blazorwasm -o BlazorIIS --hosted --no-https» ایجاد می‌شود که به همراه سه پوشه‌ی کلاینت، سرور و shared است. برای توزیع حالت متکی به خود، فقط محتویات پوشه‌ی publish، به عنوان مسیر برنامه، در IIS معرفی خواهند شد. در حالت hosted، مسیر اصلی، پوشه‌ی publish مربوط به پروژه‌ی سرور است؛ یعنی: Server\bin\Release\net5.0\publish. در این حالت پوشه‌ی Client\bin\Release\net5.0\publish باید به داخل همین پوشه‌ی publish سرور کپی شود. یعنی پوشه‌ی publish پروژه‌ی client باید به درون پوشه‌ی publish پروژه‌ی server کپی شود تا با هم یک برنامه‌ی قابل توزیع توسط IIS را تشکیل دهند.
در اینجا تنها فایل‌هایی که تداخل پیدا می‌کنند، فایل‌های web.config هستند که باید یکی شوند. فایل web.config برنامه‌ی web api با برنامه‌ی client یکی نیست، اما می‌توان محتویات این دو را با هم یکی کرد.
نکته 2: محل اجرای دستور dotnet publish -c Release مهم است. اگر این دستور را در کنار فایل sln پروژه‌ی hosted اجرا کنید، سه خروجی نهایی publish را تولید می‌کند و پس از آن باید فایل‌های کلاینت را به سرور، به صورت دستی کپی کرد. اما اگر دستور publish را درون پوشه‌ی سرور اجرا کنید، کار کپی فایل‌های کلاینت را به درون پوشه‌ی نهایی publish تشکیل شده، به صورت خودکار انجام می‌دهد؛ علت اینجا است که اگر به فایل csproj. پروژه‌ی سرور دقت کنید، ارجاعی را به پروژه‌ی کلاینت نیز دارد (هر چند ما از کدهای آن در برنامه‌ی web api استفاده نمی‌کنیم). این ارجاع تنها کمک حال دستور dotnet publish -c Release است و کاربرد دیگری را ندارد.

ج) اکنون اگر برنامه را برای مثال با مسیر فرضی جدید http://localhost/blazortest اجرا کنید، خطای 500.19 را دریافت می‌کنید. علت آن‌را در مطلب «بررسی خطاهای ممکن در حین راه اندازی اولیه برنامه‌های ASP.NET Core در IIS» بررسی کرده‌ایم. باید IIS URL Rewrite ماژول را نصب کرد؛ تا این مشکل برطرف شود. همچنین دلیل دیگر مشاهده‌ی این خطا، عدم نصب بسته‌ی هاستینگ متناظر با شماره نگارش NET. مورد استفاده‌است (اگر برنامه‌ی شما از نوع hosted است و web api هم دارد).
د) پس از آن باز هم برنامه اجرا نمی‌شود! اگر در خطاها دقت کنید، به دنبال اسکریپت‌هایی شروع شده از مسیر localhost است و نه از پوشه‌ی جدید blazortest. برای رفع این مشکل باید فایل publish\wwwroot\index.html را مطابق نکته‌ی base-URL که کمی بالاتر ذکر شد، ویرایش کرد تا blazor بداند که فایل‌ها، در چه مسیری قرار دارند (و در ریشه‌ی سایت واقع نشده‌اند):
<head>
<base href="/blazortest/" />
اکنون برنامه بدون مشکل بارگذاری و اجرا می‌شود.
‫۳ سال و ۲ ماه قبل، شنبه ۵ تیر ۱۴۰۰، ساعت ۰۴:۱۱
این پروژه برای اجرا، نیاز به اجرای همزمان دو پروژه را دارد که بهتر است ابتدا Web API اجرا شود و سپس کلاینتی که قرار است با آن کار کند:
الف) پروژه‌ی Web API
در این پروژه دو تغییر زیر انجام شده:
- در فایل HotelManagement\BlazorWasm\BlazorWasm.WebApi\Properties\launchSettings.json شماره پورت‌ها به 5001 و 5000 تنظیم شدند که البته چون بر روی SSL اجرا می‌شود، مقدار 5001 آن مهم است:
https://localhost:5001;http://localhost:5000
- در فایل HotelManagement\BlazorWasm\BlazorWasm.WebApi\appsettings.json شماره پورت کلاینت مشخص شده که در قسمت ب تنظیم می‌شود:
"Client_URL": "https://localhost:5002/"

ب) پروژه‌ی کلاینت
در این پروژه هم دو تغییر زیر انجام شده:
- در فایل HotelManagement\BlazorWasm\BlazorWasm.Client\Properties\launchSettings.json  شماره پورت‌ها به 5002 و 5003 تنظیم شدند که البته چون بر روی SSL اجرا می‌شود، مقدار 5002 آن مهم است:
https://localhost:5002;http://localhost:5003
- در فایل HotelManagement\BlazorWasm\BlazorWasm.Client\wwwroot\appsettings.json شماره پورت اتصال به Web API مشخص شده که همان 5001 قسمت الف است:
"BaseAPIUrl": "https://localhost:5001/"

این نکات را برای کار با IIS Express هم باید رعایت کنید و در فایل‌های launchSettings.json آن‌ها تنظیم کنید (و اگر شماره پورت ssl آن‌ها یکی نیست، یعنی تنظیم خوبی دارند). بعد از این تنظیمات، فایل‌های appsettings.json پروژه‌ها را هم یافته و شماره پورت‌های کلاینت و Web API را مانند مثال فوق و بر اساس شماره‌هایی که تنظیم کردید، دقیق تنظیم کنید تا کلاینت بداند که قرار است درخواست‌ها را دقیقا به چه آدرسی ارسال کند.