标签: solution

我有一些工具可以在.NET解决方案上执行更新,但是他们需要知道解决方案所在的目录.

我将这些工具添加为外部工具,它们出现在IDE工具菜单中,并$(SolutionDir)作为参数提供.这很好用.

但是,我希望通过自定义顶级菜单(我为其创建Visual Studio集成包项目)以及通过解决方案节点上的上下文菜单(我为其创建了一个Visual),在IDE中为用户更轻松地访问这些工具. Studio加载项目).我正在寻找一种方法来通过这些上下文获取当前的解决方案目录.

我尝试从VisualStudio.DTE对象获取解决方案信息:

EnvDTE.DTE dte = (EnvDTE.DTE)System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE");
string solutionDir = System.IO.Path.GetDirectoryName(dte.Solution.FullName);

但是,这将返回add ins的解决方案目录,而不是当前解决方案.

我试着回应$(SolutionDir)并回读它:

System.Diagnostics.ProcessStartInfo procStartInfo = new System.Diagnostics.ProcessStartInfo("cmd", "echo $(SolutionDir)");

// The following commands are needed to redirect the standard output.
// This means that it will be redirected to the Process.StandardOutput StreamReader.
procStartInfo.RedirectStandardOutput = true;
procStartInfo.UseShellExecute = false;
// Do not create the black window.
procStartInfo.CreateNoWindow = true;
// Now we create a process, assign its ProcessStartInfo and start …

我有一个脚本,为visual studio 2005生成一个.sln文件和几个.vcproj文件.我需要设置WorkingDirectory选项,但它在.user文件中指定.我们目前无法生成的文件.我在msdn 找到了vcproj文件定义,但似乎这个选项不能从那里设置.

如何从.sln或.vcproj文件中指定"配置属性 - >调试 - >工作目录"？

我想知道基于MVC5的企业级架构的最佳实践是什么.我的意思是在一个解决方案中选择多层或多个项目？或者可能不止一个解决方案？任何好的示例项目？

我正在使用多台机器来分析和运行一个解决方案,通过DropBox完成数据同步(辉煌,顺便说一句!).不幸的是,一台机器的更改会导致所有其他机器的VS实例问我是否要重新加载哪个......很烦人,因为答案总是肯定的.

所以我的问题是:我可以让VS认为答案总是是的吗？

在我的解决方案中,我有一个名称为粗体的项目.

为什么ErrorHandlerLibrary大胆？

在.NET中,您应该将单元测试项目与其余解决方案放在一起吗？或者是否应该有一个包含所有测试项目的测试解决方案？

我们的代码库解决方案中包含所有测试项目......看起来有点麻烦.

你平常都做什么？

首先,让我们同意命名空间应该匹配文件夹结构,并且每个语言工件应该在它自己的文件中.

(请参阅解决方案中的文件夹是否应与命名空间匹配？).

接下来的问题是如何在磁盘上实际组织文件夹.
假设我在ABC命名空间中有ClassC,在ABCD命名空间中有ClassD.
我们还假设每个命名空间都构建在它自己的程序集(项目)中,并且命名空间根据公认的最佳实践从右到左依赖(ABCD可以依赖于ABC,它可以依赖于AB,它可以依赖于A).我感谢每个命名空间不必在一个单独的程序集中,但在一般情况下,我们将在单独的程序集中有一些命名空间,我的例子说明了这一点.

我可以看到(至少)两种创建文件夹树的方法 - 我称之为"嵌套文件夹"和"平面文件夹":

1 - 嵌套文件夹:

甲
--A.csproj
--B
---- ABcsproj
----Ç
------ ABCcsproj
------ classC.cs
------ d
-------- ABCDcsproj
-------- classD.cs

要么

2 - 扁平文件夹:

A
--A.csproj
AB
--ABcsproj
ABC
--ABCcsproj
--classC.cs
ABCD
--ABCDcsproj
--classD.cs

你会看到我已经做了一些假设:

• 每个项目文件都具有基于命名空间的完全限定名称(FQN).
• 每个类文件都使用非FQN

嵌套文件夹似乎更自然(我们都喜欢层次结构),但在大型解决方案中导航可能有点困难:

当您在VS中查看解决方案时,它会显示项目的平面列表,而不是嵌套视图.这看起来更像是"平面文件夹",因此在磁盘上组织文件夹以匹配VS中的视图可能是有好处的.

如果查看磁盘上的每个文件夹,您将看到该项目的文件夹文件加上命名空间的子文件夹:以C为例:

ç
--bin
--D
--obj
--properties
--ABCcsproj
--classC.cs

根据D的真实名称,D可能并不明显是命名空间文件夹而不是C命名空间中的组织文件夹.

我知道我们在.NET(8或9年前)和Java之前的第一天就有文件夹和命名空间,但是,就个人而言,我们似乎没有就大型的最佳实践项目组织达成共识解决方案.我真的很想知道你们都在想什么.

谢谢
迈克尔

给定 Visual Studio 中打开的解决方案，如何快速检查解决方案中的各个项目具有哪些目标框架？是否有一个解决方案范围的视图显示每个项目针对哪个目标框架，或者有多少项目针对每个框架版本的聚合视图？

我知道我可以单独检查每个项目（在属性窗口或文件csproj本身上），但是在具有 100 多个项目的解决方案中这是不可行的。

此外，我知道我可能可以csproj在根文件夹中的文件内进行某种正则表达式搜索，但我想知道 Visual Studio 中是否有内置的东西可以提供此数据。