标签: projects-and-solutions

我看到开发人员经常针对包含系统中所有项目(27)的解决方案进行开发.这引发了构建持续时间(5分钟),Visual Studio性能(例如智能感知延迟)的问题,而且它不会强迫开发人员考虑项目依赖性(直到他们得到循环引用问题).

将这样的解决方案分解为可编译和可测试的独立于"母"解决方案的小型解决方案是一个好主意吗？这种方法有任何潜在的缺陷吗？

我有点不知道如何处理我的开发环境.任何时候我打开一个解决方案Visual Studio会提示我安装"带有Razor语法1.0的ASP.NET网页".

如果我忽略提示并继续进入解决方案,那么看起来不起作用的唯一事情就是剃刀视图中的智能感知.不是世界末日,但是当从解决方案转向解决方案时,会出现此消息,这已经开始变得烦人.

我试过了:

• 通过Web平台安装程序安装缺少的组件
• 通过独立安装程序安装缺少的组件
• 卸载并重新安装MVC3

关于我接下来可以尝试什么的任何建议？

编辑:

因此,卸载了与visual studio和visual studio sp1相关的所有工具后,我重新安装了visual studio和service pack1.我去安装MVC3并且安装失败了.

从那里,我清除了我机器上的每个临时文件/目录,并尝试了网络平台安装程序.再一次,它失败了.

从那里,我尝试安装MVC3的RTM并且安装成功:http://www.microsoft.com/download/en/details.aspx？id = 4211

在最终安装了MVC3后,我能够安装工具更新,并且我已经备份并运行....浪费4小时的好方法......等等......

现在Visual Studio 2015 RC已经出来了,有没有人安装它并打开Visual Studio 2013项目/解决方案？

• 它是否要求更改文件？
• 如果是,那么它向后兼容的变化是什么？

注意:这适用于在C++,C++/CLI和C#中工作的商店,其中一些产品是作为三者的组合交付的.

我们目前有一条规则,即项目应该只有一个包含解决方案.该规则最初是因为Visual Studio的源代码控制插件无法处理多个解决方案中包含的项目,因此在从一个解决方案更改为另一个解决方案时总是尝试更改源代码控制绑定.

出于其他原因,我们将完全停止使用源代码控制插件(不会丢弃源代码控制,只是停止使用脑干插件).它重新提出了是否继续限制只包含一个解决方案的项目的政策的问题.

我们在多个可交付产品所使用的库,dll和程序集中有相当多的代码,我们目前通过一个解决方案间依赖关系管理系统来控制它,如果一个人在最终产品的解决方案中工作,请求构建依赖项解决方案是一件简单的事情,它将启动Visual Studio的其他实例来构建它们.该系统有效,但有以下缺点:

• 常见项目的解决方案通常太胖,包含当前开发的产品所需的一些项目,并且通常还有许多不需要用于手头开发工作的项目.它们只是被归结为一种全面的解决方案,涵盖了仅与松散相关的项目.由于编译了不需要的代码,因此导致构建时间延长.
• 在我们试图解决上述胖解决方案的地方,我们常常只留下一个只包含一个项目的太瘦的解决方案.这些中的每一个都需要在解决方案间依赖性管理系统中的附加配置.随着Visual Studio的多个实例的旋转,这也会增加构建时间.

我正在考虑修改政策,允许多个可交付产品中使用的项目包含在多个解决方案中.我们可以消除解决方案间依赖关系管理并严重减少解决方案的数量(每个产品减少一个).我担心这次重组将需要做多少工作以及是否值得付出努力.在团队使用它一段时间之前,我恐怕甚至无法发现潜在的好处.我还预见到一些潜在的问题,这些都是真正的问题.

• 单个解决方案中的大量项目是否会在Visual Studio 2005(我们当前的开发平台)中出现任何稳定性问题？在VS 2008或VS 2010中它会变得更好吗？
• 如果项目包含在多个解决方案中,如何修改项目配置(例如添加新配置),如何管理多个解决方案的效果？

对于已经在每个可交付产品中使用一个解决方案的环境中工作的任何人,将通用组件作为多个解决方案中包含的项目:您是否遇到过此类配置的任何重大缺陷？

我有一个VC2010 C#解决方案,里面有很多项目.

例如,我有一个Web项目,我有一个类库.

在web.config文件中,我在该<appSettings>部分中有一个键,例如

<add key="FileDirectory" value="G:\ftproot\sales" />

我还在Web.Production.config文件中添加了一个键,以反映服务器上的文件目录.

所以当我在我的web项目中引用它时(它是MVC) - 我这样做:

var FTPPath = ConfigurationManager.AppSettings["FileDirectory"];

这在我的web项目中工作正常.但是,我还需要在类库中引用它,这就是我的问题 - 有没有办法在同一个解决方案中从另一个项目(例如类库)引用web.config文件中的键？

所有帮助表示赞赏.谢谢

有没有办法使用用户宏/环境变量在解决方案中定义项目文件路径？我似乎无法做到这一点.

有点像环境变量用于在C++项目中定义附加的包含目录,除了我想对解决方案中项目文件的位置做同样的事情.

我已经尝试在文本编辑器中编辑解决方案以更改以%MyMacroName%或$(MyMacroName)开头的路径,但它们似乎都没有解析得恰到好处.打开解决方案时无法找到项目文件.

正如本 SO答案所指出的,默认情况下,Visual Studio中的" 添加">"现有项目"对话框显示" 添加"按钮(意味着所选项目将物理复制到新位置),而理想的操作通常(始终是？)到添加为链接.

