To paraphrase this rather long question:
用这个相当长的问题来解释：
Why would you need more than 2 build configurations for their project when used in conjunction with service configurations ?
当与服务配置结合使用时，为什么他们的项目需要超过2个构建配置？
I have a cloud service that contains multiple websites which needs to be deployed onto a number of different Azure platforms, one for Test, one for UAT, and one for Live.
我有一个云服务，其中包含多个网站，需要部署到许多不同的Azure平台上，一个用于测试，一个用于UAT，一个用于Live。
Each environment needs a different host header defined for the website it deploys e.g. test.myportal.com, test.myservice.com, uat.myportal.com, uat.myservice.com, live.myportal.com and live.myservice.com.
每个环境都需要为其部署的网站定义不同的主机头，例如test.myportal.com，test.myservice.com，uat.myportal.com，uat.myservice.com，live.myportal.com和live.myservice.com。
This means I need to define a ServiceDefinition for each environment, fine so far.
这意味着我需要为每个环境定义一个ServiceDefinition，到目前为止很好。
In previous related questions I've seen (Azure: Is there any way to deploy different instance sizes for test/production, Azure connection string best practices (step 4, and using $(Configuration) instead of $(TargetProfile) in the .ccproj file), people have mentioned that you will need X configurations (meaning build configurations). This doesn't make sense to me, as I only need two build configurations (Debug and Release) for the way that the code is built, rather than how the service is configured. Rather, what I need are three service configurations.
在我之前看到的相关问题中（Azure：有没有办法为测试/生产部署不同的实例大小，Azure连接字符串最佳实践（步骤4，并在.ccproj中使用$（Configuration）而不是$（TargetProfile））文件），人们已经提到你需要X配置（意思是构建配置）。这对我来说没有意义，因为我只需要两个构建配置（Debug和Release）来构建代码的方式，而不是如何配置服务。相反，我需要的是三种服务配置。
My question is, am I right in thinking that a build configuration should only be used for how the code is built and that people who create multiple different build configurations for service configuration are wrong? (That's not the best word to use, I admit)
我的问题是，我是否认为构建配置应仅用于构建代码的方式以及为服务配置创建多个不同构建配置的人是错误的？ （我承认，这不是最好用的词）
To further explain how I'm implementing a solution around this, I continue below:
为了进一步解释我是如何围绕这个实现解决方案，我继续下面：
I'm configuring my CI build server for MSBuild to take an additional parameter, TargetProfile, alongside Configuration.
我正在为MSBuild配置我的CI构建服务器以获取额外的参数TargetProfile和Configuration。
The MSBuild commands for my environments look like this:
我的环境的MSBuild命令如下所示：
For Test:
对于测试：
msbuild mySolution.sln /p:TargetProfile=Test /p:Configuration=Debug
For UAT
对于UAT
msbuild mySolution.sln /p:TargetProfile=UAT /p:Configuration=Debug
For Live
为了生活
msbuild mySolution.sln /p:TargetProfile=Live /p:Configuration=Release
For my cloud service, I use three ServiceDefinition.csdef files, one for each environment: ServiceDefinition.Test.csdef ServiceDefinition.UAT.csdef ServiceDefinition.Live.csdef. These are kept in a '/config/' folder.
对于我的云服务，我使用三个ServiceDefinition.csdef文件，每个环境对应一个文件：ServiceDefinition.Test.csdef ServiceDefinition.UAT.csdef ServiceDefinition.Live.csdef。这些保存在'/ config /'文件夹中。
In my cloud server ccproj file I only have two Configurations, Debug and Release, with a task in BeforeBuild :
在我的云服务器ccproj文件中，我只有两个配置，调试和发布，在BeforeBuild中有一个任务：
<Target Name="BeforeBuild">
<Copy SourceFiles="configs\ServiceDefinition.$(TargetProfile).csdef" DestinationFolder="$(OutputPath)" />
<Move SourceFiles="$(OutputPath)ServiceDefinition.$(TargetProfile).csdef" DestinationFiles="$(OutputPath)ServiceDefinition.csdef" />
</Target>
This then ensures that I only ever need two build configurations, but can have as many service configurations as I like, just by changing the TargetProfile parameter that I pass into MSBuild.
这样就确保我只需要两个构建配置，但只需更改我传递给MSBuild的TargetProfile参数就可以拥有尽可能多的服务配置。
To reprise my question:
重新提出我的问题：
Am I right in thinking that a build configuration should only be used for how the code is built, and that people who create multiple different build configurations for service configuration are wrong ?
我是否正确地认为构建配置应仅用于构建代码的方式，以及为服务配置创建多个不同构建配置的人员是错误的？
1 个解决方案
#1
0
One possible use case of different build configurations might be when a service needs to be deployed to multiple product platforms for different customers with different feature sets. In such a scenario, it might make sense for the build process to customize the individual feature sets (e.g. via the use of C# Preprocessor Directives) for performance and security reasons.
不同构建配置的一个可能用例可能是当需要将服务部署到具有不同功能集的不同客户的多个产品平台时。在这种情况下，出于性能和安全原因，构建过程可能有意义地定制各个功能集（例如，通过使用C＃预处理器指令）。
#1
0
One possible use case of different build configurations might be when a service needs to be deployed to multiple product platforms for different customers with different feature sets. In such a scenario, it might make sense for the build process to customize the individual feature sets (e.g. via the use of C# Preprocessor Directives) for performance and security reasons.
不同构建配置的一个可能用例可能是当需要将服务部署到具有不同功能集的不同客户的多个产品平台时。在这种情况下，出于性能和安全原因，构建过程可能有意义地定制各个功能集（例如，通过使用C＃预处理器指令）。