آموزش ساخت نسخه ویندوز با Tauri؛ خروجی EXE و فایل نصب MSI

ساخت نسخه ویندوز با Tauri یکی از بهترین روش‌ها برای تبدیل پروژه‌های React، TypeScript و Rust به نرم‌افزارهای دسکتاپ است.
با استفاده از Tauri 2 می‌توانید پروژه خود را به فایل اجرایی EXE و نصب‌کننده‌های MSI و NSIS تبدیل کنید.
در این آموزش، تمام مراحل آماده‌سازی محیط توسعه، نصب پیش‌نیازها و تنظیم فایل tauri.conf.json را بررسی می‌کنیم.
همچنین نحوه کامپایل پروژه، تولید نسخه Release و رفع خطاهای متداول هنگام Build را یاد می‌گیرید.
مدیریت دیتابیس SQLite، ذخیره اطلاعات در AppData، تنظیم WebView2 و پشتیبان‌گیری از داده‌ها نیز از موضوعات مهم این مقاله هستند.
در پایان می‌توانید یک نرم‌افزار حرفه‌ای Tauri برای ویندوز تولید کنید و آن را به‌صورت قابل نصب در اختیار کاربران قرار دهید.

مقدمه

توسعه نرم‌افزارهای دسکتاپ در سال‌های اخیر تغییرات زیادی کرده است. دیگر لازم نیست برای ساخت یک برنامه ویندوزی حتماً به سراغ زبان‌هایی مانند C#، Java یا ++C بروید. امروزه فریم‌ورک‌هایی وجود دارند که به شما اجازه می‌دهند با استفاده از فناوری‌های وب مانند HTML، CSS، JavaScript و React، نرم‌افزارهایی حرفه‌ای برای سیستم‌عامل‌های مختلف تولید کنید. یکی از جذاب‌ترین این فناوری‌ها Tauri است؛ فریم‌ورکی سبک، مدرن و مبتنی بر زبان Rust که امکان ساخت برنامه‌های دسکتاپ را با استفاده از رابط کاربری وب فراهم می‌کند.

فرض کنید یک نرم‌افزار مدیریت کلینیک فیزیوتراپی با React، TypeScript، Rust و SQLite توسعه داده‌اید. در محیط توسعه، برنامه شما با اجرای Vite و دستور npm run tauri dev به‌درستی اجرا می‌شود؛ اما حالا می‌خواهید آن را به یک نرم‌افزار واقعی تبدیل کنید که بتوانید روی کامپیوترهای دیگر نصب کنید، بدون نیاز به Visual Studio Code اجرا شود و اطلاعات خود را به‌صورت محلی ذخیره کند. اینجاست که فرایند Build و Package در Tauri اهمیت پیدا می‌کند.

در این مقاله، از آماده‌سازی محیط توسعه گرفته تا ساخت فایل اجرایی EXE، تولید نصب‌کننده MSI و NSIS، مدیریت دیتابیس SQLite، تنظیم آیکون، امضای دیجیتال، رفع خطاهای متداول و انتشار نسخه نهایی را بررسی می‌کنیم. هدف این است که در پایان بتوانید یک خروجی قابل نصب و قابل انتشار از پروژه Tauri خود تهیه کنید.

 

آشنایی با فرایند Build در Tauri

قبل از اینکه سراغ دستورات برویم، باید بدانیم Tauri دقیقاً چه کاری انجام می‌دهد. بسیاری از توسعه‌دهندگان تصور می‌کنند که با اجرای دستور Build، صرفاً فایل‌های React به یک فایل EXE تبدیل می‌شوند؛ اما این تصور دقیق نیست.

Tauri از دو بخش اصلی تشکیل شده است: بخش Frontend که معمولاً با React، Vue یا سایر فریم‌ورک‌های وب ساخته می‌شود و بخش Backend که با Rust توسعه پیدا می‌کند. این دو بخش در زمان اجرا با یکدیگر ارتباط دارند. رابط کاربری در محیط WebView سیستم‌عامل نمایش داده می‌شود و عملیات سیستمی، دسترسی به فایل‌ها، ارتباط با دیتابیس و اجرای دستورات داخلی می‌توانند از طریق Rust انجام شوند. هنگام Build، ابتدا Frontend ساخته می‌شود، سپس کد Rust کامپایل می‌شود و در نهایت فایل‌های موردنیاز برای اجرای برنامه در بسته نهایی قرار می‌گیرند.

نکته مهم این است که Tauri برخلاف Electron، یک نسخه کامل از مرورگر Chromium را همراه نرم‌افزار بسته‌بندی نمی‌کند. در ویندوز از WebView2 استفاده می‌کند که مبتنی بر موتور مرورگر Microsoft Edge است. این معماری باعث می‌شود حجم بسیاری از برنامه‌های Tauri نسبت به نمونه‌های مشابه Electron کمتر باشد. البته حجم نهایی به کتابخانه‌های Rust، فایل‌های جانبی، منابع تصویری و تنظیمات بسته‌بندی نیز وابسته است. بنابراین نباید انتظار داشته باشید تمام برنامه‌های Tauri الزاماً حجم بسیار کمی داشته باشند.

تفاوت فایل EXE با Installer

