小编Stu*_*nge的帖子

我正在为我们所有的项目定义一个通用的构建模板 - 我已将其置于"根项目"级别(感谢TeamCity 8的这一新功能).我们的一些项目创建了一个安装程序,需要通过运行powershell脚本的单独"构建步骤"生成.但是,我们的一些项目不会创建此安装程序,因此不需要此额外的构建步骤.

有没有办法根据构建参数有条件地执行构建步骤？我想也许可以在这里利用"禁用构建步骤"功能,但我没有看到通过参数定义步骤的启用/禁用状态的方法.

当然,我可以将这个条件烘焙到执行安装程序生成的构建步骤中,但如果可以从teamcity本身内部处理它,那将更加清晰.

我想使用预提交挂钩,阻止开发人员在非根目录上设置svn:mergeinfo.也就是说,我想强制执行svn:mergeinfo 只能在"trunk"或"branches/branchName"这样的目录上设置.开发人员有时需要"提醒"使用根目录的子目录作为合并目标(根据此处列出的最佳实践)并不是一种好的做法.有没有人有这样的钩子脚本或知道我在哪里找到一个？我在Windows环境中,所以批处理或powershell会更好,但任何东西肯定会有所帮助.

问题

您的组织有许多单独的应用程序,其中一些应用程序相互交互(形成"系统").您需要将这些应用程序部署到单独的环境中,以便于分阶段测试(例如,DEV,QA,UAT,PROD).在每个环境中,给定的应用程序需要稍微不同地配置(例如,每个环境都有一个单独的数据库).您希望通过某种自动化机制来处理此重新配置,以便您的发布管理器不必在每次部署到不同环境时手动配置每个应用程序.

期望的功能

我想设计一个具有以下属性的组织范围的配置解决方案(理想情况下):

• 支持"一键"部署(仅需要指定环境,并且在部署期间/之后不需要手动重新配置).
• 应该有一个"记录系统",其中指定了共享的依赖于环境的属性(例如,许多应用程序共享的数据库连接字符串).
• 支持重新配置已部署的应用程序(在特定于环境的属性需要更改的情况下),理想情况下无需重新部署应用程序.
• 允许应用程序在同一台机器上运行,但在不同的环境中运行(同时运行PROD实例和DEV实例).

可能的解决方案

我看到了解决方案可以采用的两个基本方向:

1. 使所有应用程序"环境感知".您可以将命令行中的环境名称(DEV,QA等)传递给应用程序,然后该应用程序"足够智能",足以在运行时计算出特定于环境的配置值.该应用程序可以从应用程序部署的平面文件或中央配置服务中获取值.
2. 应用程序不是"智能",因为它们位于#1中,只是通过应用程序部署的配置文件中的属性名称获取配置.安装程序/脚本在部署时将这些属性的值注入配置文件中.该安装脚本采用环境名称并从中央配置服务获取所有相关配置值.

题

您如何实现解决这些问题并支持这些所需功能的配置解决方案？我是否有两种可能的解决方案？您对这些解决方案有偏好吗？另外,请随时告诉我,我正在考虑这个问题.任何反馈将不胜感激.

我想在C#中编写(或使用它,如果它已经退出)一个函数,它返回给定System.TimeZoneInfo对象的下一个DST转换的日期/时间以及该时区中特定的"截至"时间.返回的时间应该在提供的时区内.我想要的功能有这个签名:

public DateTime GetNextTransition(DateTime asOfTime, TimeZoneInfo timeZone)
{
    // Implement me!
}

例如,如果我传入"东部标准时间"TimeZoneInfo对象,以及1/21/2011 @ 17:00作为"asOfTime",我希望此函数返回2011年3月13日@ 2:00.

该System.TimeZoneInfo.TransitionTime结构似乎有我需要的所有信息,但理想会有某种内在的机制的规则转换为实际日期.有人有什么建议吗？

我有一些通过cruisecontrol.net运行的C++项目.作为构建过程的一部分,我们编译并运行Boost.Test单元测试套件.我将这些配置为转储XML日志文件.虽然格式类似于JUnit/NUnit,但它并不完全相同(并且缺少一些信息),所以cruisecontrol.net无法接收它们.我想知道是否有人创建(或知道)现有的XSL转换,它将Boost.Test结果转换为JUnit/NUnit格式,或者直接转换为可呈现的(html)格式.

谢谢!

我有一个msi(用WIX编写),它有一个绑定到自定义属性的复选框(称之为MY_PROPERTY).我想从命令行运行此msi,为此属性指定0(未选中)或1(已选中).我的脚本将确定适当的值(基于环境)并将该值注入msiexec命令行.我的命令行看起来像这样:

msiexec /i my_installer.msi MY_PROPERTY=$value

