WPF项目Properties文件夹消失与AssemblyInfo补回

新建一个 WPF 项目，Solution Explorer 里从上到下翻一遍，只有 App.xaml、MainWindow.xaml 加两个 .cs 文件，以前那套Properties文件夹连影子都没有——没有 AssemblyInfo.cs，没有 Resources.resx，也没有 Settings.settings。第一次碰到这情况的开发者往往以为是自己装错了模板或者 IDE 抽风，其实什么都没坏，只是项目文件格式换代之后，微软把这一层"脚手架"从磁盘上的实体文件挪进了编译期的自动生成逻辑里。这篇就聊透这件事：Properties文件夹为什么默认不出现、缺了它到底影响哪些功能、想补回不同类型的文件该走哪条路径，以及在 WPF + .NET 组合下踩过的那些资源找不到、特性重复、本地化失效的坑。刚接手老项目迁移的同学、正在写自定义控件库的同学，以及被MissingManifestResourceException折腾过一轮的同学，都能从里面找到能直接抄的 csproj 片段和排查顺序。

1. Properties 文件夹消失这件事，得从项目文件格式换代说起

1.1 两代项目模板的时间分界线

先把结论摆出来：Properties文件夹从来不是 WPF 的硬性要求，它只是老式 .NET Framework 项目模板附带的一套"约定俗成的家当"。那个年代的 csproj 是一个巨长的 XML，里面把每一个 .cs、每一个 .resx 都显式列出来，编译顺序、依赖关系、代码生成器全靠 ItemGroup 手写维护。模板为了把这些零碎东西归置整齐，就在项目根目录建了个Properties文件夹，塞进程序集元数据、资源文件、用户配置三件套。换到 SDK 风格项目之后，csproj 变成了十几行的精简格式，文件包含靠通配符自动完成，程序集元数据则由 MSBuild 在编译时根据项目属性现生成一份，写到obj目录里再一起参与编译。既然元数据不再需要人肉维护，模板自然就把Properties这个"容器"省掉了。

这里有个容易被忽略的细节：省掉的只是模板默认生成的文件，不是文件夹本身的能力。你完全可以手动建一个Properties文件夹，往里放 AssemblyInfo.cs，编译照样通过，命名空间照样是项目名.Properties。很多人以为新版不支持这套老结构了，其实是误会。真正的限制在于：SDK 风格下项目属性会自动生成一批程序集特性，你手写的文件如果碰了同一批特性，编译器会毫不留情地甩出 CS0579，这才是需要重点处理的地方。

还有一类情况需要单独区分：用新版 IDE 打开一个老 .NET Framework 的 WPF 项目，项目文件没被迁移，那Properties文件夹里的东西原封不动都在；但如果这个项目被"升级"过——哪怕只是改成了 SDK 风格但不换目标框架——那些文件会被自动剔除，只留下一个空文件夹或者干脆连文件夹都没了。所以看到项目里没有Properties，第一件事不是急着补文件，而是先确认这个项目属于哪一代，后面的操作路径完全不同。

1.2 GenerateAssemblyInfo 替你写了什么、又漏了什么

理解Properties缺失的关键，是把GenerateAssemblyInfo这个 MSBuild 属性搞明白。它在 SDK 风格项目里默认是true，含义是：编译前 MSBuild 会扫描 csproj 里的一批属性，拼出一个.AssemblyInfo.cs临时文件扔到obj/Debug/net8.0-windows/下面，然后随项目一起编译。老模板里那些[assembly: AssemblyTitle]、[assembly: AssemblyVersion]、[assembly: AssemblyCompany]就是被这套机制接管的。

它接管了哪些、没接管哪些，必须心里有数。下面这张表是我照着obj目录里生成的文件逐条比对出来的：