یکی از اولین موضوعاتی که باید روشن شود، تفاوت میان فایل اجرایی و فایل نصب‌کننده است. در ویندوز، پسوند EXE به‌تنهایی نشان‌دهنده نصب‌کننده بودن برنامه نیست. یک فایل EXE ممکن است مستقیماً برنامه را اجرا کند یا صرفاً یک نصب‌کننده باشد که فایل‌های برنامه را در مسیر مشخصی کپی می‌کند.

در پروژه Tauri معمولاً با سه نوع خروجی روبه‌رو می‌شویم:

نوع خروجی	کاربرد	توضیحات
EXE	اجرای مستقیم	فایل اجرایی برنامه
MSI	نصب نرم‌افزار	بسته استاندارد Windows Installer
NSIS Setup EXE	نصب نرم‌افزار	نصب‌کننده قابل شخصی‌سازی

برای مثال، اگر نرم‌افزار مدیریت کلینیک خود را برای یک مرکز فیزیوتراپی آماده می‌کنید، بهتر است یک نصب‌کننده NSIS یا MSI در اختیار کاربران قرار دهید. کاربر فایل را اجرا می‌کند، مراحل نصب را انجام می‌دهد و میانبر برنامه روی دسکتاپ ایجاد می‌شود.

پیشنهاد عملی: برای انتشار عمومی نرم‌افزار، تولید Installer را در اولویت قرار دهید و فایل EXE خام را صرفاً برای تست یا کاربردهای خاص نگه دارید.

معماری Tauri در ویندوز

Tauri در ویندوز از WebView2 برای نمایش رابط کاربری استفاده می‌کند. این موضوع از نظر حجم برنامه و مدیریت امنیت اهمیت زیادی دارد. در بسیاری از نسخه‌های جدید ویندوز، WebView2 Runtime از قبل وجود دارد؛ با این حال، نصب‌کننده Tauri می‌تواند در صورت نیاز فرایند نصب آن را مدیریت کند.

در معماری برنامه شما، ساختار به شکل زیر خواهد بود:

React + TypeScript + Tailwind CSS

رابط کاربری و صفحات نرم‌افزار

ارتباط از طریق Tauri Commands

Tauri 2 + Rust

منطق برنامه، عملیات فایل و دسترسی به دیتابیس

SQLite + AppData + Files

ذخیره اطلاعات و فایل‌های کاربران

در زمان Build، این معماری به یک برنامه دسکتاپ تبدیل می‌شود. بنابراین کاربر نهایی نیازی به نصب Node.js، npm یا ابزارهای توسعه Rust نخواهد داشت.

پیش‌نیازهای ساخت نسخه ویندوز

برای ساخت نسخه نهایی Tauri در ویندوز، باید ابزارهای موردنیاز را روی سیستم توسعه نصب کنید. این ابزارها با نرم‌افزارهایی که کاربر نهایی برای اجرای برنامه نیاز دارد متفاوت هستند.

برای مثال، کاربر نهایی نیازی به نصب Rust ندارد؛ اما کامپیوتر توسعه‌دهنده باید ابزارهای کامپایل Rust و کتابخانه‌های C++ را در اختیار داشته باشد.

نصب Rust و Cargo

Rust زبان اصلی بخش Backend در Tauri است. برای کامپایل برنامه باید Rust و Cargo نصب باشند. Cargo ابزار مدیریت پکیج و سیستم Build در اکوسیستم Rust است.

برای نصب، ابتدا به وب‌سایت رسمی Rust مراجعه کنید:

دانلود Rust

در ویندوز، نصب‌کننده rustup-init.exe را دانلود و اجرا کنید. پس از نصب، ترمینال جدید باز کنید و دستورات زیر را اجرا کنید:

rustc --version
cargo --version
rustup --version

اگر نسخه هر سه ابزار نمایش داده شود، نصب به‌درستی انجام شده است.

برای مشاهده Toolchain فعال نیز می‌توانید از دستور زیر استفاده کنید:

rustup show

در پروژه‌های Tauri بهتر است از Toolchain پایدار Rust استفاده کنید، مگر اینکه یکی از وابستگی‌های پروژه نیاز مشخصی به نسخه دیگری داشته باشد.

rustup default stable
rustup update stable

یک اشتباه رایج این است که توسعه‌دهنده Rust را نصب می‌کند، اما ترمینال قدیمی VS Code همچنان PATH قبلی را در اختیار دارد. در چنین شرایطی ممکن است دستور cargo شناخته نشود. بستن و باز کردن مجدد ترمینال یا VS Code معمولاً این مشکل را برطرف می‌کند.

نصب Visual Studio Build Tools

Tauri برای ساخت برنامه ویندوزی به ابزارهای کامپایل Microsoft C++ نیاز دارد. این ابزارها به‌خصوص برای لینک‌کردن کتابخانه‌های سیستم و وابستگی‌های Native ضروری هستند.

از لینک زیر استفاده کنید:

دانلود Visual Studio Build Tools

هنگام نصب، گزینه زیر را انتخاب کنید:

Desktop development with C++

این گزینه مجموعه‌ای از ابزارهای موردنیاز برای توسعه برنامه‌های ویندوزی را نصب می‌کند. دقت کنید که نصب صرف Visual Studio Code کافی نیست؛ VS Code یک ویرایشگر کد است و جایگزین کامپایلرهای Microsoft نمی‌شود.

پس از نصب، سیستم را در صورت درخواست نصب‌کننده راه‌اندازی مجدد کنید.

نصب Node.js و WebView2