其中$ value为1或0,具体取决于环境.问题是,无论我在命令行为MY_PROPERTY提供什么值,都会选中复选框(并且该属性将始终设置为1).取消选中复选框的唯一方法是不指定属性(保留未定义).应该注意,无论UI是否显示,都会出现这种情况(在上面的命令行中添加"/ quiet"不会改变这种行为).

这个msdn帖子似乎表明这是Windows安装程序中已知的"错误"(或者更确切地说,无论创作系统编写的是msi).建议使用post-build msi hack作为解决方案.我想知道是否有人遇到过这个问题并提出了更好的解决方法/解决方案.谢谢!

更新

我看到这个问题的三个解决方案:

1. 从@Damien开始,让包装器脚本在其值为0时不将属性传递给msiexec.这会使脚本更复杂,并且可能会阻止我覆盖默认为"已检查"的复选框的值.
2. 从@Michael Urman添加一个自定义操作,如果其值为零,则清除该属性.这使得msi更复杂,我将不得不为UI中的每个复选框添加这样的自定义操作.
3. 另一个想法是简单地禁止在我们的msi安装程序中使用复选框,并使用单选框或下拉菜单代替"真/假"问题.虽然这限制了我们的安装程序的UI选项,但它允许包装器脚本保持简单,并且不需要自定义操作来"破解"属性.

我目前倾向于选项3,虽然选项1可能是我原来问题的最佳答案.有什么想法吗？

这已在MS Connect中交叉发布:

https://connect.microsoft.com/VisualStudio/feedback/details/560451

我试图通过msbuild构建包含C#Web应用程序项目的解决方案时覆盖属性$(MSBuildExtensionsPath).我这样做是因为Web应用程序csproj文件导入文件"$(MSBuildExtensionsPath)\ Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets".此文件由Visual Studio安装到标准$(MSBuildExtensionsPath)位置(C:\ Program Files\MSBuild).我想消除对机器上安装的这个文件的依赖(我希望尽可能保持我的构建服务器"干净").为了做到这一点,我想在我的项目的源代码管理中包含Microsoft.WebApplication.targets,然后覆盖$(MSBuildExtensionsPath),以便csproj将导入此包含的Microsoft.WebApplication.targets版本.

当我从命令行构建解决方案文件时,此方案正常工作,通过/ p标志在命令行将自定义值$(MSBuildExtensionsPath)提供给msbuild.但是,如果我尝试使用自定义msbuild项目文件中的MSBuild任务构建解决方案(使用"属性"属性覆盖MSBuildExtensionsPath),则会失败,因为Web应用程序csproj文件正在尝试从中导入Microsoft.WebApplication.targets "标准"Microsoft.WebApplication.targets位置(C:\ Program Files\MSBuild).值得注意的是,如果我使用自定义项目文件中的"Exec"任务运行msbuild,它就可以运行.更值得注意的是,第一次使用"MSBuild"任务运行构建后,我使用"EXEC"任务(或直接从命令行)运行构建,构建工作.

以前有人见过这样的行为吗？我疯了吗？是否有人知道此问题的根本原因,可能的解决方法,或者这是否是MSBuild中的合法错误？

重现步骤:

1)在MSVS 2008中创建一个新的空解决方案(Fake.sln)

2)向解决方案添加新的C#Web应用程序(WebApplication1.csproj)

3)关闭MSVS

4)将"C:\ Program Files\MSBuild \"的内容复制到包含解决方案的目录中名为"MSBuildExtensions"的目录中.

5)重命名目录"C:\ Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications",以便WebApplication1.csproj无法从该位置导入Microsoft.WebApplication.targets.

6)在与解决方案相同的目录中创建名为"TestBuild.proj"的自定义MSBuild项目文件.它应该具有以下内容:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="BuildMSBuild">

<PropertyGroup>
    <MSBuildExtensionsPath>$(MSBuildProjectDirectory)\MSBuildExtensions\</MSBuildExtensionsPath>
    <BuildThis>Fake.sln</BuildThis>
</PropertyGroup>

<Target Name="BuildMSBuild">
    <MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);" Targets="Clean" />
    <MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);"/>
</Target>

</Project>

7)从MSVS命令提示符执行"msbuild TestBuild.proj"(注意:构建可能会在第一次成功,但如果运行多次则会失败)

我注意到当使用XElement.CreateWriter创建编写器时,XmlWriter.WriteRaw似乎无法正常工作(它会转义xml字符).以下测试用例再现了该问题.我的用法不正确吗？有谁知道如何实现理想的行为？我需要能够将原始xml字符串写入XmlWriter并将该xml合并到XElement中.

[Test]
public void XElementWriterTest()
{
    var xelement = new XElement("test");
    using (var writer = xelement.CreateWriter())
    {
        writer.WriteRaw(@"<some raw='xml' />");
    }
    Assert.That(xelement.ToString(), Is.EqualTo(@"<test><some raw='xml' /></test>"));
    // actual : "<test>&lt;some raw='xml' /&gt;</test>"
}