把 RDL 放進 Blazor 專案後，能否直接生成 PDF？

2026-07-13 13:44:54 JST | PowerPlatform | 2 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1325

最近在研究將既有 Access 報表遷移到 Blazor Web App 時，我遇到了一個很容易產生誤解的問題：

如果直接把 .rdl 文件放進 Blazor Web App 的工程目錄，應用程式能不能自己把它生成 PDF？
還是一定要把 RDL 上傳到 Power BI Service，再透過 REST API 導出？

結論是：

RDL 不一定要放在 Power BI 雲端，但僅僅把 RDL 文件放進 Blazor 專案，也不能讓它自己生成 PDF。

真正需要的不是「文件放在哪裡」，而是必須有一個能夠解析和渲染 RDL 的報表引擎。

---

一、RDL 本身不能直接生成 PDF

RDL 的全稱是 Report Definition Language，本質上是一份 XML 格式的報表定義文件。

它通常記錄以下內容：

• 報表版面

• 資料來源

• SQL 查詢

• 報表參數

• 表格和文字框

• 分頁方式

• 頁首與頁尾

• 格式和運算式

例如，在 Blazor 工程中建立以下目錄：

BlazorWebApp
└─ Reports
   └─ 処理状況帳票.rdl

這只代表應用程式中保存了一份 RDL 文件。

RDL 本身不是執行程式，也不包含 PDF 生成器。Blazor 不會因為讀取到一份 RDL，就自動知道如何執行其中的 SQL、處理參數、計算版面並輸出 PDF。

整個流程實際上是：

RDL 報表定義
    ↓
報表渲染引擎
    ↓
執行 SQL、套用參數、排版
    ↓
輸出 PDF

因此，問題的核心不是 RDL 能不能放進 Blazor，而是由誰負責渲染。

---

二、方案一：使用 Power BI Service 生成 PDF

目前較常見的雲端方案是：

Blazor Web App
    ↓
Power BI REST API
    ↓
Power BI Service 中的 Paginated Report
    ↓
生成 PDF
    ↓
返回瀏覽器

Blazor 後端可以透過 Service Principal 呼叫 Power BI 的 ExportToFile API，將部署在 Power BI Service 中的 RDL 導出為 PDF。

這種方案的優點是：

• 不需要自己維護報表伺服器

• 報表統一放在 Power BI Workspace 中管理

• 適合 Azure Web App

• 可以透過 API 自動生成 PDF

• Web 使用者不一定需要 Power BI 帳號

缺點則是：

• 通常需要 Microsoft Fabric Capacity

• 需要設定 Entra ID 應用程式和 Service Principal

• 需要管理 Workspace 權限

• 系統會依賴 Power BI 雲端服務

因此，Power BI Service 是比較現代化的雲端方案，但並不是唯一選擇。

---

三、方案二：自己部署 SSRS

微軟也提供 SQL Server Reporting Services，也就是 SSRS。

SSRS 是一套可以安裝在 Windows Server 上的報表伺服器，專門負責管理和渲染 RDL。

架構可以變成：

Blazor Web App
    ↓
SSRS Report Server
    ↓
執行 RDL
    ↓
查詢 SQL Server 或 Azure SQL Database
    ↓
輸出 PDF

SSRS 支援透過 URL 直接指定輸出格式，例如：

https://report-server/ReportServer?/Reports/処理状況帳票
&StartDate=2026-07-01
&EndDate=2026-07-31
&rs:Format=PDF

其中：

rs:Format=PDF

代表要求 SSRS 將報表渲染為 PDF。

Blazor 後端只需要向 SSRS 發出請求，取得 PDF 的位元資料，再返回給瀏覽器即可。

這個方案不需要 Power BI Service，也不需要呼叫 Power BI ExportToFile API。

SSRS 可以部署在：

• 公司內部 Windows Server

• 公司內部虛擬機

• Azure Virtual Machine

• 其他 Windows Server 環境

不過，SSRS 本身是一個完整的伺服器產品，不能直接安裝在 Azure Web App 裡。通常需要另外準備 Windows Server 或 Azure VM。

---

四、方案三：Power BI Report Server

微軟還提供 Power BI Report Server。

它同樣可以部署在公司內部或 Windows Server 上，並支援 Paginated Report 和 RDL。

架構與 SSRS 類似：

Blazor Web App
    ↓
Power BI Report Server
    ↓
RDL
    ↓
PDF

Power BI Report Server 除了分頁報表之外，也支援部分 Power BI 報表功能。