是否可以配置Visual Studio,以便在打开" 添加">"现有"项目对话框时默认选择" 添加为链接"？

我已经彻底搜索了Visual Studio中的" 选项"对话框,并检查了MSDN文档以获得答案,但到目前为止无济于事.

当两个新项目共享相同的代码库时,Project Linker将是自动链接的一个很好的选择.然而,从现有到新的项目连接大量文件时,一个似乎被限制在添加>现有项目的做法,这项工作可能会更加方便,不易出错,如果添加的链接将是默认动作.

我有15个C#项目的解决方案,我正在尝试为它们建立一个高效的git存储库.我应该在该级别上创建存储库还是在解决方案下为每个项目创建存储库？

WebServices/
|- WebServices.sln
|- WebService1/
 `- WebService1.csproj
|- WebService2/
 `- WebService2.csproj

该解决方案有一个项目引用,../framework/framework.csproj它是一个单独的存储库,所有其他项目都有引用.解决方案下的项目没有任何关联,但它们都使用框架.

我希望框架的任何更改都会传递给项目.

你有什么指导我如何以最好的方式实现这一目标吗？

将eclipse项目导入Android Studio并将其保存在新文件夹中.将包名称和所有内容更改为新名称,但项目名称仍然是旧项目中的名称.

如何将尖头名称更改为其他名称？

脚本

我有一个包含项目A,B和C的库.

我有两个解决方案.解决方案1包括项目A的副本,解决方案2包括项目A和项目B的副本.

当我构建解决方案1时,这是应该发生的事情:

替代文字http://img689.imageshack.us/img689/9341/onbuildsolution1.jpg

当我构建解决方案2时,这是应该发生的事情:

alt text http://img32.imageshack.us/img32/7821/onbuildsolution2.jpg

我怎样才能做到这一点？

这是我可以使用版本控制系统或现成的文件同步软件自动化的东西吗？或者我需要推出自己的解决方案吗？

如果我构建自己的解决方案,我会对它如何工作有一些想法,但我很感激您的任何输入:

• 可以是一个简单的控制台应用程序,带有用于指定"源解决方案"的命令行开关,例如:

  c:\Program Files\Library Syncronizer\LibSync.exe /solution:Solution 1
  

  Run Code Online (Sandbox Code Playgroud)

• 用于注册包含库项目的活动解决方案的XML文件.可能的格式:

  <solutions>
    <solution>
      <name>Solution1</name>
      <path>c:\...\Projects\Solution 1</path>
    </solution>
    <solution>
      <name>Solution2</name>
      <path>c:\...\Projects\Solution 2</path>
    </solution>
    <!-- more solutions -->
  </solutions>
  

  Run Code Online (Sandbox Code Playgroud)

• 计划将执行以下操作:

  • 读入源解决方案
  • 确定它具有哪些库项目
  • 将这些项目的文件夹复制到库中
  • 循环遍历XML文件中的每个解决方案(源代码除外)
  • 根据需要复制所有库项目的文件夹
  • 也许某些备份操作也可能发生,以防同步过程覆盖重要的事情.

这在概念上听起来相对简单,但这可能会产生严重意想不到的后果,我没有想到.希望有人会警告我,如果它:)

更新 - 我复制项目文件夹的动机是什么？

总之 - 版本控制.

如果我将库项目保存在一个单独的文件夹中,并且只在我的各种解决方案中链接到它们(而不是在我的解决方案文件夹中物理定位文件夹),我的版本控制存储库最终不包含我的库项目的源代码.所以,如果我更新到"三个版本之前",并且我需要对我的一个库方法进行微小的更改,那么代码就不存在了.

我的解决方法是在我的库的存储库中添加标签,例如"解决方案1 ​​ - 版本2.5.3",但这非常笨重.如果我正在处理解决方案1的"三个版本之前"和解决方案2的当前版本,事情变得非常尴尬.现在,解决方案2将指向旧版本的库项目,这使得它可能无法实现使用和测试,直到我完成旧版本的解决方案1.

如果我正在使用副本,所有解决方案都会在其存储库中包含库源代码,并且我可以在需要时随时轻松地返回它.

我应该注意到,我一直在使用Tortoise HG(Mercurial)进行版本控制.

无论如何,我愿意解决这个问题.它不必涉及复制项目文件夹 - 这是我唯一能想到的,以确保我的所有版本控制存储库都是完整的独立软件包.

更新2

首先,只是一个注释.我使用Mercurial(TortoiseHG)进行版本控制,而不是SVN.如果绝对必要,我可以改变,但我真的更喜欢Mercurial.

根据目前为止的回复,我决定废除"双向复制"的想法,然后回到引用我的图书馆项目.这是一个新图:

alt text http://img30.imageshack.us/img30/7445/referencedprojects.jpg

然而,我仍然有相同的目标:

1. 每个解决方案的最新版本都使用最新的库代码
2. 每个存储库一个解决方案/应用
3. 每个存储库都包含所有源代码,包括库项目
4. 一切都尽可能自动化,以尽量减少错误的风险

目标#1通过引用库项目而不是使用副本自动处理,目标#2只是我如何设置我的存储库的问题,但目标#3和#4仍然是难以捉摸的.

对于Mercurial,有一个子库存功能似乎可以处理我的情况,但正如文档所示,这仍然被认为是实验/风险.

目前,我认为一个好的解决方法可能是将库项目的 …