اگر Frontend پروژه شما با React و Vite توسعه داده شده است، به Node.js و npm نیاز دارید.

نسخه LTS را از وب‌سایت رسمی دریافت کنید:

دانلود Node.js

پس از نصب، دستورات زیر را اجرا کنید:

node --version
npm --version

در ادامه باید WebView2 را نیز در نظر بگیرید.

دانلود Microsoft Edge WebView2 Runtime

WebView2 محیطی است که رابط کاربری برنامه Tauri را در ویندوز نمایش می‌دهد. در ویندوز ۱۰ نسخه 1803 و جدیدتر و ویندوز ۱۱ معمولاً این Runtime به‌صورت پیش‌فرض وجود دارد؛ با این حال، بهتر است نصب‌کننده نرم‌افزار را به شکلی تنظیم کنید که نبود WebView2 را نیز مدیریت کند.

Tauri+2

آماده‌سازی پروژه برای خروجی گرفتن

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

my-tauri-app/
│
├── src/
│   ├── components/
│   ├── pages/
│   ├── hooks/
│   ├── services/
│   └── App.tsx
│
├── src-tauri/
│   ├── src/
│   │   ├── main.rs
│   │   ├── lib.rs
│   │   └── commands/
│   ├── icons/
│   ├── capabilities/
│   ├── Cargo.toml
│   └── tauri.conf.json
│
├── public/
├── package.json
├── vite.config.ts
└── tsconfig.json

این ساختار یک نمونه متداول است و ممکن است ساختار واقعی پروژه شما تفاوت‌هایی داشته باشد.

بررسی package.json

فایل package.json را باز کنید و مطمئن شوید دستورات موردنیاز برای اجرای پروژه و Build تعریف شده‌اند.

یک نمونه ساده:

{
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "preview": "vite preview",
    "tauri": "tauri",
    "tauri_dev": "tauri dev",
    "tauri_build": "tauri build"
  }
}

توجه کنید که اگر پروژه شما از تنظیمات TypeScript متفاوتی استفاده می‌کند، ممکن است دستور tsc -b نیاز به اصلاح داشته باشد. همچنین اگر پروژه از Vite 8 استفاده می‌کند، باید نسخه Node.js موردنیاز همان نسخه Vite را بررسی کنید.

قبل از تولید خروجی، ابتدا وابستگی‌ها را نصب کنید:

npm install

سپس Build فرانت‌اند را مستقل آزمایش کنید:

npm run build

اگر این دستور با خطا مواجه شود، هنوز زمان اجرای Build نهایی Tauri نیست. ابتدا باید خطاهای TypeScript، مسیر فایل‌ها، Importها و وابستگی‌های Frontend را اصلاح کنید.

تنظیم tauri.conf.json

یکی از مهم‌ترین فایل‌های پروژه، src-tauri/tauri.conf.json است. این فایل تنظیمات اصلی برنامه، اطلاعات بسته‌بندی، پنجره‌ها، آیکون و نحوه تولید خروجی را مشخص می‌کند.

نمونه تنظیمات:

{
  "$schema": "https://schema.tauri.app/config/2",
  "productName": "Physio Clinic",
  "version": "1.0.0",
  "identifier": "ir.sahand.physioclinic",
  "build": {
    "beforeDevCommand": "npm run dev",
    "devUrl": "http://localhost:1420",
    "beforeBuildCommand": "npm run build",
    "frontendDist": "../dist"
  },
  "app": {
    "windows": [
      {
        "label": "main",
        "title": "Physio Clinic",
        "width": 1280,
        "height": 800,
        "resizable": false,
        "fullscreen": true
      }
    ]
  },
  "bundle": {
    "active": true,
    "targets": [
      "nsis",
      "msi"
    ],
    "icon": [
      "icons/32x32.png",
      "icons/128x128.png",
      "icons/128x128@2x.png",
      "icons/icon.icns",
      "icons/icon.ico"
    ],
    "windows": {
      "webviewInstallMode": {
        "type": "downloadBootstrapper"
      }
    }
  }
}

چند نکته مهم درباره این تنظیمات وجود دارد.

اول اینکه مقدار identifier باید شناسه‌ای یکتا و ثابت برای برنامه شما باشد. بهتر است پس از انتشار نسخه اول آن را تغییر ندهید، زیرا در شناسایی برنامه و مدیریت نصب و به‌روزرسانی اهمیت دارد.

دوم اینکه مسیر frontendDist باید با محل خروجی واقعی Vite مطابقت داشته باشد. در حالت پیش‌فرض Vite، خروجی در پوشه dist قرار می‌گیرد.

سوم اینکه تنظیم targets مشخص می‌کند چه نوع بسته‌هایی تولید شوند. در این مثال هم MSI و هم NSIS درخواست شده‌اند.

چهارم اینکه تنظیمات پنجره باید با نیاز واقعی برنامه مطابقت داشته باشند. برای مثال، اگر نرم‌افزار شما تمام‌صفحه و غیرقابل تغییر اندازه است، می‌توانید همین تنظیمات را حفظ کنید؛ اما اگر قصد دارید کاربران اندازه پنجره را تغییر دهند، مقدار resizable باید true باشد.

نکته فنی: اگر در پروژه خود از HashRouter استفاده می‌کنید، مسیرهای داخلی React Router را نیز در محیط Production آزمایش کنید. همچنین مطمئن شوید فایل‌های CSS، فونت Vazirmatn و تصاویر در خروجی Vite قرار می‌گیرند و آدرس‌دهی آن‌ها به مسیرهای محلی توسعه وابسته نیست.