但是，如果系統主要需求只是執行 RDL 並輸出 PDF，SSRS 往往更直接。Power BI Report Server 的授權條件也需要另外確認。

---

五、能不能完全不使用報表伺服器，由 Blazor 自己生成？

理論上可以，但微軟目前沒有為現代 Blazor 或 ASP.NET Core 提供一套完整、方便的官方 RDL 本地渲染 SDK。

微軟過去提供過 ReportViewer 和 LocalReport。

概念上的程式碼如下：

LocalReport report = new LocalReport();

report.ReportPath = "Reports/帳票.rdlc";

report.DataSources.Add(dataSource);

byte[] pdf = report.Render("PDF");

這種方式可以由應用程式直接生成 PDF，不需要連線到 Power BI Service 或 SSRS。

但是它存在幾個重要限制。

---

六、LocalReport 主要處理的是 RDLC，而不是完整 RDL

RDL 和 RDLC 很相似，但用途不同。

簡單來說：

RDL
→ 通常交給 SSRS、Power BI Service 或 Power BI Report Server 執行

RDLC
→ 通常由應用程式在本地模式中執行

RDL 中可以包含：

• DataSource

• SQL 查詢

• 報表參數

• 報表版面

而 RDLC 本地模式通常不會自己執行報表中的 SQL。

資料取得流程通常會變成：

Blazor 或後端程式
    ↓
自己執行 SQL
    ↓
取得 DataTable 或物件集合
    ↓
傳給 RDLC
    ↓
生成 PDF

也就是說，原本寫在 RDL 裡面的 SQL 和資料來源邏輯，可能需要移到 C# 程式中。

如果既有 RDL 已經包含完整的 SQL、參數和報表設計，那麼轉成 RDLC 可能會增加很多重寫工作。

---

七、微軟官方 ReportViewer 對 Blazor 支援不足

另一個問題是，微軟官方 ReportViewer 主要面向：

• ASP.NET WebForms

• Windows Forms

• .NET Framework

它不是專門為以下環境設計的：

• Blazor Web App

• ASP.NET Core

• .NET 8

• .NET 9

• .NET 10

因此，目前不存在這樣一個理想的官方套件：

Blazor .NET 10
+
完整 RDL
+
官方 NuGet
+
直接 Render PDF

雖然網路上有一些第三方或社群移植方案，例如：

• ReportViewerCore

• AspNetCore.Reporting

• FastReport

• Telerik Reporting

• DevExpress Reporting

• Bold Reports

• Stimulsoft

但它們可能存在以下問題：

• 不是微軟官方產品

• 需要商業授權

• 對 RDL 的支援程度不同

• 不一定相容 Power BI Report Builder 產生的所有功能

• 複雜 Tablix、Subreport、Custom Code 或運算式可能無法完整執行

因此，第三方本地渲染方案需要逐份報表測試，不能直接假設與 Power BI Report Builder 完全相容。

---

八、幾種方案的比較

方案	RDL 放置位置	是否需要報表伺服器	是否使用雲端	Blazor 是否直接渲染
Power BI Service	Power BI Workspace	是，由微軟管理	是	否
SSRS	自建 Report Server	是	不一定	否
Power BI Report Server	自建 Report Server	是	不一定	否
ReportViewer／RDLC	Blazor 或後端工程	否	否	是，但支援受限
第三方報表引擎	工程或自建服務	視產品而定	不一定	可以

其中最容易誤解的一點是：

將 RDL 放進 Blazor 工程，不等於 Blazor 就具備 RDL 渲染能力。

文件可以放在工程中，但仍然需要一個可以理解 RDL 的渲染引擎。

---

九、對既有 RDL 遷移專案的建議

如果既有 RDL 已經具備以下條件：

• 已經寫好 SQL

• 已經設定資料來源

• 已經設定參數

• 已經完成版面設計

• 可以在 Power BI Report Builder 中直接預覽

• Web 端只需要點擊按鈕取得 PDF

那麼比較合適的方案通常是以下兩種。

雲端方案

Blazor Web App
    ↓
Power BI REST API
    ↓
Power BI Service
    ↓
PDF

這種方案適合使用 Azure Web App，並且不希望自己維護報表伺服器的情況。

自建方案

Blazor Web App
    ↓
SSRS
    ↓
RDL
    ↓
PDF

這種方案適合公司已經擁有 Windows Server、SQL Server 授權或內部基礎設施，並且希望避免依賴 Power BI 雲端服務的情況。

相對而言，不建議為了讓 Blazor 本地生成 PDF，而把大量完整 RDL 改造成 RDLC。