表格里最后三行"否"的部分，就是补Properties/AssemblyInfo.cs时唯一需要手写的内容。ThemeInfo尤其特殊——它是 WPF 独有的程序集级特性，负责告诉运行时去哪里找主题资源字典，MSBuild 那套通用生成逻辑压根不认识它，所以无论你怎么配项目属性，它都不会凭空出现。老模板的 AssemblyInfo.cs 里雷打不动地写着这么一行，新模板不生成文件，这一行自然也就没了。

顺带提醒一个高频冲突：如果你习惯在 AssemblyInfo.cs 里写[assembly: NeutralResourcesLanguage("zh-Hans")]，同时又在新项目的 csproj 里配了<NeutralLanguage>zh-Hans</NeutralLanguage>，恭喜，CS0579 就在前面等你。这两个位置只能留一个，推荐用 csproj 属性，因为它是项目级声明，团队协作时一眼能看见。

1.3 缺失之后真正会疼的四个场景

只是编译一个 Hello World 的 WPF 窗口，没有Properties文件夹一丁点问题都没有。真正开始疼，是在下面这几种场景里：

第一种，自己写自定义控件库。控件库要在Themes/Generic.xaml里放默认样式，运行时靠ThemeInfo找到这份字典。少了这个特性，控件能编译能实例化，但样式静默失效——不报错、不抛异常，界面上就是一片白，全靠默认的Control模板撑着。这种"不报错的错误"排查起来最折磨人。

第二种，需要多语言资源。老模板自带Resources.resx，Properties.Resources.SomeString在代码里随手就能用。新项目里这个入口不存在，你得自己加 resx 文件、设生成操作、处理命名空间，还要面对RootNamespace变动导致的资源名错位。

第三种，项目里用InternalsVisibleTo做单元测试。老模板里这行写在 AssemblyInfo.cs，新项目得改成<InternalsVisibleTo Include="测试项目名" />，遇到强签名程序集还要补公钥。

第四种，从老项目搬迁代码。满屏的Properties.Settings.Default.XXX和Properties.Resources.XXX一到新项目就红成一片，编译都不给过。这种时候不是"要不要补文件夹"的问题，而是"补完之后命名空间对不对"的问题。

2. 三分钟定位：你的项目属于哪一代

2.1 看 csproj 头几行就够了

判断方式其实特别快，用文本编辑器打开 csproj，看根节点。

<!-- SDK 风格：一行搞定 --> <Project Sdk="Microsoft.NET.Sdk">

或者：

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

老式项目的根节点长得完全不一样，是一串带版本号的引用，开头大概是这样：

<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

看到xmlns那一长串，就是老式项目，Properties文件夹里的东西应该还在，只是可能被某些操作藏起来了。看到Sdk="..."，就是 SDK 风格，程序集信息由 MSBuild 代管。

还有一种中间态：csproj 是 SDK 风格，但TargetFramework还是net48。这种情况挺常见的——有人为了用新格式的项目文件，把老框架项目手动改成了 SDK 风格。这类项目的Properties文件夹可能被保留也可能被删，得实际打开看。判断标准跟目标框架无关，只看 csproj 格式：SDK 风格就按新路径处理。

另外，.NET 5之后Microsoft.NET.Sdk.WindowsDesktop这个 SDK 被合并了，WPF 项目统一用Microsoft.NET.Sdk加<UseWPF>true</UseWPF>来声明。这本身就是个很实用的识别特征：看到UseWPF就知道项目至少是 .NET 5 起步，Properties文件夹大概率不存在。

2.2 翻 obj 目录拿到最直接的证据

比看 csproj 更直接的办法，是去obj目录里找那份自动生成的 AssemblyInfo 文件。路径大致是obj/Debug/<目标框架>/<项目名>.AssemblyInfo.cs，用文本编辑器打开，里面白纸黑字列着当前项目自动生成了哪些程序集特性。

我习惯的做法是：需要手写Properties/AssemblyInfo.cs之前，先把这份文件读一遍。凡是它里面有的特性，手写文件里一律不碰；凡是它里面没有的，才往手写文件里放。这样从源头上就把 CS0579 规避掉了，比事后一条条删报错行省事得多。