ساخت نسخه Release

پس از آماده‌سازی تنظیمات، نوبت به تولید نسخه نهایی می‌رسد. در این مرحله، Tauri کد Frontend را بهینه‌سازی می‌کند و سپس بخش Rust را در حالت Release کامپایل می‌کند. تفاوت اصلی حالت Release با Development این است که خروجی نهایی برای اجرای واقعی و توزیع آماده می‌شود. در حالت Development، ابزارهای Debug و امکانات توسعه در دسترس هستند، اما در نسخه Release تمرکز بر عملکرد، حجم و اجرای پایدار برنامه است.

اجرای دستور Build

ابتدا وارد پوشه اصلی پروژه شوید. برای مثال:

cd D:\projects\tauri1

سپس وابستگی‌های پروژه را نصب کنید:

npm install

برای اطمینان از اینکه Frontend مشکلی ندارد:

npm run build

حالا دستور اصلی تولید خروجی را اجرا کنید:

npm run tauri_build

اگر در package.json اسکریپت tauri_build تعریف نکرده‌اید، می‌توانید مستقیماً از دستور زیر استفاده کنید:

npx tauri build

یا با استفاده از اسکریپت عمومی Tauri:

npm run tauri build

در این مرحله فرایندهای زیر انجام می‌شوند:

1. اجرای دستور Build فرانت‌اند.

2. آماده‌سازی فایل‌های HTML، CSS و JavaScript.

3. کامپایل کد Rust.

4. لینک‌کردن کتابخانه‌های موردنیاز.

5. آماده‌سازی منابع و فایل‌های جانبی.

6. تولید فایل اجرایی برنامه.

7. ساخت بسته نصب‌کننده براساس تنظیمات پروژه.

ممکن است اولین Build چند دقیقه طول بکشد؛ زیرا Cargo باید وابستگی‌های Rust را دریافت و کامپایل کند. در Buildهای بعدی، به دلیل استفاده از Cache، معمولاً زمان کمتری صرف می‌شود.

اگر در زمان کامپایل با خطای شبکه مواجه شدید، ابتدا اتصال Cargo به مخازن موردنیاز را بررسی کنید. اگر از Proxy استفاده می‌کنید، تنظیمات آن باید با برنامه‌های خط فرمان هماهنگ باشد. برای مثال، اگر V2Ray شما روی پورت 10808 کار می‌کند، می‌توانید در PowerShell تنظیمات موقت زیر را اعمال کنید:

$env:HTTP_PROXY="http://127.0.0.1:10808"
$env:HTTPS_PROXY="http://127.0.0.1:10808"

این تنظیم فقط برای همان نشست ترمینال معتبر است و با تنظیم دائمی متغیرهای محیطی تفاوت دارد.

محل ذخیره فایل‌های خروجی

یکی از سؤالات رایج توسعه‌دهندگان این است که پس از اجرای موفق Build، فایل EXE در کجا قرار می‌گیرد.

در ساختار استاندارد Tauri 2، خروجی‌ها معمولاً در مسیر زیر قرار می‌گیرند:

src-tauri/
└── target/
    └── release/
        ├── physio_clinic.exe
        │
        └── bundle/
            ├── nsis/
            │   └── Physio Clinic_1.0.0_x64-setup.exe
            │
            └── msi/
                └── Physio Clinic_1.0.0_x64_en-US.msi

نام فایل‌ها به productName، نسخه برنامه، معماری و تنظیمات پروژه وابسته است.

توجه کنید که physio_clinic.exe فایل اجرایی برنامه است، اما فایل داخل پوشه nsis یک نصب‌کننده است.

اگر فقط به فایل اجرایی نیاز دارید، می‌توانید آن را از مسیر target/release پیدا کنید؛ ولی برای انتشار نرم‌افزار، پیشنهاد می‌شود Installer تولید کنید تا فایل‌های موردنیاز و فرایند نصب نیز مدیریت شوند.

یک نکته مهم دیگر این است که فایل EXE را به‌تنهایی از پوشه Release جدا نکنید و تصور نکنید که تمام وابستگی‌های برنامه همراه آن هستند. اگر برنامه از منابع خارجی، کتابخانه‌های جانبی یا فایل‌های پیکربندی استفاده می‌کند، باید مطمئن شوید این منابع نیز در بسته نهایی قرار گرفته‌اند.

تولید فایل نصب MSI و EXE

Tauri 2 دو روش متداول برای تولید بسته نصب ویندوز ارائه می‌دهد: WiX برای MSI و NSIS برای Setup EXE. هر دو روش کاربردی هستند، اما تفاوت‌هایی در تجربه نصب، سفارشی‌سازی و نحوه توزیع دارند.

استفاده از NSIS

NSIS مخفف Nullsoft Scriptable Install System است. این ابزار امکان تولید نصب‌کننده‌های ویندوزی با پسوند EXE را فراهم می‌کند.

یکی از مزیت‌های NSIS انعطاف‌پذیری آن در طراحی فرایند نصب است. می‌توانید مسیر نصب، ساخت میانبر، تنظیمات نصب برای کاربر جاری یا تمام کاربران و برخی مراحل اضافی را مدیریت کنید.

