二、 可以独立处理“杂项文件”文件夹中的文件，而不需要特定项目参与。

杂项文件通常位于解决方案和开发项目的外部，与其相对独立。在实际工作中，程序开发人员可以使用“空白解决方案模板”来管理这些杂项文件，如打开阅读，甚至进行修改。也就是说，这个方案可以独立处理“杂项文件”文件夹中的文件，而不需要特定项目参与。通常情况下，利用独立的容器打开杂项文件显得非常的重要。如有时候开发人员往往喜欢将对那些项目或者解决方案必不可少的文件放在项目的内部。而将那些并非必不可少的文件当作“杂项文件”来处理，即存放在项目与解决方案的外部。这会提供应用程序的灵活性，降低其复杂的程度，从而有利于后续的维护与升级。如一些程序的通用示例、开发说明、数据库架构就往往都当作杂项文件来处理。“杂项文件”往往都存放在一个叫做“杂项文件夹”中，这也是为了集中管理的需要。跟普通程序文件不同的是，杂项文件夹中的杂项文件只表示为一个连接，就好象文件的快捷方式，不属于解决方案的一部分。

这些杂项文件虽然同项目具有一一对应的关系。但是在维护这些文件的时候，如开发人员需要查看某个项目的开发说明或者数据库架构，他们往往喜欢在不打开项目或者解决方案的时候，就可以对其进行维护与修改。如果查看这些文件，还需要先打开解决方案或者项目才能够进行维护操作，那显然太麻烦了。

所以为了能够更加独立与灵活的管理这些杂项文件，笔者推荐使用“空白解决方案模板”。因为采用这个解决方案，开发人员可以独立处理“杂项文件”文件夹中的文件，而不需要特定项目参与。当然，当打开某个解决方案的时候，跟这个解决方案相关的所有杂项文件(上次关闭解决方案时打开的部分或者全部杂项文件)也会重新打开。也就是说，杂项文件与普通的文件项目，有两种管理方式。可以从外部的独立容器和解决方案内部对其进行维护。两者基本上是等价的。这就是笔者推荐使用这个“空白解决方案模板”的第二个理由。

三、 可以独立的处理“解决方案项”文件夹中的项，而不需要特定项目参与。

在Visual Studio的解决方案资源管理器中有一个叫做“解决方案项”的文件夹。在这个文件夹中的项跟普通的项有所不同。普通的项往往位于解决方案内部。而位于着文件夹中的项往往都是独立于项目之外进行管理的，同时又与解决方案有所关联。在这个文件夹中的项就叫做“解决方案项”。其实它的作用跟上面讲到的“杂项文件”非常的类似。

如果将这些“解决方案项”加入到“空白解决方案模板”中，可以实现如下几个功能：

一是可以独立的阅读、修改这些项目，而不需要打开特定的解决方案。如现在有一个OA系统的开发项目，需要用到一个与微软邮件系统进行交互的一个子程序。通常情况下，就可以将这个子程序当作一个“解决方案项”来处理。开发人员可以在独立与OA项目外部对这个项目进行开发。而可以将其交给其他的人员来完成，而自己只需要提供标准的接口就可以了。此时程序开发人员就可以保证OA系统项目文件的独立性。因为不需要将这些内部的项目文件对外开发，其他人也可以修改这些“解决方案项”。

二是解决方案文件夹中的项可以在解决方案中编译和生成。虽然解决方案项独立与特定的解决方案，但是其毕竟是解决方案中一个必不可少的功能。如上面笔者举的一个与邮件系统交互的例子就是如此。为此最终的编译与生成需要在解决方案中完成。如此的话，他们才能够浑然一体。不过在实际工作中，在测试的时候往往需要跟解决方案脱离。不然的话，测试之前需要先对整个解决方案进行编译，显然太浪费时间。而在“空白解决方案模板”中可以对“解决方案项”进行独立的编译以及测试。测试没有问题的时候，在交付，然后在解决方案中进行最终的编译生成工作。

如果没有“空白解决方案模板”的帮助，这些功能将变得难以实现，或者说实现起来比较困难。而有了这个模板，对于解决方案项的管理将相对来说变的简单。

总之，空白解决方案项对于管理单个解决方案多个项目、杂项文件、解决方案项等等提供了简便、独立的管理平台。在这个模板的帮助下，可以在很大程度上降低程序开发人员的工作量，缩短项目开发的周期。