IIRC, it's not candle, it's MSBuild. That makes it harder. <smile/> On Sun, Mar 20, 2011 at 3:40 PM, Rennie Petersen <r...@merlinia.com> wrote:
> Hi Rob, > > Thank you very much for your explanation. > > I have an alternative suggestion as to how this "feature" should be > implemented, as I think it is unfortunate that the current > implementation punishes 99.9% of the WiX users in order to avoid > problems that only 0.1% of the users encounter. > > Add an option to candle.exe (and light.exe?), something like > "-individualizedoutput". > > If the option is missing, place all obj files in the same folder, like > in the good old days. > > But add code to detect the error that 0.1% of the users encounter, the > ones who link to multiple files with the same file name. If you detect > this situation, then write out an error message like "Multiple files > with same file name XxxxxXxxxx.wxs are being compiled to same resulting > obj file. Suggest use of the -individualizedoutput option." The compile > ends with an error code, i.e., the compile is considered to have failed. > > Only if the -individualizedoutput option is present should the current > technique of placing obj files in strange places be enabled. > > I think this would be more user-friendly than the current situation, and > at the same time avoid the need for implementing metadata as you > suggest. > > > -----Original Message----- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: 19. marts 2011 19:00 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] WiX creating obj file in strange place > > It's a feature that usually looks like a bug. The feature came about > because > there were some people creating links to files that had the same file > name. > During compile one of the .wixobj's would get overwritten. It was a very > mysterious issue and took us a long time to figure out. > > Now, I don't care for the way the fix was implemented (I would have > rather > we allow you to specify metadata on one of the files to rename the > .wixobj > output) but that is where we are at right now. If someone wanted to do > the > MSBuild-magic to get the behavior I described above and contribute it, > that > would be quite fantastic. > > On Wed, Mar 16, 2011 at 7:35 AM, Rennie Petersen <r...@merlinia.com> > wrote: > > > In my WiX 3.5 project I'm including a wxs file via a link. I.e., the > wxs > > file is not in the project folder, it is fairly far away in the folder > > structure, and is included using Visual Studio's "Add as a link" > > facility. > > > > > > > > A specific example: > > > > > > > > My project is here: > > > > D:\Merlinia\Trunk\OutBack5x\OutBack Server\WiX 3.5 Install\OutBack > > Server - WiX.wixproj > > > > > > > > I include the following file using "Add as a link": > > > > D:\Merlinia\Trunk\Common5x\WiX Include > files\LicenseAgreementKludge.wxs > > > > > > > > This works fine, except for one strange side-effect. WiX creates two > new > > folders in which to place the obj file for the included file! Here is > > where the obj file is placed: > > > > D:\Merlinia\Trunk\OutBack5x\OutBack Server\Common5x\WiX Include > > files\LicenseAgreementKludge.wixobj > > > > > > > > In doing this it has created the two folders "Common5x\WiX Include > > files". Which I would prefer that it didn't do - I would prefer that > it > > placed the obj file for the included file the same place as all of the > > other obj files. > > > > > > > > Is this a bug or a feature? Is it possible to avoid this? > > > > > > > > I've tried asking about this at StackOverflow, and got some > suggestions, > > but while they fixed the original problem they had side-effects of > their > > own that were even worse. > > > > > http://stackoverflow.com/questions/5235560/wix-creating-obj-file-in-stra > > > nge-place<http://stackoverflow.com/questions/5235560/wix-creating-obj-fi > le-in-strange-place> > > > > > > > > Thanks in advance for any suggestions. > > > > > > > > > > > ------------------------------------------------------------------------ > ------ > > Colocation vs. Managed Hosting > > A question and answer guide to determining the best fit > > for your organization - today and in the future. > > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > -- > virtually, Rob Mensching - http://RobMensching.com LLC > ------------------------------------------------------------------------ > ------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
