桌面应用跨平台【免费下载链接】Electron.NET:electron: Build cross platform desktop apps with ASP.NET Core (Razor Pages, MVC, Blazor).项目地址https://gitcode.com/gh_mirrors/el/Electron.NET点击查看免费下载Electron.NET 通过 Visual Studio 项目系统与 MSBuild 深度集成让开发者可以用配置方式而非手工维护 Electron 工程文件。本文以docs/Using/Configuration.md为主线系统讲解 Electron.NET 的全部配置入口可视化 App Designer、.csproj中的 MSBuild 属性及其默认值、产品名与可执行文件名规则、自定义打包目录布局、构建扩展点、package.json自动生成机制、应用图标、Node.js 集成与 Preload 脚本并结合仓库源码ElectronNET.Core.props、ElectronNET.LateImport.targets、ElectronRootDirResolver.cs 等逐项印证底层实现帮助你在自定义构建流水线、CI 或特殊打包需求下精确掌控 Electron.NET 的行为。Visual Studio App Designer图形化配置入口Electron.NET 通过 Visual Studio 项目系统Project System与 MSBuild 提供紧密集成。在项目中添加 ElectronNET.Core即ElectronNET包之后双击项目中的Properties文件夹或右键项目选择「属性」即可在项目配置页看到 Electron.NET 提供的配置界面App Designer 中呈现的每一项设置本质上都是下文将要讲解的 MSBuild 属性的可视化封装。界面写入的值会被保存到.csproj的PropertyGroup中与直接手写 XML 完全等价二者可以随时互切。Project File SettingsMSBuild 属性与默认值App Designer 中的设置同样可以通过手工编辑.csproj中的 MSBuild 属性来完成。当你未做任何修改时Electron.NET 会使用以下默认值与源码中的 ElectronNET.Core.props 第 422 行的ElectronNetCommonPropertyGroup 完全一致PropertyGroup LabelElectronNetCommon ElectronVersion30.4.0/ElectronVersion ElectronBuilderVersion26.0/ElectronBuilderVersion RuntimeIdentifierwin-x64/RuntimeIdentifier ElectronSingleInstancetrue/ElectronSingleInstance ElectronSplashScreen/ElectronSplashScreen ElectronIcon/ElectronIcon ElectronPackageId$(MSBuildProjectName.Replace(., -).ToLower())/ElectronPackageId ElectronBuilderJsonelectron-builder.json/ElectronBuilderJson Title$(MSBuildProjectName)/Title ElectronExecutableName/ElectronExecutableName ElectronRootDir../../ElectronRootDir ElectronSkipExecCommandsfalse/ElectronSkipExecCommands /PropertyGroup各属性的作用与默认值规则如下属性默认值说明ElectronVersion30.4.0打包所使用的 Electron 版本会写入生成的package.json的devDependencies.electron并作为electron-builder的-c.electronVersion参数ElectronBuilderVersion26.0发布时安装的electron-builder版本见 ElectronNET.LateImport.targets 中npm install electron-builder$(ElectronBuilderVersion)的调用RuntimeIdentifierwin-x64.NET 应用的目标运行时标识同时决定 Electron 的平台与架构在ElectronResolveRuntimeIdentifier目标中被解析为ElectronRuntimeIdentifierElectronSingleInstancetrue是否启用应用单实例模式以 JSON 布尔值写入生成的package.json的singleInstance字段ElectronSplashScreen空启动画面图片路径写入package.json的splashscreen.imageFileElectronIcon空应用图标路径支持.ico、.icns与 macOS.icon目录详见下文「App Icon Path」ElectronPackageId$(MSBuildProjectName.Replace(., -).ToLower())包标识符项目名中的点替换为连字符并转为小写例如My.App→my-app。用于package.json的name、build.appId及 Linux/macOS 下的可执行文件名ElectronBuilderJsonelectron-builder.jsonProperties目录下 electron-builder 配置文件的文件名Title$(MSBuildProjectName)产品名见下文ElectronExecutableName空按平台推断包内可执行文件的名称electron-builder 的executableNameElectronRootDir../..Electron 二进制相对 .NET 应用目录的路径见「Custom Packaging Layout」ElectronSkipExecCommandsfalse跳过所有npm/npx命令见「Build Extensibility」注意源码中的默认属性大多带有Condition$(属性) 守卫如ElectronRootDir、ElectronSkipExecCommands这意味着只有在外部未设置时默认值才会生效——你可以在Directory.Build.props或命令行中覆盖它们。RuntimeIdentifier 的解析时机从 ElectronNET.LateImport.targets 的ElectronResolveRuntimeIdentifier目标第 100112 行可以看到ElectronRuntimeIdentifier是在执行期解析的优先取$(RuntimeIdentifier)其次在 Core MSBuilddotnetCLI下推断当前机器 RID最后在 Full MSBuildWindows 上的 Visual Studio下按 OS 架构推断为win-arch。因此来自项目文件、发布配置文件或命令行传入的RuntimeIdentifier总能优先生效。ElectronRuntimeIdentifier还会被映射为 Electron 的ElectronArch如win-x64→x64、linux-arm→armv7l、osx-arm64→arm64与ElectronPlatformwin/linux/mac用于版本检查、npm 参数和跨平台发布校验。Product Name and Executable Name产品名与可执行文件名Title是应用的产品名product name。它被用于窗口标题安装程序的显示名称macOS 应用 bundle 名称Linux 桌面入口desktop entry名称。因为上述场景允许空格等不适合作为文件名的字符Title与文件名是解耦的——这正是ElectronExecutableName存在的意义。ElectronExecutableName控制包内可执行文件的名称对应 electron-builder 的executableName。当它未被显式设置时按目标平台默认如下目标平台默认值Windows$(Title)Linux / macOS$(ElectronPackageId)该推断逻辑在源码 ElectronNET.LateImport.targets 第 48 行实现当RuntimeIdentifier以win开头时取$(Title)否则取$(ElectronPackageId)。例如要发布一款产品名为My Great App、各平台二进制均为mygreatapp的应用PropertyGroup TitleMy Great App/Title ElectronExecutableNamemygreatapp/ElectronExecutableName /PropertyGroup[!NOTE]ElectronExecutable是另一个独立的进阶设置它指定 .NET 应用先启动DotNet-First 启动时 Electron.NET 实际启动的二进制文件。它默认等于ElectronExecutableName仅当包内包含一个需要优先启动的启动器桩程序例如由 electron-builder hook 添加的 launcher stub时才需要改动。该值连同ElectronVersion、ElectronRootDir、RuntimeIdentifier等会以 AssemblyMetadata 的形式写入程序集见 ElectronNET.Core.targets 第 2535 行消费端对应 BuildInfo.cs供运行时读取。Custom Packaging Layout自定义打包目录布局ElectronRootDir告诉 .NET 应用在「先启动 .NET、再拉起 Electron」即打包应用的 DotNet-First 启动场景下去哪里寻找 Electron 二进制。路径相对于 .NET 可执行文件所在目录解析绝对路径则原样使用。默认值../..恰好匹配dotnet publish产生的标准 Electron-First 打包布局——.NET 应用被放置在 Electron 包的resources/bin下install-root/ MyApp # Electron 可执行文件 resources/ bin/ MyApp # .NET 可执行文件若你自己的打包流水线把 .NET 可执行文件放在包根目录、而 Electron 放在子目录中则按需设置ElectronRootDirElectronRootDirelectron/ElectronRootDirinstall-root/ MyApp # .NET 可执行文件 electron/ MyApp # Electron 可执行文件 resources/ locales/该属性还参与打包/未打包模式检测只有它指向的目录确实包含 Electron 二进制运行时才能正确判断当前处于哪种模式。这一点在源码中有直接印证ElectronRootDirResolver.cs 定义了DefaultElectronRootDir ../..并在ElectronNetRuntime.BuildInfo.ElectronRootDir为空时回退到该默认值随后用Path.GetFullPath(Path.Combine(baseDirectory.FullName, rootDir))解析绝对路径——绝对路径由此天然「原样使用」UnpackagedDetector.cs 的CheckUnpackaged2()会在「.exe所在目录名为bin且父目录名为resources」时判定为打包模式否则检查ElectronRootDir指向的目录下是否存在 Electron 可执行文件——这也印证了文档强调的「必须指向真正包含 Electron 二进制的目录」。Build Extensibility构建扩展点当 Electron.NET 被嵌入自定义构建或 CI 流水线时以下属性非常实用属性默认值说明ElectronSkipExecCommandsfalse跳过 Electron 构建与发布目标中所有npm/npx调用。当依赖与 Electron 发行版由流水线自身提供例如来自缓存或离线镜像时使用ElectronIntermediatePublishDir$(IntermediateOutputPath)PubTmp\覆盖 .NET 应用在被组装进 Electron 包之前所发布的中间目录ElectronSkipExecCommands在 ElectronNET.LateImport.targets 中控制三处关键执行构建时的npm install --no-bin-links与node node_modules/electron/install.jsElectronConfigureApp目标、发布时的npm install --omitdev安装应用运行时依赖与最终npx electron-builder ...调用——所有Exec任务都带有Condition$(ElectronSkipExecCommands) ! true条件。开启后整个流水线变成纯文件操作非常适合离线 CI。ElectronIntermediatePublishDir由ElectronSetIntermediatePublishDir目标处理对于非 ASP.NET 项目它会将PublishDir重定向到该中间目录默认$(IntermediateOutputPath)PubTmp\并在发布完成后由ElectronPublishApp目标恢复原始PublishDir。ElectronPackageId与Title仅在未被设置时才回退到项目名源码中分别以Condition$(ElectronPackageId) 与Condition$(Title) 守卫因此两者都可以在Directory.Build.props中统一定义或直接通过命令行传入。Relation to package.jsonMSBuild 属性如何映射到 package.jsonElectronNET.Core 已不再使用electron-manifest.json文件。由于 electron-builder 仍然要求存在package.jsonElectronNET.Core 会在构建期间自动生成它。以下是所使用的package.json模板仓库中实际模板位于 package.template.json与文档展示的映射一致可以看到 MSBuild 属性与package.json数据的对应关系{ name: $(ElectronPackageId), productName: $(ElectronTitle), build: { appId: $(ElectronPackageId), win: { executableName: $(ElectronExecutableName) }, mac: { executableName: $(ElectronExecutableName) }, linux: { desktop: { entry: { Name: $(Title) } }, executableName: $(ElectronExecutableName) }, deb: { desktop: { entry: { Name: $(Title) } } } }, description: $(Description), version: $(Version), main: main.js, author: { name: $(Company) }, license: $(License), executable: $(TargetName), singleInstance: $(ElectronSingleInstance), homepage: $(ProjectUrl), splashscreen: { imageFile: $(ElectronSplashScreen) } }这一映射由 ElectronNET.LateImport.targets 的ElectronCreatePackageJson目标完成它把ElectronPackageId、Title、ElectronTitle、Version、Description、ProjectUrl、License、Company、ElectronSplashScreenFileName、ElectronVersion、TargetName、ElectronSingleInstance等值打包为TemplateProperty通过ReplaceTemplateTask填充模板并输出到中间目录$(IntermediateOutputPath).electron\package.json随后随构建输出进入.electron目录。其中有两个值得注意的细节源码第 130141 行Version会被正则压缩为最多三段^\d\.\d\.\d以符合部分打包工具的版本规范针对 Linux 目标ElectronTitle会用连字符替换Title中的空格$(Title.Replace( , -))因为 electron-builder 在 Linux 上以 title 作为安装目录名不应包含空格。App Icon Path应用图标路径ElectronIcon属性支持经典图标文件如.ico和.icns也支持现代 macOS 的.icon应用图标包。对于.ico/.icns等单文件图标直接给出文件路径即可构建时会被复制到输出的.electron目录对于.icon图标包提供文件夹路径例如Assets/MyApp.icon。构建/发布期间Electron.NET 会把整个目录复制进 Electron 输出以便electron-builder.json引用它例如mac: { icon: MyApp.icon }。源码印证见 ElectronNET.LateImport.targets 的ElectronGetCopyToOutputDirectoryItems目标第 329376 行当ElectronIcon指向一个存在的目录时_ElectronIconDirectoryFiles会递归收集该目录下所有文件并以$(ElectronDirName)\$(ElectronIconFileName)\%(RecursiveDir)...的目标路径复制否则单文件图标走_ElectronFilesToCopy常规复制。Node.js IntegrationNode.js 集成开关Electron.NET 的 IPC 功能依赖 Electron 渲染进程开启 Node.js 集成。如果你完全不需要 IPC 功能可以像下面这样关闭 Node.js 集成从而降低渲染进程的暴露面更安全WebPreferences wp new WebPreferences(); wp.NodeIntegration false; BrowserWindowOptions browserWindowOptions new BrowserWindowOptions { WebPreferences wp };这里WebPreferences、BrowserWindowOptions均来自 ElectronNET.API 的实体层仓库中对应 WebPreferences.cs 与 BrowserWindowOptions.cs最终会通过 Socket 桥Bridge 与 SocketIOConnection.cs序列化后传递给 Electron 宿主进程中的 browserWindows.ts应用到new BrowserWindow({ webPreferences: {...} })上。关闭NodeIntegration后只要不用ipcMain/ipcRenderer通道其余功能窗口管理、菜单、通知、托盘等不受影响。Preload Script预加载脚本如果需要在窗口创建前执行脚本例如通过 preload 脚本暴露受控的桥接 APIElectron 官方的推荐做法可以在创建窗口时指定脚本路径WebPreferences wp new WebPreferences(); wp.Preload path/to/preload.js; BrowserWindowOptions browserWindowOptions new BrowserWindowOptions { WebPreferences wp };[!IMPORTANT] 同时使用 preload 脚本和Blazor 应用时IsRunningBlazor必须设置为false或删除并且必须在 preload 脚本中补充以下两行global.process undefined; global.module undefined;这是因为 Blazor 的运行时与 preload 脚本都依赖process/module全局对象二者共存时会产生冲突清除这两个全局变量可以避免 Electron 宿主环境与 Blazor 之间的全局污染。结语与后续路径至此你已经掌握了 Electron.NET 配置体系的完整脉络从 Visual Studio App Designer 的可视化配置到.csproj中每一项 MSBuild 属性的默认值与覆盖方式再到ElectronRootDir背后的打包目录语义、ElectronSkipExecCommands/ElectronIntermediatePublishDir的 CI 集成点、自动生成的package.json映射关系以及渲染进程侧的 Node.js 集成与 Preload 脚本。如需继续深入建议按以下顺序阅读仓库内的关联文档Startup Methods —— 理解各类启动场景DotNet-First / Electron-First 与打包/未打包模式Debugging —— 学习 ASP.NET 应用的调试特性Package Building —— 创建可分发的安装包其中「Custom Packaging Pipelines」一节与本文的ElectronRootDir、ElectronSkipExecCommands直接呼应。综合本文与 ElectronNET.Core.props、ElectronNET.LateImport.targets、ElectronRootDirResolver.cs 等源码你可以完全掌控 Electron.NET 在构建与打包阶段的每个开关按需接入自定义 CI/CD 流水线。赞分享桌面应用跨平台【免费下载链接】Electron.NET:electron: Build cross platform desktop apps with ASP.NET Core (Razor Pages, MVC, Blazor).项目地址https://gitcode.com/gh_mirrors/el/Electron.NET点击查看免费下载相关推荐Conan与Visual Studio集成MSBuild工具链配置终极指南Conan与Visual Studio集成MSBuild工具链配置终极指南 Conan作为开源C/C包管理器为Visual Studio开发者提供了强大开发工具包管理器构建工具CLISquirrel.Windows 集成指南将 NuGet 打包与 Releasify 自动化嵌入 Visual Studio MSBuild 构建流程Squirrel.Windows 集成指南将 NuGet 打包与 Releasify 自动化嵌入 Visual Studio MSBuild 构建流程 导读开发工具ok-ww完整指南如何把鸣潮刷声骸与日常一键交给后台自动战斗ok ww完整指南如何把鸣潮刷声骸与日常一键交给后台自动战斗 ok ww 是一款免费开源的鸣潮自动化程序基于图像识别技术只读画面、不读内存、不改文件。它替GUI 自动化计算机视觉RPA人工智能上一篇ncmdump终极指南快速解密网易云音乐NCM格式的完整教程下一篇TypeScript 2.6 破坏性改动详解只写引用检测与环境声明中的导出约束创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考