调试“插件”应用程序的一种无痛的方式？
我即将开始基于“插件”体系结构开发桌面应用程序（WPF），并打算使用MEF（及其DirectoryCatalog）来发现和加载插件程序集。我们将开发许多插件，因此将它们保留在单独的VS解决方案中似乎是明智的，而不是膨胀“核心”应用程序解决方案，但只从事单一，独立的解决方案，我怀疑这会使调试有点棘手。如果这有所作为，我使用VS2013。调试“插件”应用程序的一种无痛的方式？
我假设我还是可以步入中的场景插件，其中“核心”应用程序调用该插件的方法？而且我猜测那里有一次，我可以在那些已被“访问”的源代码文件中设置断点？但是如果我想将断点添加到不同的源代码文件 - 还没有在逐步过程中被访问？我如何打开该文件？在单个解决方案中，我可以通过解决方案资源管理器打开它，但不是（我猜测）它在单独的程序集中。
我试图抢先我可能有这个多解决办法的任何问题，并想知道如果VS过任何巧妙的功能，简化了一些这方面的东西。拥有单独的解决方案还意味着首先编译我想测试的插件解决方案，然后编译并运行“核心”应用程序解决方案。虽然它只是一些额外的鼠标点击，是否有（再次）任何VS功能，可以帮助这里？
我看到两种方法来做到这一点。
更舒适的选择：
1.您可以添加外部解决方案的核心解决方案。
Walkthrough: Adding an existing Visual Studio solution to another solution
通过这样做，你可以组织你的解决方案，以引用代码，仍然保持每个插件溶液中分离在同一时间。
您只需引用您当前想要使用的核心解决方案中的插件解决方案即可。此外，使用这种方法，您可以组织其他解决方案，就像使用普通项目一样，并将虚拟解决方案文件夹之间的文件夹移动到您喜欢的位置，直到您拥有最充足的文件夹结构。从文章
报价：
这种方法的好处是，不仅目前均为 项目的一个解决方案，但在任何时候，你可以在不影响打开 单独的解决方案“主“解决方案和副 。
参考文献解决方案中的文件可以像“常规”项目中的任何其他文件一样打开和编辑，当然，您也可以像设置其他代码文件一样设置断点。
通过这种方式，您可以同时编辑代码和一步到位，我个人发现比切换和附加到多个进程更方便。
2.添加PDB文件。
将您想要调试的插件的相应PDB放入一个文件夹中，并配置您的核心应用程序使用该文件夹作为DirectoryCatalog。这使您可以进入插件代码，但是您将无法编辑它们。
这是一种常见的情况，根本不棘手。
在插件的项目属性中，转到Debug -> Start Action并将Start external program设置为核心应用程序的可执行文件。
这样，你只需要编译你的核心应用程序一次（可能使用一个构建脚本，仅仅建立一切），并在插件调试将开始与连接调试器的核心应用程序，你可以调试插件（只要核心应用程序加载插件程序集）。
记住也请您可以从dettach运行的应用程序的调试器，切换到Visual Studio中的另一个解决方案开辟的另一个实例，再连接到运行的应用程序。例如，如果你喜欢，这很方便。调试您的插件，并希望在您的核心应用程序中设置或使用现有的断点。
只要Visual Studio能够找到调试符号（* .pdb文件），就可以遍历代码。调试插件时，您的核心应用程序也不成问题。
@Andrew 关于调试，只要您将程序集中的.pdb文件放在您用作DirectoryCatalog的目录中，就不应该成为问题。
关于核心 - 前建筑插件解决方案，你必须为每个解决方案1个build文件，你应该检查，如果你能在.bat文件中写的MSBuild命令来让它执行另一个之后。
除了上述所有建议之外，另一种调试方法是将您的插件解决方案附加到正在运行的核心进程。 Attach to Running Processes with the Visual Studio Debugger
您的方法（选项1）似乎更适合我将如何开发应用程序。虽然我可以看到@Dominic Kexel的方法在某些场景中很有用，但我已经接受了您的答案！ –