obj目录还有个用途：确认资源文件的编译结果。obj/Debug/<目标框架>/下面能看到.resources中间产物，命名规则就是资源的逻辑名称。如果你怀疑资源名不对，直接看这个目录里的文件名，比运行时打日志猜要快。这个目录平时被.gitignore忽略，容易被人遗忘，但它在排查资源类问题时是最好用的证据链。

2.3 一份对照清单：哪些东西该补、哪些不该补

在动手补文件之前，先明确自己要解决什么问题。补Properties文件夹不是目的，让某个具体功能跑起来才是。

这张表里的判断逻辑很简单：能用 csproj 属性表达的，就别建文件；文件只用来承载 csproj 表达不了的东西。按这个原则走，新建的 AssemblyInfo.cs 里通常只有三四行代码，干净得很，也不会跟自动生成的特性打架。

3. 补回 Properties 文件夹的四条实操路径

3.1 只缺 AssemblyInfo.cs：手写最小集，别抄老模板

最省事的做法是在项目根目录右键新建文件夹，命名为Properties，再往里加一个类文件改名成 AssemblyInfo.cs。注意新建的时候选"类"模板会带一个namespace和一个空 class，这些要全部删掉——AssemblyInfo.cs 只放程序集级特性，不能有命名空间包裹，写了反而报错。

内容按最小集来：

using System.Runtime.InteropServices; using System.Windows; [assembly: ComVisible(false)] [assembly: Guid("3f2a7c91-6b4d-4e18-9a02-5d7c8b1e4f60")] [assembly: ThemeInfo( ResourceDictionaryLocation.None, ResourceDictionaryLocation.SourceAssembly)]

这段代码里三行特性各有分工。ComVisible(false)表示不向 COM 暴露，绝大多数托管程序都不需要暴露，写上是为了显式表态。Guid是程序集的唯一标识，老项目做 COM 互操作或者被其他非托管程序引用时有用，纯托管项目可以从老项目的 AssemblyInfo.cs 里原样搬过来，也可以随机生成一个。ThemeInfo的两个参数是重点，后面单独讲。

写完之后编译，如果蹦出CS0579 Duplicate 'System.Reflection.AssemblyTitleAttribute' attribute，说明你不小心把自动生成的特性也抄进来了。处理方式二选一：删掉重复行，或者在 csproj 里关掉自动生成。

<PropertyGroup> <!-- 关闭后 AssemblyVersion 等特性必须全部手写，慎用 --> <GenerateAssemblyInfo>false</GenerateAssemblyInfo> </PropertyGroup>

我在项目里基本不用GenerateAssemblyInfo=false，除非是那种必须完全掌控程序集特性的老系统。关掉之后Version、Company、Copyright全得手写，后续想统一改版本号还得改代码文件，得不偿失。保持开启、手写文件只放"漏网之鱼"，是更省心的姿势。

提示：Properties只是文件夹名，跟功能没有任何绑定关系。你叫它AssemblyInfos、Build、Meta都能正常工作，编译进程序集里也看不出区别。之所以沿用这个名字，纯粹是为了让接手老代码的人不用重新找地方。

3.2 需要多语言资源：Resources.resx 的添加顺序有讲究

