问题标签 [projects-and-solutions]

Pretty much what the title says. Is there a way to add files to a vsnet project from inside Vim? I work in a group of devs, and all of our code has solutions and projects as you would expect. I would like to use Vim, and was hoping for a way to maintain those project files when I added or removed files without having to go into vsnet.

首先，我知道这一点：您将如何为内部软件项目组织 Subversion 存储库？ 接下来是实际问题：我的团队正在重组我们的存储库，我正在寻找有关如何组织它的提示。（在这种情况下为 SVN）。这就是我们想出的。我们有一个存储库、多个项目和多个 svn:externals 交叉引用

明确词汇：解决方案意味着单个产品，项目是一个 Visual Studio 项目（导致单个 .dll 或单个 .exe）

这就是我们计划布局存储库的方式。主要问题是，我们有多个解决方案，但我们希望在解决方案之间共享项目。我们认为将这些共享项目转移到他们自己的解决方案中没有任何意义，因此我们决定使用 svn:externals 在解决方案之间共享项目。我们还希望将通用工具集和第 3 方库保存在存储库中的一个位置，并在每个解决方案中使用 svn:externals 引用它们。

你觉得这个布局怎么样？尤其是关于 svn:externals 的使用。这不是一个理想的解决方案，但考虑到所有利弊，这是我们能想到的最好的解决方案。你会怎么做？

在查看与在 VS 2005 和 VS 2008 之间共享解决方案相关的其他问题之后，似乎要走的路是拥有两个解决方案文件（一个用于 VS 2005，一个用于 VS 2008）。

但是，如果解决方案受源代码控制（在我们的例子中是 VisualSVN），我们将如何维护两个解决方案文件而不是在每次更新/提交时不断覆盖一个或另一个？

是否可以仅从源代码管理中删除 .sln 文件并阻止 VisualSVN 客户端检查其在 Visual Studio 中的状态？

谢谢

马特

对于某些解决方案，当我打开它们时，Visual Studio 将获取不在项目中的文件（特别是来自 obj/Debug）并将其添加到变更集中，我总是必须对它们执行Undo Pending Changes操作。它很烦人。有没有办法阻止 Visual Studio 以这种方式运行？

我有一个包含以下项目的视觉工作室解决方案：

1. 用户界面
2. 数据访问
3. 业务逻辑
4. 业务对象

我现在有一堆代码可以生成通过电子邮件发送或保存为 csv 文件的报告。

这些 ReportGenerators 类接收业务对象并输出文件或字符串。

你会把它们放在哪个项目中？我倾向于答案，但想看看其他人的想法？

我有一个 winforms 项目，我们使用命令模式。我们正在尝试清理我们的目录结构并使其保持一致。

我们正在尝试决定是否应该有一个根命令文件夹。你认为什么更适合目录结构？

项目
--Commands
----AddCommand
----SubtractCommand
----InsertCommand
----DeleteCommand

或者

项目
--Calculation
----AddCommand
----SubtractCommand
--Database
----InsertCommand
----DeleteCommand

好的，所以我一直在尝试将每个人的课程之一放在某个根文件夹中，或者：

UI
BusinessLogic
DataAccess
BusinessObjects
接口

我还有一些我似乎不太好斗的地方，所以我正在寻找建议

1. 一个 Cache 类，它维护一个私有字典并允许基于某些特定键对对象进行不同的访问

2. 事件 Arg 类？

此外，在一个项目下，我现在开始拥有拥有全部 3 个（数据访问、业务对象、业务逻辑）的子系统。我应该如何分解文件夹结构？

一种。

ProjectX
--Subsystem1
----BusinessObjects
----DataAccess
----BusinessObjects
--Subsystem2
----BusinessObjects
----DataAccess
----BusinessObjects

或者

ProjectX
--BusienssLogic
----Subsystem1BL
----Subsystem2BL
--DataAccess
----Subsystem1DA
---- Subsystem2DA
--BusinessObjects ----
Subsystem1BO
----Subsystem2BO

或者

ProjectX
--BusinessLogic
--DataAccess --BusinessObjects
（
每个功能子系统没有子目录）

有没有办法禁用解决方案资源管理器的拖放功能？你为什么要问？我使用 wacom 数位板已经有好几年了，我很喜欢它。但是，当您在解决方案资源管理器中将它与 TFS 或 AnkhSvn 等源代码控制结合使用时，当您不小心将文件移动到不同的目录时，这将是一场灾难。

我目前将 Visual Studio 设置为在要签出文件时提示，但是当已经签出解决方案/项目文件时，上述问题仍然存在。

我们公司 (xyz) 正在将我们的大量 Flash 代码迁移到 Python。

在 Flash 中，我们的 Flash 应用程序之间有一个共享库 - 包 xyz。我们可以对包进行更改，而不必担心在部署其他应用程序时会破坏它们，因为 Flash 会编译它们的代码并包含库的内容。我们通过 RPM 部署最终的 SWF，我们就完成了。App1 和 App2 的更新永远不会破坏 App3。

您将如何在共享库依赖项 Python 中处理此问题。

App1、App2 和 App3 都可能需要 xyz-lib.rpm，并且都使用相同的库文件，但是每次有新库时，都必须针对 App1、2、3 显式测试更新的 xyz-lib.rpm ，这只是繁重的。

我目前最喜欢的解决方案——我可以让 app1.rpm 包含打包时的库——实际上是库的某种静态链接。然而，这感觉很不雅。（虽然唯一的额外成本是硬盘空间==便宜。）

我知道共享库的可靠管理可能是最好的解决方案，但我一直在努力考虑到所有开发人员都是人类，并且会犯错误。我们会犯错误，我不希望 app1 的部署破坏 app2 和 app3 - 它只是要测试和调试更多。

默认情况下，Ctrl-Shift-B 构建一个完整的解决方案。一个完整的解决方案可能包含许多项目。同时编译可能会很慢，尤其是当开发只发生在一个项目上时。

我尝试将 Ctrl-Shift-B 重新映射到 Build.BuildOnlyProject，但它不起作用。没发生什么事。

从菜单中，以下选项完全符合我的要求：