[wix-users] Experience of build with WiX 4 Toolset

Sean Hall r.sean.hall at gmail.com
Wed Aug 3 12:07:00 PDT 2022 

I tried to add tests for the issues you reported while converting your
files and the wxl issue in https://github.com/wixtoolset/wix4/pull/212. I
could not reproduce the wxi or wxl issues. Maybe it matters how you have
ordered the command line parameters?

On Mon, Aug 1, 2022 at 4:51 PM Sean Hall <r.sean.hall at gmail.com> wrote:

> > My question was about the switch "-quiet" which was in v3.
>
> The "-quiet" switch still exists in v4 but there was no reason to pass it
> in this case because embedded mode is its own special display mode. I'm not
> sure what to do here. Your BA was parsing the whole command line and not
> just the one provided in the BootstrapperCommand? Was it smart enough to
> get "-q" as well as "-quiet"? It wasn't using the display value from the
> BootstrapperCommand? The engine will operate in embedded mode even if your
> BA wants to run full UI. So for example, it won't show the splash screen.
> If the bundle is running in embedded mode and as a related bundle, then
> showing full UI is probably not the right thing to do.
>
> For the wxl question - as far as I know nothing has changed in this area
> except the namespace. If it worked in v3 then it's supposed to work in v4.
>
> For the wix.dll question - the short answer is to use
> WixToolsetServiceProviderFactory from WixToolset.Core.dll and get the
> appropriate interface. I don't remember off the top of my head what
> interface you need, you might need to create a feature request if it wasn't
> exposed through one.
>
> On Fri, Jul 29, 2022 at 6:20 AM Timofey Evsyutkin <
> goldghost.oomphi.suppository at gmail.com> wrote:
>
>> Thanks, Sean!
>>
>>
>>> I'm surprised you were
>>> able to get something like this working in v3.
>>>
>>
>> Yes, It works in v3.11.2.
>>
>> 0x800705b4 is ERROR_TIMEOUT. The child process is probably crashing.
>>> Hopefully there is a log in %TEMP% with more information. Worst case
>>> would
>>> be that you enable crash dumps and we'd have to debug that.
>>
>>
>> You won't do anything about it. I use "runner" which contains Bundle as
>> an embedded resource.
>> It uses a Mutex for Full UI and another Mutex for Silent. So I need to
>> redesign my code.
>> My question was about the switch "-quiet" which was in v3.
>>
>>
>> Let's go back to one of the previous questions.
>>
>> I'm guessing your wxl file was not upgraded to the new namespace:
>>>
>> http://wixtoolset.org/schemas/v4/wxl. If that's the case, I don't know
>>> why
>>> the toolset isn't giving some kind of error if it had the v3 namespace.
>>
>>
>>  I have Bundle like this:
>> <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs" xmlns:bal="
>> http://wixtoolset.org/schemas/v4/wxs/bal" xmlns:netfx="
>> http://wixtoolset.org/schemas/v4/wxs/netfx">
>>   <?include $(var.WixSourcesRoot)\common\Shared\DEF.wxi?>
>>   <?include
>> $(var.ProductSourcesRoot)\$(var.PathProductName)\productdata.wxi ?>
>>   <Bundle
>>     Name="$(var.DisplayProductName)"
>>     Version="$(var.ProductSetupVersion)"
>>     Manufacturer="$(var.ManufacturerName)"
>>     UpgradeCode="$(var.ProductUpgradeCode)"
>>     DisableModify="no"
>>     DisableRemove="yes">
>>   </Bundle>
>>   <?include
>> $(var.ProductSourcesRoot)\$(var.PathProductName)\fragments.wxi ?>
>> </Wix>
>>
>> In productdata.wxi:
>> <Include xmlns="http://wixtoolset.org/schemas/v4/wxs">
>>    <?define DisplayProductName = "!(loc.DisplayName)" ?>
>> </Include>
>>
>> In loc file:
>> <WixLocalization Culture="en-us" xmlns="
>> http://wixtoolset.org/schemas/v4/wxl" Codepage="1252">
>>   <String Id="DisplayName" Overridable="yes">Test Product</String>
>> </WixLocalization>
>>
>> Should it work? This throws an error.
>>
>> ~\src\Bundle.wxs(4) : error WIX0102:
>>
>> The localization variable !(loc.DisplayName) is unknown.  Please ensure
>>> the variable is defined.
>>
>>
>> It looks like I shouldn't specify wxl files and I should
>> pre-define all variables when building the bundle.
>>
>> I have an extra question.
>> Previously, it was possible to unpack a bundle from MBA
>> using the Microsoft.Tools.WindowsInstallerXml.Unbinder class and
>> wix.dll and winterop.dll libraries from v3.
>> winterop.dll is missing in v4. However, my code is compiled. How can this
>> be done now?
>> I am seeing how it works in ExtractSubcommand.cs, Is it the only one way?
>>
>> пт, 29 июл. 2022 г. в 02:29, Sean Hall via wix-users <
>> wix-users at lists.wixtoolset.org>:
>>
>>> There's no need to apologize, bundles have a lot of moving parts so
>>> there's
>>> not really a way around the back and forth that we're doing here.
>>>
>>> Bundles don't support the MSI changing between build time and runtime, so
>>> they don't support transforms (
>>> https://github.com/wixtoolset/issues/issues/6472). I'm surprised you
>>> were
>>> able to get something like this working in v3. I can only think of two
>>> issues that might be impacting this change in behavior - 3643 and 4663.
>>>
>>> > After install and re-run the installer DetectRelatedMsiPackage event
>>> fires only for the x64 package on the x86 operating system.
>>>
>>> Yes, that is by design. DetectRelatedMsiPackage is only for packages on
>>> the
>>> machine with the same upgrade code but different product code. You're
>>> supposed to use the state parameter from DetectPackageComplete for the
>>> actual package.
>>>
>>> > e000: Error 0x80070020: Failed to cache bundle from... to:
>>> 'C:\ProgramData\Package
>>> Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe'
>>>
>>> 0x80070020 is ERROR_SHARING_VIOLATION. Your MBA appears to be touching
>>> this
>>> file as well so it could be interfering:
>>>
>>>     i000: MBA#: Copying extractor to temp directory:
>>> C:\ProgramData\Package
>>> Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe in
>>> C:\Users\Evsyutkin.Tim\AppData\Local\Temp\uoelhrqv.y4d\Boot.exe
>>>
>>> On the other hand, I think v3 skipped trying to copy the file if it
>>> already
>>> existed. v4 always tries to copy over it in case it was corrupted. Maybe
>>> v4
>>> needs to ignore this error.
>>>
>>> > e000: Error 0x800705b4: Failed to wait for child to connect to pipe
>>>
>>> 0x800705b4 is ERROR_TIMEOUT. The child process is probably crashing.
>>> Hopefully there is a log in %TEMP% with more information. Worst case
>>> would
>>> be that you enable crash dumps and we'd have to debug that.
>>>
>>> > Why don't command line arguments contain the "-quiet" switch?
>>>
>>> It is running the bundle as an embedded bundle, which is its own version
>>> of
>>> quiet.
>>>
>>> > Also some Detect events fire twice.
>>>
>>> The DetectRelatedMsiPackage duplicate is because there are different
>>> languages (0 and 1033).
>>>
>>> I don't understand the DetectRelatedBundle duplicate. This might be a bug
>>> on x86 machines where it tries to enumerate the 64-bit registry but that
>>> ends up enumerating the 32-bit registry a second time.
>>>
>>> On Thu, Jul 28, 2022 at 5:49 AM Timofey Evsyutkin <
>>> goldghost.oomphi.suppository at gmail.com> wrote:
>>>
>>> > Thanks, Sean!
>>> >
>>> > Your answer kicked me. I am really sorry! I should have provided more
>>> > information.
>>> > I found out why it happens.
>>> > I use embedded transformations to create MUI MSI like this:
>>> > @cscript "%_WindowsSdkDir%bin\x86\WiLangId.vbs"
>>> > "%MSI_PATH%\%MSI_NAME%.msi" Product %LANGUAGE_ID%
>>> > @"%_WindowsSdkDir%bin\x86\MsiTran.exe" -g %MUI_SETUP%
>>> > %MSI_PATH%\%MSI_NAME%.msi %UnloadMuiMsiPath%\%CULTURE%.mst
>>> > @cscript "%_WindowsSdkDir%bin\x86\WiSubStg.vbs" "%MUI_SETUP%"
>>> > "%UnloadMuiMsiPath%\%CULTURE%.mst" %LANGUAGE_ID%
>>> > @cscript "%_WindowsSdkDir%bin\x86\WiSubStg.vbs" "%MUI_SETUP%"
>>> >
>>> > Transformation changes the ProductCode during the install.
>>> > >> Product Code passed to Engine.Initialize:           ''
>>> > >> Product Code from property table before transforms:
>>> > '{3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}'
>>> > >> Product Code from property table after transforms:
>>> > '{3D8554F9-E2B4-40B0-869E-10FADD1EF636}'
>>> > >> Product not registered: beginning first-time install
>>> > >> Product {3D8554F9-E2B4-40B0-869E-10FADD1EF636} is not managed.
>>> >
>>> > After that I am getting the installed product with two different
>>> > ProductCode in the registry.
>>> > It looks so strange. I uploaded extra files.
>>> >
>>> https://drive.google.com/drive/folders/1SIL4xzyd9S5KqbuJmgHNk3qygKpU_aeM?usp=sharing
>>> > So, MSI doesn't work as earlier. But It worked with version 3.
>>> > I am going to freeze Package/@Id for the MSIs build process and
>>> continue
>>> > my journey in this way.
>>> > However, what should I do if I take strange MSI with embedded
>>> > transformations?
>>> >
>>> >
>>> > Also I tried it out with MSI which has only one language. There is a
>>> > similar log:
>>> > >> Product Code passed to Engine.Initialize:           ''
>>> > >> Product Code from property table before transforms:
>>> > '{A9B478AB-23B1-4787-B574-FA71EB79D181}'
>>> > >> Product Code from property table after transforms:
>>> > '{A9B478AB-23B1-4787-B574-FA71EB79D181}'
>>> > >> Product not registered: beginning first-time install
>>> > >> Product {A9B478AB-23B1-4787-B574-FA71EB79D181} is not managed.
>>> >
>>> > It works and seems like all good but it is not exactly.
>>> >
>>> > After install and re-run the installer
>>> > DetectRelatedMsiPackage event fires only for the x64 package on the x86
>>> > operating system,
>>> > so MBA has incorrect info about the system state. For example, if I
>>> plan
>>> > Repair, then the product will be removed.
>>> > Should I use bal:PrimaryPackageType?
>>> >
>>> > When I run installer from Package Cache by link I get this error on
>>> > register process:
>>> > i000: MBA#: EVENT: RegisterBegin
>>> >
>>> ({"RecommendedRegistrationType":2,"RegistrationType":2,"Cancel":false,"HResult":0})
>>> > i370: Session begin, registration key:
>>> >
>>> SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A},
>>> > options: 0x3, disable resume: No
>>> > i000: Caching bundle from:
>>> > 'C:\Windows\TEMP\{6C28A1FE-C63E-4A96-8A37-66C33029A122}\.be\Boot.exe'
>>> to:
>>> > 'C:\ProgramData\Package
>>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe'
>>> > e000: Error 0x80070020: Failed to cache bundle from:
>>> > 'C:\Windows\TEMP\{6C28A1FE-C63E-4A96-8A37-66C33029A122}\.be\Boot.exe'
>>> to
>>> > 'C:\ProgramData\Package
>>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe'
>>> > e000: Error 0x80070020: Failed to cache bundle from path:
>>> > C:\Windows\TEMP\{6C28A1FE-C63E-4A96-8A37-66C33029A122}\.be\Boot.exe
>>> > e000: Error 0x80070020: Failed to begin registration session.
>>> > e000: Error 0x80070020: Failed to begin registration session in
>>> > per-machine process.
>>> > i000: MBA#: EVENT: RegisterComplete
>>> ({"Status":-2147024864,"HResult":0})
>>> > e000: Error 0x80070020: Failed to register bundle.
>>> >
>>> > When I try to Update the installed product I get this error on
>>> uninstall a
>>> > previous bundle:
>>> > i301: Applying execute package: {76B4A6BF-A40F-4C25-BAC1-182F0EF5848A},
>>> > action: Uninstall, path: C:\ProgramData\Package
>>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe, arguments:
>>> > '"C:\ProgramData\Package
>>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe" -uninstall
>>> > -burn.related.upgrade
>>> > -burn.ancestors={5634A379-6E22-40D3-85D8-6C5A4DD609CE}
>>> > -burn.filehandle.self=1004'
>>> > e000: Error 0x800705b4: Failed to wait for child to connect to pipe.
>>> > e000: Error 0x800705b4: Failed to wait for embedded process to connect
>>> to
>>> > pipe.
>>> > e000: Error 0x800705b4: Failed to run bundle as embedded from path:
>>> > C:\ProgramData\Package
>>> Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe
>>> > e000: Error 0x800705b4: Failed to execute related bundle.
>>> > e000: Error 0x800705b4: Failed to configure per-machine related bundle.
>>> > As a result the previous bundle is not removed. Why don't command line
>>> > arguments contain the "-quiet" switch?
>>> > Also some Detect events fire twice.
>>> >
>>> > ср, 27 июл. 2022 г. в 00:16, Sean Hall via wix-users <
>>> > wix-users at lists.wixtoolset.org>:
>>> >
>>> >> I'm guessing your wxl file was not upgraded to the new namespace:
>>> >> http://wixtoolset.org/schemas/v4/wxl. If that's the case, I don't
>>> know
>>> >> why
>>> >> the toolset isn't giving some kind of error if it had the v3
>>> namespace.
>>> >>
>>> >> For the bundle, can you run 'wix.exe burn extract path\to\bundle.exe
>>> -o
>>> >> path\to\outputfolder'? Then upload the BA\manifest.xml file for both
>>> >> bundles. I don't understand what I'm seeing in the logs. The CacheId
>>> >> ({3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}v1.1.1.1) and dependency
>>> provider
>>> >> ({3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}_v1.1.1.1) say that the product
>>> >> code
>>> >> is '{3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}' but the detected package's
>>> >> product code is '{3D8554F9-E2B4-40B0-869E-10FADD1EF636}'.
>>> >>
>>> >> On Tue, Jul 26, 2022 at 9:11 AM Timofey Evsyutkin <
>>> >> goldghost.oomphi.suppository at gmail.com> wrote:
>>> >>
>>> >> > Thanks, Sean!
>>> >> >
>>> >> > I'm confused why you brought up missing loc variables. Did you
>>> expect
>>> >> them
>>> >> >> to be found?
>>> >> >>
>>> >> >
>>> >> > Yes, I did. I passed loc.DisplayName from a file by the following
>>> >> command
>>> >> > line
>>> >> > as similar that as I did with light in WiX Toolset v3:
>>> >> >
>>> >> > "~\wix_toolset\wix.exe" build -wx^
>>> >> >  -ext
>>> >> >
>>> >>
>>> "~\wix_toolset\.wix4\extensions\WixToolset.Bal.wixext\4.0.0-source\tools\WixToolset.Bal.wixext.dll"^
>>> >> >  -ext
>>> >> >
>>> >>
>>> "~\wix_toolset\.wix4\extensions\WixToolset.Netfx.wixext\4.0.0-source\tools\WixToolset.Netfx.wixext.dll"^
>>> >> >  -ext
>>> >> >
>>> >>
>>> "~\wix_toolset\.wix4\extensions\WixToolset.Util.wixext\4.0.0-source\tools\WixToolset.Util.wixext.dll"^
>>> >> >  -arch "x86"^
>>> >> >  -culture "en-US"^
>>> >> >  -loc "~\test_product\loc\ENU\ENU.wxl"^
>>> >> >  -trackingfile "~\temp\test_product\track_boot_ENU_x86.log"^
>>> >> >  -intermediatefolder "~\temp\test_product\ENU\"^
>>> >> >  -d "PathProductName=test_product"^
>>> >> >  -d "ProductSourcesRoot=~"^
>>> >> >  -d "SharedComponentsPath=~\src\shared_components"^
>>> >> >  -d "SharedSrcPath=~\src\common_code"^
>>> >> >  -out ~\test_product\Bundle\ENU\Boot.exe^
>>> >> >  -src "~\src\Bundle.wxs"
>>> >> >
>>> >> > I should not configure wxl for Bundle and add switches "-culture"
>>> "-loc"
>>> >> > to build commands, is it right?
>>> >> >
>>> >> > Custom BAs are very complex so it's pretty much impossible to guess
>>> >> what's
>>> >> >> wrong. It would help if you could provide the Burn log from %TEMP%
>>> >> along
>>> >> >> with the relevant code from your BA.
>>> >> >>
>>> >> >
>>> >> > I apologize for misleading you.
>>> >> > I looked deeper.
>>> >> > The DetectRelatedMsiPackage event (after DetectPackageBegin)
>>> determines
>>> >> > the incorrect state of the package and features (returns the
>>> incorrect
>>> >> > operation - Downgrade).
>>> >> > It happens even with the expected upgrade.
>>> >> > Unfortunately, I can not provide the relevant code from my BA.
>>> >> > But the logs here:
>>> >> >
>>> >>
>>> https://drive.google.com/drive/folders/1SIL4xzyd9S5KqbuJmgHNk3qygKpU_aeM?usp=sharing
>>> >> >
>>> >> > чт, 21 июл. 2022 г. в 22:10, Sean Hall via wix-users <
>>> >> > wix-users at lists.wixtoolset.org>:
>>> >> >
>>> >> >> Thanks for trying it out and reporting your findings here.
>>> >> >>
>>> >> >> WIX1150 is a warning, you must have opted in to treating warnings
>>> as
>>> >> >> errors. It was added in v4 and it looks like we missed the Fragment
>>> >> >> symbol.
>>> >> >> Fragment/@Id is not deprecated, but at the same time it doesn't
>>> >> actually
>>> >> >> do
>>> >> >> anything.
>>> >> >>
>>> >> >> WIX8500 is also a warning, and it was also added in v4. The issue
>>> that
>>> >> it
>>> >> >> is warning about existed in v3 as well, it just didn't tell you
>>> about
>>> >> it.
>>> >> >>
>>> >> >> I'm confused why you brought up missing loc variables. Did you
>>> expect
>>> >> them
>>> >> >> to be found?
>>> >> >>
>>> >> >> Custom BAs are very complex so it's pretty much impossible to guess
>>> >> what's
>>> >> >> wrong. It would help if you could provide the Burn log from %TEMP%
>>> >> along
>>> >> >> with the relevant code from your BA.
>>> >> >>
>>> >> >> On Thu, Jul 21, 2022 at 6:03 AM Timofey Evsyutkin via wix-users <
>>> >> >> wix-users at lists.wixtoolset.org> wrote:
>>> >> >>
>>> >> >> > Hi there
>>> >> >> >
>>> >> >> > I have recently converted and built a small "Test Project" from
>>> v3 to
>>> >> >> v4.
>>> >> >> > I took 4.0.0-preview.1-build.425 for this and got some errors.
>>> >> >> >
>>> >> >> > Converter did not cover some situations.
>>> >> >> >
>>> >> >> > Related to WIX0022 after converting:
>>> >> >> > 1. There is an empty condition. For example,
>>> >> >> >      <Text><![CDATA[]]></Text>
>>> >> >> > 2. There is an inner comment. For example,
>>> >> >> >      <Custom Action ... something here ... >
>>> >> >> >          <!-- comment of action -->
>>> >> >> >          <![CDATA[ ... something here ... ]]]
>>> >> >> >      </Custom>
>>> >> >> >      <Condition Message="!(loc.UpdateKB2533623NotFound)">
>>> >> >> >          <!-- comment of condition -->
>>> >> >> >          <![CDATA[NOT ((UpdateKB2533623Exist = "No") AND
>>> (VersionNT =
>>> >> >> > 601))]]>
>>> >> >> >      </Condition>
>>> >> >> > 3. There is a condition in include file (wxi). For example,
>>> >> >> >      <Include xmlns="http://wixtoolset.org/schemas/v4/wxs">
>>> >> >> >          <Condition Message="!(loc.InvalidOsVersion)">
>>> >> >> >              <![CDATA[NOT (VersionNT < 601)]]>
>>> >> >> >          </Condition>
>>> >> >> >      </Include>
>>> >> >> >
>>> >> >> > Related to WIX1150. For example,
>>> >> >> >      ~\test_product\fragments.wxi(7) : error WIX1150:
>>> >> >> >      The binder doesn't know how to place the following symbol
>>> into
>>> >> the
>>> >> >> > output:
>>> >> >> >      SymbolName: 'WixFragment', Id: 'MsiPackages'
>>> >> >> > Are identifiers of fragments deprecated?
>>> >> >> >
>>> >> >> > I submitted it because the converter did not mark them as an
>>> error.
>>> >> >> > However it is taking place when you are building with wix.
>>> >> >> >
>>> >> >> > When I was building a Bundle, I got these errors:
>>> >> >> > ~\test_product\components\test_product.wxi(21) : error WIX8500:
>>> >> >> > The Payload 'cabqsnbgoiL2yJhlIDGB7CrS2Lfb7k' has a duplicate Name
>>> >> >> > 'setup.cab' in the attached container.
>>> >> >> > When extracting the bundle with dark.exe, the file will get
>>> >> overwritten.
>>> >> >> > ~\test_product\components\test_product.wxi(12) : error WIX8501:
>>> >> >> > The location of the payload related to the previous error.
>>> >> >> >
>>> >> >> > I suppressed them, is it ok?
>>> >> >> >
>>> >> >> > Also I've got these errors:
>>> >> >> > ~\src\Bundle.wxs(55) : error WIX0102:
>>> >> >> > The localization variable !(loc.DisplayName) is unknown.  Please
>>> >> ensure
>>> >> >> the
>>> >> >> > variable is defined.
>>> >> >> > ~\src\Bundle.wxs(11) : error WIX0102:
>>> >> >> > The localization variable !(loc.DisplayName) is unknown.  Please
>>> >> ensure
>>> >> >> the
>>> >> >> > variable is defined.
>>> >> >> > ~\src\Bundle.wxs(11) : error WIX0102:
>>> >> >> > The localization variable !(loc.DisplayName) is unknown.  Please
>>> >> ensure
>>> >> >> the
>>> >> >> > variable is defined.
>>> >> >> >
>>> >> >> > I "fixed" my code. After that I got MSIs and EXE-installer. MSI
>>> works
>>> >> >> fine
>>> >> >> > as expected.
>>> >> >> > However, I noticed strange behavior with EXE.
>>> >> >> > After a successful installation, when I run the installer again,
>>> >> >> > the bootstrapperCommand is determined to downgrade.
>>> >> >> > It was expected that there would be an opportunity to choose an
>>> >> action:
>>> >> >> > modify/repair/remove.
>>> >> >> > But when I skipped the downgrade action in debugging and chose
>>> the
>>> >> >> remove
>>> >> >> > action,
>>> >> >> > the uninstall didn't happen.
>>> >> >> > note: I use WixManagedBootstrapperApplicationHost and
>>> >> >> > WixDotNetCoreBootstrapperApplicationHost.
>>> >> >> > What am I doing wrong? Can I influence the engine through events
>>> or
>>> >> >> should
>>> >> >> > I not do this?
>>> >> >> > I do not expect a detailed answer, at least the direction where
>>> to
>>> >> move.
>>> >> >> > Thanks.
>>> >> >> >
>>> >> >> > --
>>> >> >> > Best Regards, Timofey Evsyutkin
>>> >> >> > P.H.D., Software Engineer
>>> >> >> >
>>> >> >> >
>>> >> >> > CONFIDENTIALITY NOTICE: The information contained in this email
>>> and
>>> >> >> > attached document(s) may contain confidential information that is
>>> >> >> intended
>>> >> >> > only for the addressee(s). If you are not the intended
>>> recipient, you
>>> >> >> are
>>> >> >> > hereby advised that any disclosure, copying, distribution or the
>>> >> taking
>>> >> >> of
>>> >> >> > any action in reliance upon the information is prohibited. If you
>>> >> have
>>> >> >> > received this email in error, please immediately notify the
>>> sender
>>> >> and
>>> >> >> > delete it from your system.
>>> >> >> >
>>> >> >> >
>>> ____________________________________________________________________
>>> >> >> > WiX Toolset Users Mailing List provided by FireGiant
>>> >> >> > http://www.firegiant.com/
>>> >> >> >
>>> >> >>
>>> >> >>
>>> ____________________________________________________________________
>>> >> >> WiX Toolset Users Mailing List provided by FireGiant
>>> >> >> http://www.firegiant.com/
>>> >> >>
>>> >> >
>>> >>
>>> >> ____________________________________________________________________
>>> >> WiX Toolset Users Mailing List provided by FireGiant
>>> >> http://www.firegiant.com/
>>> >
>>> >
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Users Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>
>>

More information about the wix-users mailing list