This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- TFS and IS Standalone Build errors with "XML file changes"
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Feb 22, 2011
08:44 AM
TFS and IS Standalone Build errors with "XML file changes"
Hello all,
We have a Visual Studio 2010 C#.NET solution of which we are trying to setup automated builds on our TFS 2010 server with an InstallShield SAB installation. Our solution contains a "Basic MSI" installer project which defines a number of features including a service and a windows form features.
We have customized our dialogs to allow customized input values for the relevant ".config" files contained in both projects. Which means we needed to implement updates using the "XML file changes" view.
Of course compiling out project via the Visual Studio IDE works fine (as has been the case regarding multiple errors reported from TFS and InstallShield SAB). But I keep coming to dead-ends trying to resolve this one.
When I configured the XML file to update, I had to browse for the physical file, which of course for windows forms and services is the config file with the name that reflects the project executable. This creates an absolute path to either the bin\Debug or the bin\Release folder.
Of course TFS is not aware of these locations during an automated build and throws this kind of error for each file that needs to be updated:
C:\Program Files\MSBuild\InstallShield\2011\InstallShield.targets (68): -6103: Could not find file "d:\Builds\1\\Test Release\Sources\\bin\Release\.exe.config"
Of course it does make sense but how to fix it is the trouble. How can I define the "XML file changes" to look to the project primary output location instead of using an absolute path?
Does anyone have any other suggestions?
Stephen
We have a Visual Studio 2010 C#.NET solution of which we are trying to setup automated builds on our TFS 2010 server with an InstallShield SAB installation. Our solution contains a "Basic MSI" installer project which defines a number of features including a service and a windows form features.
We have customized our dialogs to allow customized input values for the relevant ".config" files contained in both projects. Which means we needed to implement updates using the "XML file changes" view.
Of course compiling out project via the Visual Studio IDE works fine (as has been the case regarding multiple errors reported from TFS and InstallShield SAB). But I keep coming to dead-ends trying to resolve this one.
When I configured the XML file to update, I had to browse for the physical file, which of course for windows forms and services is the config file with the name that reflects the project executable. This creates an absolute path to either the bin\Debug or the bin\Release folder.
Of course TFS is not aware of these locations during an automated build and throws this kind of error for each file that needs to be updated:
C:\Program Files\MSBuild\InstallShield\2011\InstallShield.targets (68): -6103: Could not find file "d:\Builds\1\
Of course it does make sense but how to fix it is the trouble. How can I define the "XML file changes" to look to the project primary output location instead of using an absolute path?
Does anyone have any other suggestions?
Stephen
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Mar 24, 2011
07:23 AM
Hi out there
I encountered quite the same problem as Stephen described. How do I have to reference these config files? Absolute paths are a no go. Is there really no best practice or solution?
Regards
Lars
I encountered quite the same problem as Stephen described. How do I have to reference these config files? Absolute paths are a no go. Is there really no best practice or solution?
Regards
Lars