部署C#项目须先按项目类型选择对应方式：ASP.NET Core/Azure Functions用“发布”选目标；Windows桌面应用选ClickOnce或文件夹；Console App需手动dotnet publish；类库不可发布。
Visual Studio 部署 C# 项目没有统一的“标准步骤”，因为部署方式完全取决于项目类型和目标环境——ASP.NET Core、Windows 桌面（WinForms/WPF）、Azure Functions 或 Console App 各自走的路径完全不同，强行套用同一套流程必然失败。
区分项目类型再选发布入口
VS 的“发布”功能不是万能按钮，它只对特定项目模板生效。关键看你的 .csproj 文件里是否包含 <Project Sdk="Microsoft.NET.Sdk.Web">（Web）、<Project Sdk="Microsoft.NET.Sdk">（控制台/类库）或 <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">（桌面）这类声明。
-
ASP.NET Core和Azure Functions：右键项目 → “发布” → 可选“文件夹”“Azure”“IIS”等目标 -
Windows 桌面应用（.NET 5+）：右键项目 → “发布” → 必须选“ClickOnce”或“文件夹”，但不能选“Azure” -
Console App：默认不显示“发布”菜单项；需手动配置为自包含部署（dotnet publish -r win-x64 --self-contained true）或改用发布配置文件 -
类库（.dll）：没有“发布”选项——它不是可部署的运行单元，而是被其他项目引用的依赖
文件夹发布时路径权限和结构陷阱
选“文件夹”作为发布目标最常见，但实际部署后常报错，根源往往不在代码而在路径本身。
- 目标文件夹路径不能含中文、空格或特殊符号（如
C:My App会触发 MSB3277 警告） - 若路径是网络共享（如
\serverdeploy），必须确保构建用户对该 UNC 路径有写入权限，否则静默失败且无明确错误提示 -
ASP.NET Core发布后生成的是扁平化结构（web.config、MyApp.dll、refs/等同级），而 IIS 要求该文件夹直接设为网站物理路径——不能多套一层子目录 -
ClickOnce发布到文件夹后，必须从Publish.htm或setup.exe启动安装，直接双击.application文件会因安全策略被系统拦截
发布配置文件（.pubxml）的手动编辑必要性
VS 图形界面生成的 .pubxml 文件经常漏掉关键参数，尤其在跨环境部署时。
- ASP.NET Core 项目若需启用 Windows 身份验证，必须手动在
.pubxml中添加：<PropertyGroup> <WindowsAuthentication>true</WindowsAuthentication> <AnonymousAuthentication>false</AnonymousAuthentication> </PropertyGroup>
- 自包含部署需强制指定运行时标识符（RID），例如
<RuntimeIdentifier>win-x64</RuntimeIdentifier>，否则dotnet publish会报错“无法解析运行时” - 发布到 Azure 时，
.pubxml里的<_SavePublishSettings>若为false，则下次打开发布向导会丢失上次配置，需手动设为true
真正卡住人的从来不是“怎么点下一步”，而是发布后程序跑不起来时，不知道该查 web.config 还是 appsettings.Production.json，或是没意识到 ClickOnce 应用根本不会读取你本地调试时设的环境变量——这些细节藏在项目类型和发布目标的组合逻辑里，跳过分类直接操作，等于蒙眼拆炸弹。