resx 文件在 SDK 风格项目里加起来比以前轻松：右键项目 → 添加 → 新建项 → 资源文件，命名Resources.resx，扔进Properties文件夹就完事，csproj 完全不用改。原因是 SDK 默认启用了EnableDefaultEmbeddedResourceItems，**/*.resx会被自动识别为EmbeddedResource并参与编译。这一点很多人不知道，还在 csproj 里手动写 ItemGroup，写重了反而会报重复项。

真正要留心的是访问修饰符。resx 设计器右上角有个"访问修饰符"下拉框，默认是Internal，意思是生成的Resources类只能在当前程序集里用。如果你的类库要把资源暴露给外部程序集（比如主程序读取插件里的字符串），必须改成Public，然后保存，Designer.cs 才会重新生成。改完不生效的情况我也遇到过，通常是 Designer.cs 文件被设成了只读，或者它压根没被 VS 接管——检查文件属性里的"自定义工具"一栏，应该是ResXFileCodeGenerator，"生成操作"应该是EmbeddedResource。

如果 Designer.cs 不自动生成，可以手动在 csproj 里补上归属关系：

<ItemGroup> <Compile Update="Properties\Resources.Designer.cs"> <DesignTime>True</DesignTime> <AutoGen>True</AutoGen> <DependentUpon>Resources.resx</DependentUpon> </Compile> </ItemGroup>

这段配置一石二鸟：DependentUpon让 Designer.cs 在 Solution Explorer 里嵌到 resx 下面，看起来跟老项目一模一样；AutoGen和DesignTime则让 VS 知道这是个自动生成的文件，编辑的时候会给出警告。老项目迁移过来时，这段配置往往在改造过程中丢了，表现就是 resx 和 Designer.cs 平铺在一起，看着别扭，改 resx 也不触发重新生成。

还有一个细节值得单独说：resx 文件在 Solution Explorer 里的层级跟编译结果无关。你把 resx 放在Properties/下面，资源名就是项目根命名空间.Properties.Resources；放在Resources/下面就是项目根命名空间.Resources.Resources。放哪儿都行，但位置一变，代码里Properties.Resources.XXX的引用就得跟着改。所以老项目搬迁时，最省事的做法是把Properties文件夹整体复制过来，保持目录结构不变。

3.3 需要用户配置：Settings.settings 的现状要看清

这是四条路径里最需要克制的一条。老 WPF 项目的Properties里通常有Settings.settings和它的Settings.Designer.cs，代码里到处是Properties.Settings.Default.WindowWidth这类写法，保存时调Default.Save()，落盘位置在用户的漫游目录下。

到了 .NET Core 之后的 WPF 项目，这套机制的处境比较微妙：模板不再生成这个文件，相关 API 被拆进了额外的 NuGet 包，行为细节跟 .NET Framework 时代也有差异——配置文件的分层合并逻辑、用户级配置的写入路径、默认值的来源，都不是完全一致的。就算你把老项目的Settings.settings原样复制过来，也大概率会遇到设计器打不开、生成代码引用不到类型这类问题。

我的建议很直接：新项目别往这条路上走，用 JSON 配置文件替代。做法也不复杂，一个配置类加序列化就够了：

public sealed class AppSettings { public double WindowWidth { get; set; } = 1024; public double WindowHeight { get; set; } = 768; public string Theme { get; set; } = "Light"; }

读取时从用户目录下的固定路径加载 JSON，不存在就用默认值，保存时整体覆盖写回。好处是格式透明、能放进版本控制做默认配置、跨平台没有差异、调试时直接改文件就能验证。代价是要自己处理文件锁和并发写，不过桌面应用的配置写入频率极低，加个简单的锁就够了。

如果项目是纯粹的老代码搬迁，短期内不想动业务代码，那就先保留Settings.settings的结构，把相关包引用补齐，让它先跑起来；同时在任务清单里记一笔"配置模块重构"，等业务稳定了再切。这种"先通后优"的顺序比一上来全量重构稳妥得多。

3.4 老项目整体搬迁：RootNamespace 是隐藏地雷

把老项目的整个Properties文件夹拖进新项目，看着一切正常，编译也能过，但运行时可能直接抛MissingManifestResourceException。原因大多出在RootNamespace上。

老项目可能叫某公司.某产品.Client，根命名空间和程序集名一致，资源的完整逻辑名称就是某公司.某产品.Client.Properties.Resources。新项目如果按模板默认用了MyApp这种名字，逻辑名称就变成了MyApp.Properties.Resources，而 Designer.cs 里硬编码的ResourceManager构造参数还是老名字，两边对不上，运行时自然找不到资源。

解决办法是在 csproj 里把根命名空间钉死：

<PropertyGroup> <RootNamespace>某公司.某产品.Client</RootNamespace> <AssemblyName>某公司.某产品.Client</AssemblyName> </PropertyGroup>

改完之后 Designer.cs 会自动按新命名空间重新生成一遍，代码里的引用也就对上了。这个坑的隐蔽之处在于：编译期完全不报错，只有运行时走到取资源的那一行才炸，而且异常信息只说"找不到资源"，不告诉你它找的是哪个名字。排查的时候用Assembly.GetManifestResourceNames()把实际存在的资源名全打出来，跟代码里期望的名字一对比，问题立刻现形。

顺带说一个容易忽略的连带影响：RootNamespace变了，所有x:Class里写的命名空间也得跟着调，XAML 和 code-behind 必须一致，否则 XAML 编译阶段就会报找不到类型。所以搬项目的时候，改命名空间这件事要么一次改全，要么一次都不改。

4. 比文件夹本身更关键的三个技术细节

4.1 ThemeInfo 的两个参数到底在说什么

ThemeInfo是 WPF 独有的程序集特性，构造函数两个参数类型都是ResourceDictionaryLocation枚举，取值有None、SourceAssembly、ExternalAssembly三种。第一个参数管主题专用字典（就是themes/generic.xaml这种按系统主题分目录的资源），第二个参数管普通资源字典的查找位置。

老模板给的默认组合是None+SourceAssembly，含义是：不在当前程序集里找主题专用字典，但在当前程序集里找普通资源字典。放在应用项目里这个配置没问题，因为应用项目一般不写Themes/Generic.xaml。但如果你在做自定义控件库，第一个参数就必须改成SourceAssembly，否则控件库里那份Themes/Generic.xaml永远不会被加载，控件跑起来是裸的。

// 控件库的正确写法 [assembly: ThemeInfo( ResourceDictionaryLocation.SourceAssembly, ResourceDictionaryLocation.SourceAssembly)]

这个错误最坑的地方在于它完全静默。控件能 new 出来、能加进窗口、属性都能设，就是长得不对。我第一次遇到时以为是样式没写对，翻来覆去改 XAML，最后才发现根子上是程序集特性缺了。判断方式很简单：把控件放进窗口跑一下，如果它显示的是Control的默认模板（一个灰色方块或者空白），基本就是主题字典没被加载。这时候先去看Properties/AssemblyInfo.cs存不存在、ThemeInfo写没写，比调 XAML 快一百倍。

4.2 资源逻辑名称：一次配置失误能让你查一整天

.resx编译成.resources之后会被嵌入程序集，嵌入时用的名字叫逻辑名称，默认规则是<RootNamespace>.<相对路径去掉扩展名>，路径分隔符换成点。Properties/Resources.resx在RootNamespace为MyApp的项目里，逻辑名称就是MyApp.Properties.Resources。

问题出在项目被改名、被移动、或者从别的项目复制粘贴过来的时候。这时候RootNamespace变了，逻辑名称跟着变，而 Designer.cs 里那行new ResourceManager("MyApp.Properties.Resources", typeof(Resources).Assembly)可能还是老字符串。运行到第一次取资源，MissingManifestResourceException就来了。

如果因为某些原因不能改RootNamespace，可以在 csproj 里强行固定逻辑名称：

<ItemGroup> <EmbeddedResource Update="Properties\Resources.resx"> <LogicalName>MyApp.Properties.Resources.resources</LogicalName> </EmbeddedResource> </ItemGroup>

注意LogicalName的值要带上.resources后缀，跟默认生成的完全一致，否则还是对不上。这种写法属于"打补丁"，能用但不优雅，我的习惯是能改RootNamespace就改，改不了才用这招兜底。

排查这类问题时，那行代码是无价之宝：

foreach (var name in typeof(App).Assembly.GetManifestResourceNames()) { System.Diagnostics.Debug.WriteLine(name); }

把嵌入资源的实际清单全打出来，一条条跟期望的名字比对，比任何猜测都有效。我现在的习惯是在项目里留一个只在调试配置下编译的诊断方法，遇到资源问题直接调用，省去写临时断点的时间。

4.3 本地化资源与附属程序集：NeutralLanguage 别乱设

做多语言时，除了Resources.resx这个中性语言版本，还要为每种语言建一个Resources.zh-Hans.resx、Resources.en.resx这样的文件。它们在编译时不会进主程序集，而是各自生成一个附属程序集，放在<语言代码>/子目录里。

这里有个容易踩的坑：如果你的应用默认语言不是英语，而NeutralLanguage没设对，运行时可能会拿着一套错误的中性资源去回退。表现是某些界面文字该显示中文却显示了英文，或者反过来，而且换了系统区域设置还不一定复现。处理方式是在 csproj 里显式声明：

<PropertyGroup> <NeutralLanguage>zh-Hans</NeutralLanguage> </PropertyGroup>

声明之后，主程序集里那份资源会被标记为中文的"中性"回退，语言资源找不到时就落到它身上，行为可预期。这一点在Properties文件夹还存在的老项目里通常没问题，因为老模板会自动处理；转成 SDK 风格之后，这个属性如果没跟着搬过来，多语言就可能悄悄退化。

另外一个相关细节：附属程序集要能被正确加载，得保证它们被复制到了输出目录。默认情况下会复制，但如果项目里有自定义的输出路径规则或者后置生成事件在清理目录，容易误删。发布前我一般会打开输出目录看一眼，确认<语言代码>/子目录都在，这个动作只需要三秒钟，却能避免上线后用户反馈"界面全是英文"。

5. 报错现场实录：高频问题与排查顺序

5.1 编译期报错怎么快速定位

编译期最常撞见的是CS0579 Duplicate 'xxx' attribute。这个报错信息很明确，直接告诉你哪个特性重复了。处理逻辑分三步：第一步，去obj/Debug/<目标框架>/打开自动生成的 AssemblyInfo 文件，看这个特性是不是已经在里面了；第二步，如果已经在，把你手写文件里对应的那行删掉；第三步，如果这个特性必须由你控制（比如AssemblyVersion要精确到四段），就在 csproj 里关掉自动生成。

第二个常见的是CS0234 命名空间 "项目名" 中不存在类型或命名空间名 "Properties"。这说明代码里using 项目名.Properties;或者直接引用Properties.Resources，但对应的类根本没生成。原因通常是 resx 文件的"生成操作"不是EmbeddedResource，或者自定义工具没设成ResXFileCodeGenerator。有时候还会遇到 Designer.cs 存在但内容为空的诡异情况——那多半是文件被加进了项目又被排除，csproj 里的Compile项被Remove掉了，检查一下有没有多余的<Compile Remove="Properties\**" />这种配置。

第三个是修改 resx 后代码里新加的字符串不识别。这不是报错，是"没有效果"，比报错更烦人。八成是因为 VS 认为 resx 没变，没触发代码生成。手动右键 resx 选"运行自定义工具"就能强制刷新。我一般在改完资源后顺手看一眼 Designer.cs 的时间戳，确认它确实更新了，这个小动作能省掉大量"改了没生效"的困惑。

注意：从别的电脑或者代码仓库拉下来的项目，Properties文件夹可能完整，但 Designer.cs 因为.gitignore规则被忽略掉了，表现为编译报错一片。检查仓库的忽略规则，把*.Designer.cs的忽略项去掉，或者手动跑一次自定义工具重新生成。

5.2 运行期问题与排查速查表

运行期的问题更隐蔽，因为不报错最麻烦。MissingManifestResourceException会明确抛出，还算好办；主题字典失效、附属程序集没加载这类，全靠观察现象。

排查顺序我总结成一句话：先看编译产物，再看代码引用，最后才怀疑运行时环境。绝大多数资源类问题都能在前两步定位，扯上环境变量的情况极少。养成看obj目录的习惯，比在代码里到处打断点高效。

5.3 几个非常规但真实存在的坑

第一个是项目路径里带非 ASCII 字符。老式项目对路径的处理比较粗糙，某些版本的构建链在解析含中文或空格的路径时会出问题，表现出来的症状跟资源配置错误一模一样。如果别的项目都正常，只有某一个项目反复出资源问题，把项目复制到纯英文无空格路径下试一次，能排除掉一大类干扰。

第二个是强签名程序集里的InternalsVisibleTo。老项目里这行写在 AssemblyInfo.cs，搬迁后改成 csproj Item，但强签名程序集的InternalsVisibleTo必须带上公钥，只写程序集名不够。症状是测试项目编译不过，提示找不到 internal 成员。处理方式是用签名工具导出公钥，填到 Item 的Key属性里。这个细节在文档里藏得很深，我第一次遇到时查了很久。

第三个是共享项目或者多目标框架项目。同一个项目同时面向多个目标框架时，Properties文件夹里的资源会被编译多次，如果LogicalName被固定死了，可能出现不同框架下资源名冲突。这种情况下的正解是用条件属性，让不同目标框架走不同的配置，而不是硬编码一个名字。多目标项目本身复杂度就不低，如果只是桌面应用，能单目标就别多目标。

6. 我自己的几个固定做法

6.1 用 Directory.Build.props 统一收口版本信息

Properties/AssemblyInfo.cs在老项目里承担的最大职责其实是版本号和公司信息。这部分在 SDK 风格项目里完全不需要文件，一个Directory.Build.props放在解决方案根目录，所有子项目自动继承：

<Project> <PropertyGroup> <Version>1.4.2</Version> <Company>某个软件开发团队</Company> <Product>某桌面客户端</Product> <Copyright>保留所有权利</Copyright> </PropertyGroup> </Project>

单个项目要覆盖就在自己的 csproj 里再写一遍，后加载的赢。这样一来，发版时改一个文件就能让所有程序集的版本号同步，比在十几个 AssemblyInfo.cs 里翻找靠谱太多。我的项目里，Properties文件夹通常只剩下一个只有三行特性的 AssemblyInfo.cs，剩下的全交给 props 文件。

这套做法还有个附带好处：CI 流水线上可以用-p:Version=1.4.2-beta.3这种命令行参数覆盖版本号，构建脚本不用动任何源文件。在没有这套机制的年代，为了打一个带版本号的包，得写脚本去改 AssemblyInfo.cs，改完还得记得提交回去，特别别扭。

6.2 资源目录不一定非得叫 Properties

最后说个观念上的松动。很多人补Properties文件夹是因为代码里写着Properties.Resources，改起来牵一发动全身。但如果项目是新的，完全没必要沿用这个命名。我自己现在的习惯是建Resources/目录放 resx，命名空间自然就是项目名.Resources，读起来比Properties.Resources更直白——"属性"这个词承载资源本来就有点历史遗留的味道。

真要改老代码的命名空间，有个取巧的办法：在 resx 所在目录的命名空间上做一次全局替换，配合前面说的RootNamespace固定，一轮就能改完。前提是业务代码里对资源的引用都集中在少数几个文件里，如果散落在几百处，那就先别动，保持现状最省事。工程上很多"看起来不优雅"的东西，只要它稳定、团队都认识，就没必要为了审美去动它。

我个人的体会是，Properties文件夹缺不缺从来不是问题的核心，核心是搞清楚 SDK 风格项目把哪些职责交给了构建系统、哪些还留在开发者手上。把这条线划清楚之后，补文件就是几分钟的事，剩下的时间可以花在真正重要的地方——比如确认ThemeInfo有没有漏，比如确认发布出来的附属程序集齐不齐。这两件事任何一个出岔子，用户那边看到的就是"界面不对劲"或者"语言不对"，而你在本地调试时一切正常，那种感觉，经历过一次就再也忘不掉。