I never saw it in 3.5 either, which is where I added all of the other projects. I had updated to 3.6.1518 sometime ago, this is the first time I had to add a project to TFS, and the first time I've had an issue.
Another issue that has been there since the beginning, though low priority (at least to me) is that you cannot add a new build configuration (ie, debug, release, etc) from the UI, you have to manually edit the wixProj file. -----Original Message----- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Wednesday, September 21, 2011 1:14 PM To: General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX TFS Source Control bindings in a WixProj - Problem with a manual fix. I've been running WiX 3.5 in VS2010 with TFS 2010 and haven't seen this problem. I've done some VS SDK work and I know how hard it is and how much work the team put into making votive work right. I sure wish InstallShield's VS integration worked nearly as well. Actually I'd settle for it working period. ---------------------------------------- From: "John Bergman" <john.berg...@xpedienttechnologies.com> Sent: Wednesday, September 21, 2011 1:09 PM To: "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> Subject: [WiX-users] WiX TFS Source Control bindings in a WixProj - Problem with a manual fix. Not sure if anyone else has encountered this, but with Wix 3.6.1518.0 when I added a solution to TFS source control it did not update the WixProj correctly, and hence everytime I open the solution I get a message telling me that the project is not under source control, and whether or not I wanted to use the Solution bindings. I went back to look at a wixproj project that does not have the error, and I was able to manually fix this by changing the WixProj manually and checking it in. The changes that were needed are as follows: <SccProjectName>SAK</SccProjectName> <SccProvider>SAK</SccProvider> <SccAuxPath>SAK</SccAuxPath> <SccLocalPath>SAK</SccLocalPath> The project has these elements as being blank when it prompts for the source control binding. -----Original Message----- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Wednesday, September 21, 2011 12:48 PM To: David Rickard (USA); General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow? Open the solution up and click properties on the merge module project. Go to the build events tab then type your command into the pre-build event command line. I still wouldn't do it though. This type of dynamic authoring frequently masks up stream problems. What should have been a build break will end up being a runtime break. ---------------------------------------- From: "David Rickard (USA)" <davri...@microsoft.com> Sent: Wednesday, September 21, 2011 12:44 PM To: "chr...@deploymentengineering.com" <chr...@deploymentengineering.com>, "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> Subject: RE: [WiX-users] Best way to invoke Wix from a TFS build workflow? Alright. In this case how would you run a program to add all the files in a given directory to the MSI? Before we had an EXE that generated a merge module of files based on a directory. Could this hook in somehow? -----Original Message----- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Tuesday, September 20, 2011 4:09 PM To: General discussion for Windows Installer XML toolset.; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow? The simplest way is to use Votive to generate a .SLN / .WIXPROJ and then add the sln configuration | platform to to the build parameters in the build definition. You shouldn't have to do any customizations in workflow as the Default Template will work out of the box. Passing a ProductVersion property takes a little bit more work on the msbuild side ( build parameters and preprocessor definitions in the wixproj and wixs ) but it doesn't require any workflow changes. ---------------------------------------- From: "David Rickard (USA)" <davri...@microsoft.com> Sent: Tuesday, September 20, 2011 5:11 PM To: "wix-users@lists.sourceforge.net" <wix-users@lists.sourceforge.net> Subject: [WiX-users] Best way to invoke Wix from a TFS build workflow? I need to build some MSIs with Wix during our TFS build. Our current TFS build is using the Windows Workflow XAML files to declare the build logic. What's the best way to invoke Wix from there? Directly invoking the process from an activity? Going down to a powershell script and calling it from there? Are there any custom Wix activities to use? ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