這樣做可能需要：

• 將 SQL 從報表中移到 C#

• 重寫資料取得邏輯

• 重新處理參數

• 驗證版面相容性

• 測試分頁與 PDF 輸出

• 處理第三方套件的相容性和授權

如果報表數量很多，維護成本可能比部署 SSRS 或使用 Power BI Service 更高。

---

十、最終結論

把 RDL 放進 Blazor Web App 工程後，RDL 不會自己變成 PDF。

完整流程必須存在一個報表渲染引擎。

這個渲染引擎可以是：

Power BI Service

也可以是：

SQL Server Reporting Services

或者：

Power BI Report Server

也可以改用 RDLC 或第三方報表套件，由應用程式本地渲染。

但在目前的微軟技術體系中，並不存在一個對 Blazor 和現代 .NET 完整支援、可以直接載入任意 RDL 並生成 PDF 的官方輕量級 SDK。

因此，最準確的理解是：

RDL 不一定必須放到雲端，但必須交給某個報表引擎。Power BI Service 是雲端引擎，SSRS 和 Power BI Report Server 是可自行部署的引擎，而 Blazor 本身並不是 RDL 渲染引擎。

This article was last edited at 2026-07-13 13:44:54 JST

Related Articles

• 从 Access VBA 重构到 Microsoft Power Platform：这不是迁移，而是整套系统重做

  结论：不是“迁移”，而是“重做一套”。Access 的数据可以迁到 Dataverse，但 VBA、窗体 UI、报表、复杂按钮逻辑基本不能原封不动搬过去。你这个方向等于是把「処理状況等管理システム」迁到 Power Platform

  2026-05-13 15:00:58 JST | PowerPlatform | 17 reads
• Access 系統移行到 Power Platform 時的三種架構方案比較：Dataverse、Azure SQL、Azure Functions 的差異

  最近在研究一個既有的 Access 系統移行問題。這類 .accdb 系統通常不只是「資料庫檔案」，而是把資料表、查詢、畫面、VBA、報表、列印預覽等功能全部包在一起的小型業務系統。以「処理状況等管理システム」這類 Access 系統為例，它本身就是準備往 Power Platform 方向移行的既有 Access 系統

  2026-05-20 14:25:40 JST | PowerPlatform | 12 reads
• Dataverse 路線下，Access SQL 不能直接搬過去嗎？——Power Apps / Power BI / Dataverse View 的分工整理

  在 Access 系統移行到 Power Platform 時，最容易誤解的一點是： 「既然資料都搬到 Dataverse 了，那我原本 Access 裡寫好的 SQL，是不是可以直接拿來用？」 答案其實很殘酷： 如果後端選 Dataverse，那麼 Power Apps、Power BI、Dataverse View 這三個地方，基本上都不是直接寫 SQL 的地方。 這也是為什麼傳統 Access 系統移行到 Dataverse 時，不能單純理解成「把資料庫搬過去」。 它更像是把原本集中在 Access 查詢裡的邏輯，拆散到 Power Platform 的不同元件裡

  2026-05-20 13:16:35 JST | PowerPlatform | 12 reads
• Azure Functions 发布成功但 API 返回 HTTP 500 的处理手顺

  ——以 Azure SQL Database 连接设定缺失为例 在使用 Visual Studio 发布 Azure Functions 时，可能会遇到这样一种情况： 发布画面显示

  2026-06-04 09:41:33 JST | PowerPlatform | 10 reads
• Access 帳票要移行到 Power Platform，最小成本到底該用什麼做輸出？

  最近在思考一個很現實的問題： 如果原本的系統是 Access + VBA + Report， 現在想移行到 Power Platform， 那原本 Access 裡面的「輸出帳票」到底該怎麼處理？ 很多人一聽到 Power Platform，就會直覺想到 Power Apps、Power BI、Dataverse、Power Automate。 但如果問題是「帳票輸出」或「印刷」，答案其實不一定是 Power BI

  2026-05-20 13:23:51 JST | PowerPlatform | 9 reads
• Power Apps 使用 Launch 或 Custom Connector 呼叫 Azure Functions API 的簡單記錄

  ​ 最近測試了從 Power Apps 呼叫 Azure Functions API 的方法。 最開始使用的是 Launch()，例如： Launch("https://xxxxx.azurewebsites.net/api/Function1?code=xxxxx") 這種方式確實可以觸發 Azure Functions ​

  2026-05-29 09:43:54 JST | PowerPlatform | 8 reads