برای تولید خروجی NSIS کافی است در تنظیمات Tauri مقدار زیر را قرار دهید:

{
  "bundle": {
    "active": true,
    "targets": ["nsis"]
  }
}

سپس دستور زیر را اجرا کنید:

npm run tauri build

فایل خروجی معمولاً در مسیر زیر قرار می‌گیرد:

src-tauri/target/release/bundle/nsis/

برای نرم‌افزار مدیریت کلینیک، NSIS انتخاب مناسبی است؛ زیرا می‌توانید نصب‌کننده‌ای ساده و حرفه‌ای در اختیار اپراتور قرار دهید.

یکی دیگر از قابلیت‌های مهم NSIS، تعیین نوع نصب است. برای مثال، می‌توانید برنامه را فقط برای کاربر جاری نصب کنید یا نصب آن را برای تمام کاربران سیستم در نظر بگیرید.

نمونه تنظیم:

{
  "bundle": {
    "windows": {
      "nsis": {
        "installMode": "currentUser"
      }
    }
  }
}

مقادیر قابل استفاده در این تنظیم شامل currentUser، perMachine و both هستند.

• currentUser: نصب فقط برای کاربر جاری و بدون نیاز معمول به دسترسی Administrator.

• perMachine: نصب برای تمام کاربران سیستم و نیازمند مجوز مدیریتی.

• both: امکان انتخاب نوع نصب توسط کاربر.

برای نرم‌افزارهای کلینیکی که ممکن است روی کامپیوترهای اشتراکی نصب شوند، باید درباره نوع نصب تصمیم مشخصی بگیرید.

استفاده از WiX

MSI یکی از فرمت‌های استاندارد نصب نرم‌افزار در ویندوز است. این فرمت به‌خصوص در محیط‌های سازمانی اهمیت دارد؛ زیرا ابزارهای مدیریتی ویندوز می‌توانند نصب، حذف و مدیریت آن را انجام دهند.

Tauri برای تولید بسته MSI از WiX Toolset استفاده می‌کند.

برای فعال‌کردن خروجی MSI:

{
  "bundle": {
    "active": true,
    "targets": ["msi"]
  }
}

سپس:

npm run tauri build

خروجی در مسیر زیر قرار می‌گیرد:

src-tauri/target/release/bundle/msi/

در بعضی نسخه‌های ویندوز، قابلیت اختیاری VBScript غیرفعال است. در این شرایط ممکن است هنگام تولید MSI با خطایی مانند زیر مواجه شوید:

failed to run light.exe

برای رفع آن، وارد مسیر زیر شوید:

Settings
  → Apps
  → Optional features
  → More Windows features

سپس قابلیت VBScript را فعال کنید. این قابلیت برای ساخت MSI در شرایط مستندشده Tauri موردنیاز است.

Tauri+1

مقایسه دو روش:

ویژگی	NSIS	MSI
فرمت خروجی	EXE	MSI
نصب ساده برای کاربر	بسیار مناسب	مناسب
سفارشی‌سازی	انعطاف‌پذیر	ساختارمند
کاربرد سازمانی	مناسب	بسیار مناسب
مدیریت از طریق ابزارهای سازمانی	محدودتر	مناسب‌تر
تولید در ویندوز	بله	بله

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

تنظیم دیتابیس SQLite و فایل‌های جانبی

این بخش از مهم‌ترین قسمت‌های ساخت نسخه نهایی نرم‌افزار است؛ مخصوصاً برای برنامه‌هایی که اطلاعات کاربران را به‌صورت محلی ذخیره می‌کنند.

فرض کنیم در نرم‌افزار مدیریت فیزیوتراپی از SQLite استفاده می‌کنید و جداول زیر را دارید:

• Patients

• Insurances

• InsuranceFunds

• Services

• Invoices

• InvoiceDetails

• Operators

• Settings

در زمان توسعه ممکن است دیتابیس را در مسیر پروژه قرار داده باشید:

src-tauri/physio.db

اما این کار برای نسخه نهایی انتخاب مناسبی نیست.

چرا؟ چون نصب‌کننده ممکن است برنامه را در مسیر Program Files قرار دهد و کاربر عادی اجازه نوشتن در آن مسیر را نداشته باشد. همچنین با حذف یا به‌روزرسانی برنامه ممکن است اطلاعات کاربران به خطر بیفتد.

راهکار اصولی، ذخیره دیتابیس در مسیر اختصاصی اطلاعات برنامه در ویندوز است.

برای مثال:

C:\Users\USERNAME\AppData\Roaming\
    ir.sahand.physioclinic\
        physio.db

یا براساس مسیر واقعی AppData که Tauri برای برنامه برمی‌گرداند.

در Rust می‌توانید از API مربوط به مسیر App Data استفاده کنید:

use tauri::Manager;
use std::path::PathBuf;

fn get_database_path(
    app: &tauri::AppHandle
) -> Result {

    let app_data_dir = app
        .path()
        .app_data_dir()
        .map_err(|e| e.to_string())?;

    std::fs::create_dir_all(&app_data_dir)
        .map_err(|e| e.to_string())?;

    Ok(app_data_dir.join("physio.db"))
}

در ادامه، اتصال SQLx را با مسیر به‌دست‌آمده برقرار کنید.

نمونه:

use sqlx::sqlite::SqliteConnectOptions;
use sqlx::SqlitePool;
use std::str::FromStr;

