Using a previous version of the WiX toolset is not easily handled when you
start making changes that depend on changes made to other parts of the WiX
toolset. Again, the focus should be on making improvements (whatever those
may be) to the WiX toolset as easy as possible. If you want to just build
an extension, we provide the SDK for that.
To be transparent, my hope to get more of you deeper into the rabbit hole
where you'll see all the options available when fixing any part of the WiX
toolset is no hurdle. <smile/>
Finally, I thought the SDK folders were all fixed. In the immortal words of
some benevolent dictator I can't remember right now, "We take pull
requests." <wink/>
If you choose to fix the SDK folders, you'll probably want to be able to
build the whole WiX toolset to verify the paths in the .zip files and .msi
files are all correct, right? <wink/> <wink/>
I'd love to know challenges you have doing the above, again, if you choose
to do it. <smile/>
PS: Come to the Dark Side. We have cookies.
On Mon, Feb 18, 2013 at 10:17 AM, Neil Sleightholm <n...@x2systems.com>wrote:
> >> 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
