[Feature] A way (Or create an example) of how to create a standalone fragment and insert into Projects / chains / etc

[Smurf-IV]

I want to use an equivalent of a separate wix file that has the self contained variables / conditions / check / elements as a c# object, that can then be inserted into the relevant areas in a project / bundle / chain / etc.

e.g.
given an existing wix bundle containing

<Chain ParallelCache="yes">
    <PackageGroupRef Id="WindowsDesktopNetRuntime"/>
    ......

And a separate wxs file that has

<Fragment>
    <Variable Name="CheckNETRuntime_RequiredVER" Type="version" Value="8.0.0.33101" />
    <util:RegistrySearch Id="CheckNETRuntime_ID"
                         Variable="CheckNETRuntime_Current"
                         Result="value"
                         Root="HKLM" Key="SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{17316079-d65a-4f25-a9f3-56c32781b15d}"
                         Value="DisplayVersion"
                         Win64="yes"/>

    <PackageGroup Id="WindowsDesktopNetRuntime">
        <ExePackage
            Id="WindowsDesktopNetRuntime"
        ......

How to do this via the wixSharp coding experience in separate files?

Because:
I want to reuse these separate fragments in other projects / bundles / etc.

[oleg-shilo]

There is a code sample for that:

But I added an extension to make it easier to use from files:

static public WixProject AddWixFragmentFile(this Project project, string placementPath, string wixFile)

[Smurf-IV]

But that is just injecting XML.
I want to use a Feature C# object and add things into (Like a project) that can then be referenced by the Parent Project / Bundle / other fragment(s)

[oleg-shilo]

I am not sure I agree that merging multiple WixSharp entities brings adequate value to the product. It is one of those features with the high effort/value ratio.

I am also not convinced that importing the algorithm definition syntax fragments without merging interface/API makes sense. It rather seems like an anti-pattern. Required for WiX but rather questionable for WixSharp.

Mind you that you can still have other C# modules defining logical fragments (e.g. registries, actions):

project.AddActions(...);
project.AddBinaries(...);
project.AddDirs(...);
project.AddProperties(...);
project.AddRegValues(...);

And yet, I see it as a questionable functionality because it leads to the high codebase maintenance cost due to its fragmentation.

[Smurf-IV]

Required for WiX but rather questionable for WixSharp.

This is the crux. When converting a working Wix Project / bundle to wixSharp, it would be nice to have the same reusable component file equivalents for fragment files.

[oleg-shilo]

And you do have this equivalent. AddWixFragmentFile works exactly as in WiX.

[oleg-shilo]

Done. You can import now v1.24.0.0 packages

[Smurf-IV]

Is there a working example of this API usage?
And, Is there going to be a way of not using a WixFile, and doing it in code as requested ?

[oleg-shilo]

Is there a working example of this API usage?

Yes it is in InjectXML
It shows the usage of:

project.AddXmlInclude(...);
project.AddWixFragment(...);
project.AddXml(...);
project.AddXmlElement(...);

And, Is there going to be a way of not using a WixFile, a...

Yes, these methods of adding WixObjects to the project are available:

project.AddActions(...);
project.AddBinaries(...);
project.AddDirs(...);
project.AddProperties(...);
project.AddRegValues(...);