我希望这不是一个模糊的问题。我希望人们可以通过多种方式实现它，而我使用的方法似乎过于劳动密集。
如何将表示层项目（XAML / WPF）拆分为几个临时的＆＃34;并排＆＃34;项目，以便我可以在VS 2015中有效地进行增强，并快速对它们进行单元测试？最终的结果是，一旦单元测试成功，我就会将项目重新组合起来（重点关注组织而不是开发人员的效率）。
对我来说问题是不分析相互依赖关系，不识别项目边界之一，不添加之一新创建的（临时）项目在需要的地方引用。我遇到的最大的问题是所有愚蠢的XAML命名空间引用（clr-namespace :)。他们需要更新，以便他们指向引用资源的新主程序集（assembly =）。这是一个吨的开销，并不总是有回报，因为它首先是临时工作。为我做这个的工具在哪里？然后将其恢复原状以便我不会意外地将XAML临时更改提升为源代码控制？
我考虑过为WIP开发管理一套完全独立的sln和csproj，但基于这些XAML命名空间引用（clr-namespace :)工作方式的相同根本原因，这是不可能的。 。此外，作为一个团队的努力，这很难做到。
更多信息：
我问的原因是因为我们有许多带有XAML资源的项目（用户控件，资源字典等）。其中一些变得非常大，因为它们以某种方式组织，使它们成为放置东西的常见位置（即所有组合框查找 - ALT-down - 窗口，或所有常见数据模板，或者什么不是）。随着时间的推移，它成为一个问题，因为VS构建操作需要太长时间（影响开发效率）。对于大型项目，VS构建操作会变慢：
一个包含所有数据模板集中列表的项目可能在依赖堆栈中有很多东西，导致众多其他项目在每次更改后重建
任何具有任何中央存储库的项目都会变得很大并且需要很长时间才能编译（5秒/项目是我的极限，而我正在积极开发XAML，上限为10秒完成整个构建操作并开始调试）
答案 0 :(得分：1)
我遇到的最大问题是所有愚蠢的XAML命名空间 引用（clr-namespace :)。他们需要更新，以便他们指出 新的家庭组件（assembly =）
一般来说，当重构xaml时，ReSharper做得很好。它分析xaml文件，并修复错误的xml命名空间。但是，您需要逐个删除所有文件。
您也可以使用普通的查找/替换对话框，并将;assemmly=TempProject替换为空字符串。如果您需要更频繁地执行此操作，请为其编写powershell脚本。
然后将其恢复原状，这样我就不会意外地进行宣传 临时XAML更改为源代码管理？
在办理签到时，您需要小心，将文件与原始版本进行比较并调查更改
但是，只有一个很好的解决方案。将项目拆分为wpf usercontrol库。不仅仅是出于测试目的，而是永久性的。尝试打破您的大型资源文件。在处理大型项目时，不要使用像common place to put stuff这样的做法。考虑尽可能使用松散耦合设计和IoC（汇编注入而不是直接引用）。创建此共享程序集，所有其他程序集将引用该程序集。不要创建引用许多其他组件的组件，而是让其他组件自己注入。看一下prism的灵感：http://www.pluralsight.com/courses/prism-introduction