>> At the same time, the WiX build should not require you to install some
>> version of the WiX toolset...
I think that is easily handled with environment variables, I have just been
building my BA extension on a machine with WiX3.6 on it but building the
extension with 3.7. All I needed to do was set these 4 variables (which is
testament to the well-structured msbuild targets):
set WIX=D:\WiX\WiX3.7.1224.0\
set WixInstallPath=%WIX%bin\
set WixExtDir=%WixInstallPath%
set WixTargetsPath=%WixInstallPath%Wix.targets
One thing I did note was that the binaries zip file and the build output folder
are not structured the same as the installed SDK (the bin and inc folders are
different) which can make things harder.
I’ll take a look at the Gaming extension and report back.
Neil
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 18 February 2013 17:59
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Building WiX Code
Okay, sounds like you are solely focused on improving the extensions. In the
past the extension build was horribly designed. Rather, it's design changed
over time and work was never done to reconfigure the whole thing to make it
better.
The points your making are inline with my #2 point below. I reorganized *a lot*
of the extensions in WiX v3.7 to make them build correclty. Most importantly, I
was trying to get *incremental* build correct since it was massively
frustrating when editing any part of an extension required a clean build of the
whole system. We just lived with that for a while since fixing it was work.
Take a look at the Gaming extension or the Bal extension. Both of those are
designed better. The IIS and SQL extensions need their code to get integrated
into their correct places under src\ext\. Ultimately, the src\ca\ tree should
go away since no CustomAction in WiX should live without a helper extension.
Building WiX should not affect the version of WiX you have installed. I do
remember Votive doing some bad stuff a while ago but wix37+ definitely does not
have that issue (I'm running with WiX v3.7 RTM installed plus builds for
37,38,40).
At the same time, the WiX build should not require you to install some version
of the WiX toolset so you can build what will be the next version of the WiX
toolset. That ends up with cycles I don't even want to think about.
Again, back to #2. It should be relatively straight forward to get the various
extension projects building as you describe in Visual Studio. Would you like to
try with something simple like the Gaming extension so it doesn't require one
full build before being opened in WiX? The IIS and SQL stuff will require use
of a blowtorch to cut the CA DLL apart so that can follow later.
Note: I expect the DevBundle is not necessary to get extension realted code
building.
Note2: thmviewer probably just requires a project reference to dutil and I
expect it will work.
Finally, as I noted, the goal is to get contributions into the WiX toolset to
be as easy as possible. If making it easy to get bug fixes and features into
the WiX toolset makes it harder for someone to lift code out of the WiX toolset
and not contribute back, I don't mind that. If we optimize the other way
around, then we're putting forth a policy that is designed to fragment the
community. I don't see how that would help us right now.
Am I missing something?
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
