在大型 C# 应用程序上进行批量名称空间重命名的最佳方法是什么?
首先,介绍一下背景。
目前,我们的代码库中的命名空间和程序集(约 60 个程序集、数千个类)看起来像
WidgetCompany.Department.Something
我们现在已经被剥离,因此我们正在销售驱动 WidgetCompany 的软件,因此我们想重命名命名空间和程序集。程序集
NewCompany.Something
在正常情况下,我可能只会坚持使用旧的命名空间,但问题是我们的客户不希望在应用程序的任何位置看到其竞争对手之一的名称。如果他们看到堆栈跟踪、程序集属性等,那么它不应该显示。这并不是为了隐藏我们的同事或做任何邪恶的事情,我们只是需要确保人们知道我们是一个独立的实体,独立的管理,并且他们不需要担心数据被共享等。
现在是问题。执行这种全方位重命名的最佳方法是什么? 以下内容需要更改:(
- 几乎)每个类的命名空间 应用程序
- 中引用旧名称的每个
using
语句 - 每个项目的文件夹结构
- 依赖于已更改的文件夹结构的项目之间的引用
- 引用已更改的文件夹结构的 .Sln 文件
- 对的任何引用 那些完全被 合格(应该是少而远 之间)
- 对这些的任何引用 xml 配置文件中的类(config 节等)
- 每个程序集的 AssemblyInfo.cs 文件
- 每个 .csproj 文件中的 AssemblyName
我是否坚持使用查找-替换-祈祷策略,还是有更好的方法?
First, a little background.
Currently namespaces and assemblies in our codebase (~60 assemblies, thousands of classes) looks like
WidgetCompany.Department.Something
We have now been spun off such that we are selling the software that drives a WidgetCompany, so we 'd like to rename the namespaces & assemblies
NewCompany.Something
Under normal circumstances I'd probably just stick with the old namespace, but the problem is our customers don't want to see the name of one of their competitors anywhere in the application. In the off chance that they see a stack trace, assembly properties etc, it shouldn't show up. It's not meant to hide our associates or do anything sinister, we just need to make sure that people know we are a separate entity, separate management, and they don't need to worry about data being shared etc.
Now the question. What is the best way to perform this type of all encompassing rename?
The following would need to change:
- Namespace for (almost) every class in
the application - Every
using
statement in the application which references the old names - Folder structure for each project
- References between projects which rely on changed folder structure
- .Sln files which reference the changed folder structure
- Any references to
those classes which are fully
qualified (should be few and far
between) - Any references to those
classes in xml config files (config
sections etc) - AssemblyInfo.cs files for every assembly
- AssemblyName in every .csproj file
Am I stuck with the find-replace-pray strategy or is there something better?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
右键单击您当前的命名空间并选择 Refactor ->重命名并在稍后出现的弹出窗口中更改名称。输入您的新名称并单击“确定”。
如果您的命名空间有多个深度,则 Visual Studio 将不允许您键入点。但是,如果您复制并粘贴一个点,尽管有警告,它仍然可以正常工作。
要完全更改为新名称,您可能需要手动进行其他更改。您可以通过执行项目搜索 (ctrl+shift+f) 来查找项目、解决方案或来自单独文本编辑器(如 VS Code)的其他支持文件中名称的其他引用。最后,文件夹可能还需要手动更改。
Right click on your current namespace and select Refactor -> Rename and change the name in the pop up that comes up after a while. Enter your new name and click ok.
If you have multiple depths to your namespace, then Visual Studio won't let you type a dot. However, if you copy and paste a dot, despite a warning, it will do the business.
To completely change to the new name, you will likely need to make additional changes manually. You can find where by performing a project search (ctrl+shift+f) for other references to the name in the Project, Solution, or other supporting files from a separate text editor like VS Code. Finally, folders may need to be changed manually as well.
对于 Visual Studio 2022,这个问题终于得到了解决:
整个项目中的命名空间现在应该反映文件夹结构。
For Visual Studio 2022 this has finally been solved:
The namespaces in your entire project should now reflect the folder structure.
重新锐化。从 JetBrains 免费获取 5.1 版本 30 天(足够的时间进行重命名)。将光标放在要更改的命名空间上,然后按 Ctrl-R 两次(ReSharper 重命名)。它将与任意深度的命名空间一起使用,并将该命名空间的任何用法转换为新的命名空间。但是,您必须更改解决方案中的每个唯一命名空间(除非您只是使用“查找/替换”)
ReSharper. Get version 5.1 from JetBrains for free for 30 days (more than enough time to do your renaming). Put the cursor on the namespace you want to change and hit Ctrl-R twice (ReSharper Rename). It'll work with a namespace any number of levels deep, and converts any usage of that namespace to the new one. However, you will have to change every unique namespace in your solution (unless you just go with Find/Replace)
Visual Studio 2019 Community Edition 支持此功能,如下所述 此处。它适用于任何层次结构(带有点、根命名空间更改等)并正确更新所有依赖项。
将光标置于类名称
按Ctrl +. 触发“快速操作和重构”菜单
选择移动到命名空间
在打开的对话框中,选择您想要将类型移至的目标命名空间< img src="https://i.sstatic.net/3MtXc.png" alt="选择命名空间对话框">
Visual Studio 2019 Community Edition supports this as described here. It works for any hierarchy (with dots, root namespace changes etc) and correctly updates all dependencies.
Place your cursor in the class name
Press Ctrl+. to trigger the Quick Actions and Refactorings menu
Select Move to namespace
In the dialog box that opens, select the target namespace you'd like to move the type to
如果您有 ReSharper:
右键单击项目,属性。将默认命名空间更改为所需的
命名空间。
右键单击项目,重构 -> 调整命名空间以更新所有
使用默认命名空间的命名空间
然后就让它发挥它的魔力。
If you have ReSharper:
Right click project, Properties. Change Default namespace to desired
namespace.
Right click project, Refactor -> Adjust Namespace to update all
the namespaces to use the default namespace
Then just let it do its magic.
首先,我会尝试
Refactor->Rename
选项。但正如另一个答案的评论中提到的,它的效果不是很好(或者我还没有找到如何让它发挥作用)。所以我更喜欢使用以下场景,特别是如果您想添加一些额外的命名空间。1) 使用
Refactor-Rename
将您的根命名空间 (WidgetCompany
) 重命名为NAMESPACE_TO_BE_REPLACED
2) 使用 find-n-replace 对话框将
NAMESPACE_TO_BE_REPLACED
替换为您的最终命名空间 (NewCompany.WidgetSoftware
)并且不要忘记重命名项目、默认命名空间等。
Firstly I would try
Refactor->Rename
option. But as mentioned in comment for another answers it doesn't work that good (Or I haven't found how to make it working). So I prefer using following scenario, especially if you want to add some addiotional namespace.1) Rename your root namespace (
WidgetCompany
) to something likeNAMESPACE_TO_BE_REPLACED
usingRefactor-Rename
2) Replace
NAMESPACE_TO_BE_REPLACED
with your final namespace (NewCompany.WidgetSoftware
) using find-n-replace dialogAnd do not forget to rename projects, default namespaces, etc.
如果您已经部分重命名,则可以使用替代解决方案:
.*
)YourSolution.YourProject
YourSolution.Your[partiallyRenamedNamespaceCharacters].*
整个解决方案
code> 被选择而不是当前文档
Alternative solution if you've already partially renamed:
.*
)YourSolution.YourProject
YourSolution.Your[partiallyRenamedNamespaceCharacters].*
Entire Solution
is selected notCurrent Document