More on the build configuration automation model

I already wrote about the convoluted build configuration automation model and provided a visual representation of it to help understanding it. One of the problems that I explained is that the configurations of solutions are modeled as a collection rather than as a 2-D matrix (configuration names and platforms), as it happens with project configurations, which are modeled correctly. While this problem wouldn’t be as bad once you understand it, it gets worse when you want to do some natural things such as manipulating solution platforms and it has been raised in this post of the MSDN Forum about Visual Studio Extensibility:

  • When you delete an EnvDTE.SolutionConfiguration from the DTE.Solution.SolutionBuild.SolutionConfigurations, you get actually more than one solution configuration deleted. This must be the first case in computing when deleting an item of a collection, it actually deletes more than one… You can test it with this macro and a solution with two configuration names (“Debug” and “Release”) and two platform names (“Any CPU” and “Itanium”, for example):
Sub Configs()

   For Each objConfiguration2 As EnvDTE80.SolutionConfiguration2 In DTE.Solution.SolutionBuild.SolutionConfigurations

      MsgBox(objConfiguration2.Name & "/" & objConfiguration2.PlatformName)

   Next

   DTE.Solution.SolutionBuild.SolutionConfigurations.Item(1).Delete()

   For Each objConfiguration2 As EnvDTE80.SolutionConfiguration2 In DTE.Solution.SolutionBuild.SolutionConfigurations

      MsgBox(objConfiguration2.Name & "/" & objConfiguration2.PlatformName)

   Next

End Sub

You get four configurations initially and only two after deleting one. This is so because deleting a solution configuration from the collection actually deletes all the ones with the same configuration name, regardless the platform!!!. Of course, it doesn’t make sense to delete an item from a 2-D matrix, it only makes sense to delete items in the axis (configuration names or platform names).

  • But it gets worse: you can’t delete solution configurations by platform name because of the previous behavior. Maybe the SDK was the solution, so I checked the Visual Studio 2008 SDK in the MSDN site, and it states that: “There are no VSIP interfaces to create solution configurations programmatically. There are no VSIP APIs for editing the solution configurations. You must use DTE.SolutionBuilder. For more information, see Automation Model. However, there are VSIP APIs for managing the solution build. For more information, see IVsSolutionBuildManager2.”. So, if you can’t create solution configurations names or platforms programmatically using the SDK, you can’t delete them too, I guess. You are pointed to the DTE.SolutionBuilder, as if such thing exists in the automation model (it refers to the DTE.SolutionBuild) that, as we have seen, it doesn’t allow you to delete solution configuration platforms.

As I pointed in the original post, you can actually create solution configurations or platforms by creating project configurations and platforms and propagating them to the solution level (last parameter of EnvDTE.SolutionManager.AddConfigurationRow and EnvDTE.SolutionManager.AddPlatform). But there is no “propagation” when deleting them at project level, so I guess that there is actually no way to delete solution platform names. The closest thing that you can do with automation is to iterate the solution configurations to warn the user the platforms that are not allowed to make her to delete them by hand.

One thought on “More on the build configuration automation model”

  1. Thanks for the confirmation Carlos. I burned a bunch of time attempting to delete these platforms before resigning to warning the user that they should manually delete the platforms. Thanks again for all your work.

Comments are closed.