async fn create_pool(
    db_path: &std::path::Path
) -> Result {

    let options = SqliteConnectOptions::new()
        .filename(db_path)
        .create_if_missing(true)
        .foreign_keys(true);

    SqlitePool::connect_with(options).await
}

در پروژه واقعی بهتر است ساخت Pool، اجرای Migration و مدیریت خطاها در یک ماژول مستقل انجام شوند.

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

مدیریت فایل‌های جانبی و مستندات بیماران

اگر نرم‌افزار شما تصاویر، اسناد پزشکی، فایل‌های PDF یا اسکن مدارک بیماران را نگهداری می‌کند، فقط انتقال دیتابیس کافی نیست.

باید یک ساختار مشخص برای ذخیره فایل‌ها در نظر بگیرید:

AppData/
└── ir.sahand.physioclinic/
    ├── physio.db
    ├── files/
    │   ├── patients/
    │   ├── documents/
    │   └── invoices/
    ├── backups/
    └── logs/

در دیتابیس بهتر است مسیر نسبی فایل‌ها ذخیره شود، نه مسیر کامل کامپیوتر کاربر.

برای مثال:

patients/1024/profile.jpg

به جای:

C:\Users\Admin\AppData\...\profile.jpg

با این روش، هنگام انتقال اطلاعات یا بازیابی نسخه پشتیبان، وابستگی به نام کاربری و مسیر نصب کاهش پیدا می‌کند.

برای نسخه نهایی نرم‌افزار کلینیک، پیشنهاد می‌کنم سیستم Backup را به دو بخش تقسیم کنید: پشتیبان دیتابیس و پشتیبان فایل‌ها.

در SQLite، اگر از WAL Mode استفاده می‌کنید، صرفاً کپی‌کردن فایل اصلی physio.db در زمان فعال‌بودن برنامه همیشه روش امنی نیست. بهتر است از مکانیزم Backup خود SQLite یا API پشتیبان‌گیری SQLx استفاده کنید و وضعیت فایل‌های جانبی را نیز مدیریت کنید.

بهینه‌سازی و امنیت نسخه نهایی

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

اولین موضوع، حذف اطلاعات توسعه از نسخه نهایی است. آدرس‌هایی مانند localhost:1420 نباید در خروجی Production به‌عنوان منبع اجرای رابط کاربری استفاده شوند. Tauri در زمان Build باید فایل‌های استاتیک تولیدشده توسط Vite را در بسته قرار دهد.

موضوع دوم، مدیریت دسترسی‌هاست. در Tauri 2، سیستم Capabilities و Permissions مشخص می‌کند هر پنجره به چه قابلیت‌هایی دسترسی داشته باشد. نباید صرفاً برای اینکه برنامه بدون خطا اجرا شود، تمام دسترسی‌ها را باز کنید.

برای مثال، اگر برنامه شما به فایل‌سیستم نیاز دارد، فقط مجوزهای موردنیاز را تعریف کنید. اگر از Plugin SQL استفاده می‌کنید، دسترسی اجرای Query را نیز متناسب با نیاز برنامه تنظیم کنید.

موضوع سوم، محافظت از اطلاعات حساس است. رمزهای عبور، کلیدهای API و اطلاعات محرمانه نباید به‌صورت ثابت در کد Frontend یا فایل‌های قابل مشاهده برنامه قرار بگیرند. برای اطلاعات حساس محلی می‌توانید از امکانات رمزنگاری سیستم‌عامل یا راهکارهای مدیریت امن کلید استفاده کنید.

موضوع چهارم، امضای دیجیتال است. وقتی برنامه را در اختیار مشتری قرار می‌دهید، امضای دیجیتال ناشر کمک می‌کند هویت ناشر مشخص شود و اعتماد بیشتری در فرایند نصب ایجاد شود.

برای امضای برنامه ویندوزی می‌توانید از گواهی Code Signing و ابزارهای امضای Microsoft استفاده کنید. امضای معتبر به‌تنهایی تضمین نمی‌کند که Windows SmartScreen هیچ هشداری نمایش ندهد؛ اعتبار ناشر، نوع گواهی و سابقه انتشار نیز در این موضوع تأثیر دارند.

تنظیم WebView2 برای سیستم‌های بدون اینترنت

یکی از تصمیم‌های مهم هنگام انتشار نرم‌افزار، نحوه نصب WebView2 است.

Tauri چند روش برای مدیریت این Runtime ارائه می‌کند:

روش	حجم اضافه تقریبی	نیاز به اینترنت هنگام نصب
downloadBootstrapper	نزدیک صفر	بله
embedBootstrapper	حدود ۱٫۸ مگابایت	بله
offlineInstaller	حدود ۱۲۷ مگابایت	خیر
fixedVersion	حدود ۱۸۰ مگابایت	خیر
skip	صفر	خیر

این اعداد تقریبی هستند و به نسخه Runtime و معماری سیستم وابسته‌اند.

Tauri+1

اگر نرم‌افزار شما در یک کلینیک نصب می‌شود که اینترنت پایداری ندارد، استفاده از offlineInstaller می‌تواند گزینه مناسبی باشد.

نمونه تنظیم:

{
  "bundle": {
    "windows": {
      "webviewInstallMode": {
        "type": "offlineInstaller"
      }
    }
  }
}

البته باید توجه کنید که این تنظیم حجم نصب‌کننده را به شکل محسوسی افزایش می‌دهد.

