您一直在此站点上拖放文件以阅读它们。某个时刻会有人问，是否可以把同样的功能嵌入您正在开发的应用中——比如案件文件、索赔单、图纸，在您自己的页面中打开而不是下载。答案是可以，而且实现的难度比想象中小，因为真正改变的只有一件事。
唯一改变的事：文件的去向
在这里，您把文档上传给我们，它被渲染，关闭后即被删除。这对于一次性发送、只想现在阅读的文件来说是恰当的取舍。
但这并不适用于您无权移动的文档。医疗记录、已签署的合同、受 NDA 约束的图纸——这些都不能离开您的基础设施，单纯的删除承诺也无法解决，因为文件已经被传输。将渲染器嵌入后情况相反：文档由您的服务器在内部网络中打开，浏览器收到的只是渲染结果，文件从未离开。
这就是嵌入的原因。其他的都只是细节。
它是组件，而不是小部件
人们常犯的第一个错误是：这不是在浏览器中打开文件的 JavaScript，而是您在项目中引用的原生 .NET 组件，渲染在服务器端完成。您的页面只接收渲染后的结果。
由此产生两个后果。好的方面是：浏览器无需安装任何插件、ActiveX 或阅读器——因此在受限的桌面环境和手机上都能正常工作。需要规划的方面是：服务器承担渲染工作，所以 200 页的 PDF 与 40 MB 的图纸并不是同等请求。请为您可能接受的最大文件配置机器，并在上传时拒绝更大的文件。
开始之前必须决定的事项
三个问题，且都与查看器本身无关：
- 文档来源于何处——数据库、文件共享、Blob 存储？
- 谁有权查看该文档，查看器的 URL 是否强制此权限，还是仅仅假设？任何人只要知道文档 ID 就能访问的渲染端点是典型的安全漏洞。
- 渲染产生的临时文件何时以及如何处理？
回答这些问题后，集成工作就很简短。若把这些留到后面再处理，就会在已经可用的查看器上额外加装授权，结果更糟。
运行环境
支持 .NET Framework 4.0 及以上、.NET Standard 2.0 及以上——因此可用于 WebForms、MVC、ASP.NET Core、Blazor Server 以及 Linux 容器。服务器上无需安装 Office；渲染器直接读取相应格式。
如果您今天只想读取单个文件，可以使用PDF 查看器以及此处的其他查看器。如果您考虑的是整个应用程序，那么组件、其 NuGet 包以及 API 文档都在Doconut.com。