You may be able to modify the web.config first, and replace all those values with parameters. When you import the config file into a BLPackage, all the parameters will be there already.
Thanks for the response Yoway. I understand what you're suggesting, but it's not quite answering my question.
So, for a BLPackage, I can parameterize all the items I'd like. For pushing that package, that's fine. But, this isn't giving me the full functionality I'm looking for. For instance, I'd like to audit my build machine's application component against the QA servers' application component. But, without parameterization, that audit will fail for web.config.
Ideally, we could define these entries in the Component Template. It would let us parameterize entries like it lets us parameterize paths in the parts view. Then, when I package from a component (or audit two components), it will "know" how to read each system's web.config.
Not sure if you found your answer yet; we're doing something similar, so I defined entries in the Configuration Object Dictionary that use Server Properties as part of the path. We're using the default XML file grammar (xml.gm) to parse the config files, which has some issues regarding repeated tags if the number or ordering changes. I will probably delve into writing a custom grammar at some point...
I started out using Component Templates with multiple instances per Server, but found that referencing Component properties is just not as easy as referencing Server properties (or even possible in some cases); we have an enhancement request out to be able to easily target Components using parameter syntax that will hoepfully resolve this issue,
I haven't actually tried it, but you could try wild-carding the web.config configuration file and see if BL catches them all...
Hope that helps,
Anyone make further progress on this? This may be coming past my desk soon...