روش skip را برای انتشار عمومی پیشنهاد نمی‌کنم؛ چون اگر WebView2 روی سیستم مقصد نصب نباشد، برنامه اجرا نخواهد شد.

تنظیم آیکون و مشخصات نرم‌افزار

یک نرم‌افزار حرفه‌ای باید هویت بصری مشخصی داشته باشد. آیکون برنامه در منوی Start، دسکتاپ، نوار وظیفه و فایل نصب‌کننده نمایش داده می‌شود.

در Tauri می‌توانید آیکون‌ها را در پوشه زیر قرار دهید:

src-tauri/icons/

فرمت‌های PNG و ICO برای ویندوز اهمیت دارند. بهتر است یک تصویر با کیفیت بالا تهیه کنید و نسخه‌های موردنیاز را با ابزار Tauri تولید کنید:

npx tauri icon ./assets/logo.png

برای مثال، اگر لوگوی مرکز فیزیوتراپی سهند را در مسیر assets/logo.png قرار داده‌اید، این دستور می‌تواند مجموعه آیکون‌های موردنیاز را ایجاد کند.

همچنین اطلاعات زیر را به‌درستی تنظیم کنید:

• نام محصول

• شماره نسخه

• شناسه یکتای برنامه

• عنوان پنجره

• آیکون برنامه

• اطلاعات ناشر و مشخصات بسته

شماره نسخه را نیز در هر انتشار جدید به‌روزرسانی کنید. برای مثال:

1.0.0  → نسخه اولیه
1.0.1  → اصلاح باگ
1.1.0  → قابلیت جدید
2.0.0  → تغییرات اساسی

این نظم در آینده برای مدیریت نسخه‌ها و سیستم Update اهمیت زیادی خواهد داشت.

رفع خطاهای متداول هنگام ساخت نسخه Windows با Tauri

در فرایند Build ممکن است با خطاهای مختلفی مواجه شوید. بعضی از این خطاها به محیط توسعه مربوط هستند و برخی دیگر از تنظیمات پروژه یا وابستگی‌های Rust ناشی می‌شوند. بهتر است قبل از تغییر کد، متن کامل خطا را بررسی کنید؛ تغییر تصادفی تنظیمات Cargo یا حذف پوشه‌های پروژه معمولاً راهکار مناسبی نیست.

خطای Cargo و Rust

اگر با خطایی مانند زیر مواجه شدید:

error: linker `link.exe` not found

معمولاً ابزارهای کامپایل C++ یا محیط MSVC به‌درستی نصب نشده‌اند.

ابتدا این دستور را اجرا کنید:

rustup show

سپس بررسی کنید Toolchain ویندوزی MSVC فعال باشد. در صورت نیاز:

rustup toolchain install stable-x86_64-pc-windows-msvc

و برای فعال‌کردن آن:

rustup default stable-x86_64-pc-windows-msvc

اگر مشکل همچنان وجود دارد، نصب Visual Studio Build Tools و Windows SDK را بررسی کنید.

خطای عدم پیدا کردن فایل‌های Frontend

خطایی مانند زیر:

Could not find a frontend distribution folder

معمولاً به این معنی است که Tauri نتوانسته فایل‌های خروجی Frontend را پیدا کند.

برای حل مشکل، مقدار frontendDist را بررسی کنید:

{
  "build": {
    "frontendDist": "../dist",
    "beforeBuildCommand": "npm run build"
  }
}

سپس دستور زیر را اجرا کنید:

npm run build

بررسی کنید پوشه dist در مسیر صحیح ایجاد شده باشد.

دقت کنید مسیر frontendDist نسبت به پوشه تنظیمات Tauri یعنی src-tauri محاسبه می‌شود، نه نسبت به ریشه پروژه.

خطای SQLite در نسخه نهایی

یکی از مشکلات مهم در برنامه‌های Tauri، کارکرد صحیح SQLite پس از نصب است.

فرض کنید برنامه در محیط Development به دیتابیس دسترسی دارد، اما پس از نصب روی سیستم دیگر با خطای زیر مواجه می‌شود:

unable to open database file

دلایل احتمالی عبارت‌اند از:

• مسیر دیتابیس اشتباه است.

• پوشه مقصد ایجاد نشده است.

• برنامه اجازه نوشتن در مسیر را ندارد.

• اتصال SQLite با تنظیمات اشتباه ایجاد شده است.

• فایل دیتابیس در محل نامناسبی قرار گرفته است.

برای رفع مشکل، مسیر دیتابیس را از AppData دریافت کنید و قبل از اتصال، وجود پوشه را بررسی کنید.

همچنین اگر از SQLx استفاده می‌کنید، مطمئن شوید Featureهای لازم در Cargo.toml فعال هستند.

نمونه:

[dependencies]
sqlx = {
    version = "0.8",
    features = [
        "runtime-tokio",
        "sqlite",
        "macros",
        "migrate"
    ]
}

این نمونه باید با نسخه واقعی SQLx و سایر وابستگی‌های پروژه هماهنگ شود.

خطای WebView2

اگر برنامه نصب می‌شود اما در سیستم مقصد اجرا نمی‌شود یا پنجره سفید نمایش داده می‌شود، WebView2 و فایل‌های Frontend را بررسی کنید.

ابتدا مطمئن شوید Runtime نصب است. سپس بررسی کنید فایل‌های HTML، CSS، JavaScript و فونت‌ها در بسته نهایی قرار گرفته باشند.

در زمان توسعه، ممکن است یک فایل به دلیل آدرس‌دهی نسبی اشتباه از Vite دریافت شود؛ اما در محیط Production دیگر چنین مسیری وجود نداشته باشد.

برای مثال، استفاده از آدرس‌هایی مانند:

http://localhost:1420/assets/logo.png

برای منابع ثابت نسخه نهایی اشتباه است.

بهتر است از روش استاندارد مدیریت Assets در Vite استفاده کنید.

انتشار و به‌روزرسانی نرم‌افزار

بعد از اینکه خروجی نهایی را تولید کردید، باید به انتشار آن فکر کنید. انتشار نرم‌افزار صرفاً قراردادن فایل EXE در یک وب‌سایت نیست. باید مشخص کنید کاربران چگونه نسخه جدید را دریافت می‌کنند، اطلاعات قبلی آن‌ها چه می‌شود و در صورت بروز مشکل چگونه می‌توانند به نسخه قبلی برگردند.

برای نرم‌افزارهای دسکتاپ، بهتر است یک فرایند انتشار مشخص داشته باشید.

برای مثال:

Releases/
│
├── v1.0.0/
│   ├── PhysioClinic-Setup.exe
│   └── PhysioClinic.msi
│
├── v1.0.1/
│   ├── PhysioClinic-Setup.exe
│   └── PhysioClinic.msi
│
└── v1.1.0/
    ├── PhysioClinic-Setup.exe
    └── PhysioClinic.msi

در هر نسخه باید تغییرات، اصلاحات و قابلیت‌های جدید مشخص باشند.

پیاده‌سازی سیستم Auto Update

Tauri 2 از Plugin رسمی Updater پشتیبانی می‌کند. با استفاده از این قابلیت می‌توانید بررسی نسخه جدید، دریافت بسته به‌روزرسانی و نصب آن را مدیریت کنید.

برای مثال، نرم‌افزار می‌تواند هنگام اجرا نسخه نصب‌شده را با نسخه منتشرشده روی سرور مقایسه کند.

فرایند کلی به این شکل است:

1. بررسی نسخه فعلی

   خواندن شماره نسخه نصب‌شده نرم‌افزار

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

   دریافت اطلاعات نسخه جدید و مقایسه نسخه‌ها

3. دریافت بسته Update

   دانلود فایل به‌روزرسانی و بررسی امضای دیجیتال

4. نصب نسخه جدید

   اجرای فرایند نصب و جایگزینی نسخه برنامه

5. راه‌اندازی مجدد

   اجرای نسخه جدید با حفظ اطلاعات قبلی

برای این کار می‌توانید مستندات رسمی را مطالعه کنید:

مستندات Tauri Updater

اما یک نکته مهم برای نرم‌افزارهای مبتنی بر SQLite وجود دارد: به‌روزرسانی برنامه نباید دیتابیس کاربران را بازنویسی کند. اگر ساختار جداول تغییر کرده است، باید Migrationهای نسخه‌بندی‌شده اجرا شوند.

برای مثال، اگر در نسخه 1.0.0 جدول بیماران فیلد جدیدی به نام MedicalFileNumber نداشته باشد، در نسخه 1.1.0 می‌توانید Migration مشخصی برای افزودن آن بنویسید.

همچنین قبل از Migration بهتر است نسخه پشتیبان تهیه شود تا در صورت بروز خطا امکان بازیابی اطلاعات وجود داشته باشد.

نتیجه‌گیری

ساخت نسخه Windows با Tauri یکی از مراحل مهم تبدیل یک پروژه تحت وب به نرم‌افزار دسکتاپ واقعی است. با استفاده از React، TypeScript و Rust می‌توانید برنامه‌ای تولید کنید که علاوه بر رابط کاربری مدرن، قابلیت دسترسی به فایل‌ها، دیتابیس محلی، امکانات سیستم‌عامل و ارتباط با سرویس‌های آنلاین را داشته باشد.

برای تولید نسخه نهایی، ابتدا باید Rust، Cargo، Visual Studio Build Tools، Node.js و WebView2 را آماده کنید. سپس تنظیمات tauri.conf.json را بررسی کرده و دستور tauri build را اجرا کنید. خروجی برنامه می‌تواند شامل فایل اجرایی EXE، نصب‌کننده NSIS و بسته MSI باشد.

با این حال، کیفیت یک نرم‌افزار دسکتاپ تنها به موفقیت Build وابسته نیست. مدیریت صحیح دیتابیس، ذخیره فایل‌ها در AppData، پشتیبان‌گیری، امنیت دسترسی‌ها، مدیریت WebView2 و سیستم به‌روزرسانی از مواردی هستند که باید پیش از انتشار بررسی شوند.

برای پروژه‌های واقعی مانند نرم‌افزار مدیریت کلینیک فیزیوتراپی، پیشنهاد می‌کنم از همان ابتدا ساختار Release و Backup را اصولی طراحی کنید. همچنین نسخه نصب‌شده را روی یک ویندوز تمیز و بدون ابزارهای توسعه آزمایش کنید. موفقیت Build روی کامپیوتر برنامه‌نویس به معنی اجرای صحیح نرم‌افزار روی کامپیوتر مشتری نیست.

کلیدواژه ها

پرسش و پاسخ