Discussion:
[WiX-users] Burn and Upgrades
Christian Hausknecht
2012-09-28 13:38:53 UTC
Permalink
Hello folks,

is there anything in Burn that provides a possibility to define a minimum and a maximum bundle version for and upgrade like the <UpgradeVersion>-Tags in WiX? And if not is there a way to handle a check without writing a custom BA? Overall what is the exact behavior of a bundle that recognizes that its version is higher than the one of the installed bundle?

Greetings,

Mit freundlichen Grüßen

Christian Hausknecht
Entwicklung

BeraCom
Beratung und Software-Entwicklung GmbH & Co. KG
Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
M: ***@beracom.de<mailto:***@beracom.de>
http://www.beracom.de

=============================================
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932
Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH
Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss
Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit.
Brian C
2012-09-28 13:56:24 UTC
Permalink
I am trying, in my Managed Bootstrap Application, detect that my bundle is already installed and that a few optional features are installed as well.  I wrote the code below, but I never get into the PlantMsiFeature code.  I have set the EnableFeatureSelection on my MsiPackage. Basically, the thinking here is that PlanMsiFeature is called when either (a) the BA is called while the product is installed or (b) the Change button is selected in Add/Remove Programs.  The OptFeat…Selected functions mark that the Feature name should be added to the ADDLOCAL string I pass to the MsiPackage as a property and also set an internal property which corresponds to a checkbox on the RootView (the xaml code).  But, I never see this logging in my log file and I have tried all the possible options for LogLevel.
 
               
privatevoid PlanMsiFeature(object sender, PlanMsiFeatureEventArgs e)
        {
            /*  PROJMGMT = "ProjectEnvironment";
                BULKLOAD = "Bulkload";
                PIDSERVICE ="PIDService";
                IFCSERVICE = "IFCService";
                SERVER = "Server";
            */
 
            // Only check feature states if product is already installed
            if (this.root.State == InstallationState.DetectedPresent)
            {
                TestBA.Model.Engine.Log(LogLevel.Debug, "$$$ - Detected Feature: " + e.FeatureId.ToString() + " State: " + e.State.ToString());              
                switch (e.FeatureId.ToString())
                {
                    case PROJMGMT:
                        if (e.State == FeatureState.Local)
                        {
                            this.OptFeatProjMgmtSelected = true;
                        }
                        break;
 
                    case BULKLOAD:
                        if (e.State == FeatureState.Local)
                        {
                            this.OptFeatBulkloadSelected = true;
                        }
                        break;
 
                    case PIDSERVICE:
                        if (e.State == FeatureState.Local)
                        {
                            this.OptFeatPIDServiceSelected = true;
                        }
                        break;
 
                    case IFCSERVICE:
                        if (e.State == FeatureState.Local)
                        {
                            this.OptFeatIFCServiceSelected = true;
                        }
                        break;
 
                    case SERVER:
                        if (e.State == FeatureState.Local)
                        {
                            this.OptFeatSvrConnSelected = true;
                        }
                        break;
                }
            }
        }
 
                Assuming I get the detection of feature states working, what would I then call to do the modification?  I added a ModifyCommand, similar to the InstallCommand in the WixBA, to “apply” the changes to feature state.  Is this what should be called or would you call Plan(LaunchAction.Install) again?
 
publicICommand ModifyCommand
        {
            get
            {
                if (this.modifyCommand == null)
                {
                    this.modifyCommand = new RelayCommand(param => this.Plan(LaunchAction.Modify), param => this.root.State == InstallationState.DetectedPresent);
                }
 
                return this.modifyCommand;
            }
        }
 
Thanks in advance,
Brian
tom
2012-09-30 19:34:16 UTC
Permalink
Try "DetectMsiFeature"

I think you need to set the requested feature state in

PlanMsiFeature

Not sure though.

Tomer...



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detecting-Feature-state-in-Managed-BA-tp7580920p7580939.html
Sent from the wix-users mailing list archive at Nabble.com.
Brian_Covington
2012-10-01 14:33:43 UTC
Permalink
I have the same code in the DetectMsiFeature and, both get called in the
initial installation. However, when I run the bootstrap executable again
(or run Change in ARP) I do not get any calls to PlanMsiFeature, which is
where I modify the feature states based upon user input.





--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detecting-Feature-state-in-Managed-BA-tp7580920p7580966.html
Sent from the wix-users mailing list archive at Nabble.com.
Bob Arnson
2012-10-02 01:38:18 UTC
Permalink
Post by Brian_Covington
I have the same code in the DetectMsiFeature and, both get called in the
initial installation. However, when I run the bootstrap executable again
(or run Change in ARP) I do not get any calls to PlanMsiFeature, which is
where I modify the feature states based upon user input.
Start with the Burn log; every package with feature selection enabled
and features found should get log messages of the form:

Plan %1!u! msi features for package: %2!ls!

during the plan phase but before the "Planned package" message.
--
sig://boB
http://joyofsetup.com/
Brian_Covington
2012-10-02 12:40:52 UTC
Permalink
Yes, that is what I am expected to see, but I do not see anything. If you
look at the log, you can see where I "clicked" the checkbox, which sets the
string variable AddLocalSet on the Engine, but the PlanMsiFeature, where I
look at what checkboxes are checked and attempt to alter the Feature states
accordingly, never gets called. I have a command button which calls
Plan(LaunchAction.Modify), which I assumed would be the correct call to get
the PlanMsiFeatures called, but either that is a wrong assumption or I have
to do more to tell the package it has modified features.

In this attempt, the ProjectEnvironment feature was selected and installed
during the initial install. On the Modify, I selected the Bulkload feature,
which should be added. There is also an OptionalFeatures feature, but that
is just the parent feature to all option features.

Burn log, shortened for brevity sake:

[1028:11EC][2012-10-01T17:28:46]: Burn v3.6.3303.0, Windows v6.1 (Build
7601: Service Pack 1), path:
\\SP3D\XRoot\Tools\Setup\DVD\Smart3D\Installation\S3DInstallationBS.exe,
cmdline: '-burn.unelevated BurnPipe.{8405339B-C3AD-4F24-A232-B61E38C4BF25}
{4F6B6700-1408-4A4E-8278-B71CD9F8FB24} 3876'
[1028:11EC][2012-10-01T17:28:47]: Setting string variable 'WixBundleLog' to
value
'C:\Users\sp3dtest\AppData\Local\Temp\Intergraph_S3D_20121001172847.log'
[1028:11EC][2012-10-01T17:28:47]: Setting string variable
'WixBundleOriginalSource' to value
'\\SP3D\XRoot\Tools\Setup\DVD\Smart3D\Installation\S3DInstallationBS.exe'
[1028:11EC][2012-10-01T17:28:47]: Condition 'NOT ((VersionNT = 600 AND
ServicePackLevel >=2) OR (VersionNT >= 601))' evaluates to true.
[1028:11EC][2012-10-01T17:28:47]: Loading managed bootstrapper application.
[1028:11EC][2012-10-01T17:28:47]: Creating BA thread to run asynchronously.
[1028:0428][2012-10-01T17:28:47]: Running the WiX BA
[1028:11EC][2012-10-01T17:28:47]: Detect 2 packages
[1028:0428][2012-10-01T17:28:47]: Setting string variable 'InstallPath' to
value 'C:\Program Files (x86)\Smart3D'
[1028:0428][2012-10-01T17:28:47]: Creating a UI.
[1028:11EC][2012-10-01T17:28:47]: Setting string variable 'AddLocalSet' to
value 'ProjectEnvironment'
[1028:11EC][2012-10-01T17:28:48]: Detected package: S3DInstall, state:
Present, cached: Complete
[1028:11EC][2012-10-01T17:28:48]: Detected package: S3DInstall, feature:
PIDService, state: Absent
[1028:11EC][2012-10-01T17:28:48]: Detected package: S3DInstall, feature:
Server, state: Absentate: Absent
[1028:11EC][2012-10-01T17:28:48]: *Detected package: S3DInstall, feature:
Bulkload, state: Absent*
[1028:11EC][2012-10-01T17:28:48]: Detected package: S3DInstall, feature:
OptionalFeatures, state: Local
[1028:11EC][2012-10-01T17:28:48]: *Detected package: S3DInstall, feature:
ProjectEnvironment, state: Local*
[1028:11EC][2012-10-01T17:28:48]: Detected package: S3DInstall, feature:
IFCService, state: Absent
[1028:11EC][2012-10-01T17:28:48]: Detected package: RADInstall, state:
Present, cached: Complete
[1028:11EC][2012-10-01T17:28:48]: Detect complete, result: 0x0
[1028:0428][2012-10-01T17:28:49]: *Setting string variable 'AddLocalSet' to
value 'ProjectEnvironment,Bulkload'*
[1028:11EC][2012-10-01T17:28:51]: Plan 2 packages, action: Modify
[1028:11EC][2012-10-01T17:28:51]: Planned package: S3DInstall, state:
Present, default requested: None, ba requested: None, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[1028:11EC][2012-10-01T17:28:51]: Planned package: RADInstall, state:
Present, default requested: None, ba requested: None, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[1028:11EC][2012-10-01T17:28:51]: Plan complete, result: 0x0
[1028:11EC][2012-10-01T17:28:51]: Apply begin
[0F24:0A68][2012-10-01T17:28:57]: Automatic updates could not be paused due
to error: 0x80070422. Continuing...
[0F24:0A68][2012-10-01T17:28:57]: Creating a system restore point.
[0F24:0A68][2012-10-01T17:28:57]: Could not create system restore point,
error: 0x80070422. Continuing...
[1028:11EC][2012-10-01T17:28:57]: Apply complete, result: 0x0, restart:
None, ba requested restart: No



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detecting-Feature-state-in-Managed-BA-tp7580920p7581013.html
Sent from the wix-users mailing list archive at Nabble.com.
Bob Arnson
2012-10-03 03:12:39 UTC
Permalink
Post by Brian_Covington
Yes, that is what I am expected to see, but I do not see anything. If you
look at the log, you can see where I "clicked" the checkbox, which sets the
string variable AddLocalSet on the Engine, but the PlanMsiFeature, where I
look at what checkboxes are checked and attempt to alter the Feature states
accordingly, never gets called. I have a command button which calls
Plan(LaunchAction.Modify), which I assumed would be the correct call to get
the PlanMsiFeatures called, but either that is a wrong assumption or I have
to do more to tell the package it has modified features.
It should get called for any action. The logging makes it look like Burn
forgot the package had feature selection enabled or otherwise lost the
feature count between Detect and Plan. Hard to tell more without getting
it under the debugger. MsiEnginePlanCalculatePackage in msiengine.cpp is
the function that *should* be calling OnPlanMsiFeature.
--
sig://boB
http://joyofsetup.com/
tom
2012-10-03 22:03:42 UTC
Permalink
Looks like /LaunchAction.Modify/ does not modify the package state
and it stay in a None state
(I think Rob also mentioned it somewhere)
The engine Process Package function check if the package should be processed

//If the package is in a requested state, plan it.
if (BOOTSTRAPPER_REQUEST_STATE_NONE != pPackage->requested)
{
// do the stuff
}

Is this make sense to change the package state in the
PlanPackageBegin event? i did it and the event is called.




--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detecting-Feature-state-in-Managed-BA-tp7580920p7581074.html
Sent from the wix-users mailing list archive at Nabble.com.
Bob Arnson
2012-10-04 02:29:45 UTC
Permalink
Post by tom
Is this make sense to change the package state in the
PlanPackageBegin event? i did it and the event is called.
Yes, that makes perfect sense.
--
sig://boB
http://joyofsetup.com/
Brian_Covington
2012-10-09 18:23:47 UTC
Permalink
For those who are searching for an answer, this is what has worked for us:

private void PlanPackageBegin(object sender, PlanPackageBeginEventArgs e)

// if this is the package, which has optional features
if (e.PackageId.Equals("<package_ID_with_optfeatures>",
StringComparison.Ordinal))
{
// if the action being planned is Modify
if (this.plannedAction == LaunchAction.Modify)
{
// set the state of the package to present, which will prompt the
call to PlanMsiFeatures
e.State = RequestState.Present;
}
}

and as you can see in the log, it correctly finds that I have 3 features
installed and that I want to remove two of them (and does so quite nicely!
):

[1078:0A18][2012-10-09T07:55:06]: Condition 'NOT ((VersionNT = 600 AND
ServicePackLevel >=2) OR (VersionNT >= 601))' evaluates to true.
[1078:0A18][2012-10-09T07:55:06]: Loading managed bootstrapper application.
[1078:0A18][2012-10-09T07:55:06]: Creating BA thread to run asynchronously.
[1078:1160][2012-10-09T07:55:06]: Running the WiX BA
[1078:0A18][2012-10-09T07:55:06]: Detect 2 packages
[1078:1160][2012-10-09T07:55:06]: Setting string variable 'InstallPath' to
value 'C:\Program Files (x86)\Hippo'
[1078:1160][2012-10-09T07:55:06]: Creating a UI.
[1078:0A18][2012-10-09T07:55:06]: Detected package: Hippo, state: Present,
cached: Complete
[1078:0A18][2012-10-09T07:55:06]: Detected package: Hippo, feature:
PIDService, state: Absent
[1078:0A18][2012-10-09T07:55:06]: *Detected package: Hippo, feature: Server,
state: Local*
[1078:0A18][2012-10-09T07:55:06]: *Detected package: Hippo, feature:
Bulkload, state: Local*
[1078:0A18][2012-10-09T07:55:06]: *Detected package: Hippo, feature:
ProjectEnvironment, state: Local*
[1078:0A18][2012-10-09T07:55:06]: Detected package: Hippo, feature:
IFCService, state: Absent
[1078:0A18][2012-10-09T07:55:06]: Detected package: Hippo_Server, state:
Present, cached: Complete
[1078:0A18][2012-10-09T07:55:06]: Detect complete, result: 0x0
[1078:0A18][2012-10-09T08:42:35]: Plan 2 packages, action: Modify
[1078:0A18][2012-10-09T08:42:43]: Plan 5 msi features for package: Hippo
[1078:0A18][2012-10-09T08:42:43]: Planned feature: PIDService, state:
Absent, default requested: Unknown, ba requested: Absent, execute action:
None, rollback action: None
*[1078:0A18][2012-10-09T08:42:43]: Planned feature: Server, state: Local,
default requested: Unknown, ba requested: Local, execute action: None,
rollback action: None*
[1078:0A18][2012-10-09T08:42:43]: *Planned feature: Bulkload, state: Local,
default requested: Unknown, ba requested: Absent, execute action: Remove,
rollback action: AddLocal*
[1078:0A18][2012-10-09T08:42:43]: *Planned feature: ProjectEnvironment,
state: Local, default requested: Unknown, ba requested: Absent, execute
action: Remove, rollback action: AddLocal*
[1078:0A18][2012-10-09T08:42:43]: Planned feature: IFCService, state:
Absent, default requested: Unknown, ba requested: Absent, execute action:
None, rollback action: None
[1078:0A18][2012-10-09T08:42:43]: Setting string variable
'WixBundleRollbackLog_Hippo' to value
'C:\Users\sp3dtest\AppData\Local\Temp\COMPANY_NAME_20121009075506_0_Hippo_rollback.log'
[1078:0A18][2012-10-09T08:42:43]: Setting string variable
'WixBundleLog_Hippo' to value
'C:\Users\sp3dtest\AppData\Local\Temp\COMPANY_NAME_20121009075506_0_Hippo.log'
[1078:0A18][2012-10-09T08:42:43]: Planned package: Hippo, state: Present,
default requested: None, ba requested: Present, execute: Modify, rollback:
Modify, cache: No, uncache: No, dependency: Register
[1078:0A18][2012-10-09T08:42:43]: Planned package: Hippo_Server, state:
Present, default requested: None, ba requested: None, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[1078:0A18][2012-10-09T08:42:43]: Plan complete, result: 0x0
[1078:0A18][2012-10-09T08:42:43]: Apply begin

Many thanks for the help!

Brian



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detecting-Feature-state-in-Managed-BA-tp7580920p7581244.html
Sent from the wix-users mailing list archive at Nabble.com.
Bob Arnson
2012-10-10 03:00:25 UTC
Permalink
Post by Brian_Covington
private void PlanPackageBegin(object sender, PlanPackageBeginEventArgs e)
Please file a bug on this -- I'd vote that it's a bug that the engine
doesn't call OnPlanMsiFeature; if it would and a feature state was
change, it would set the package action to BOOTSTRAPPER_ACTION_STATE_MODIFY.
--
sig://boB
http://joyofsetup.com/
Brian C
2012-10-10 03:36:20 UTC
Permalink
Okay, done.  https://sourceforge.net/p/wix/bugs/3116/ LaunchAction.Modify on Present package does not call PlanMsiFeature



________________________________
From: Bob Arnson <***@joyofsetup.com>
To: wix-***@lists.sourceforge.net
Sent: Tuesday, October 9, 2012 10:00 PM
Subject: Re: [WiX-users] Detecting Feature state in Managed BA
Post by Brian_Covington
private void PlanPackageBegin(object sender, PlanPackageBeginEventArgs e)
Please file a bug on this -- I'd vote that it's a bug that the engine
doesn't call OnPlanMsiFeature; if it would and a feature state was
change, it would set the package action to BOOTSTRAPPER_ACTION_STATE_MODIFY.
--
sig://boB
http://joyofsetup.com/
tom
2012-10-10 09:33:16 UTC
Permalink
At first it did not make sense to me
Why the default requested state should be changed to Present?
Isn’t modify can be called only when the package is Present?!

But I think this may be the correct process
Consider a bundle with 2 MSI packages, one is your product and the other is
the
Vc redist which you only want to install one time, and you don’t have a UI
for
Features selection
If the state of a package would be set by the PlanAction.Modify to other
than None
Then I guess vc redist would be reinstalled

Just a guess.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detecting-Feature-state-in-Managed-BA-tp7580920p7581261.html
Sent from the wix-users mailing list archive at Nabble.com.

Rob Mensching
2012-10-01 04:12:02 UTC
Permalink
No. Why do you need min-max version restrictions?

Today, if you have multiple Bundles with the same UpgradeCode, the higher
version upgrades the lower versions.

You can also upgrade other Bundle's UpgradeCodes by adding a RelatedBundle
with the Action='upgrade' and the Id='UpgradeCodeOfOtherBundles'.
Technically speaking, the Bundle/@UpgradeCode attribute is just short hand
for the RelatedBundle syntax. That and it is required.
Post by Christian Hausknecht
Hello folks,
is there anything in Burn that provides a possibility to define a minimum
and a maximum bundle version for and upgrade like the <UpgradeVersion>-Tags
in WiX? And if not is there a way to handle a check without writing a
custom BA? Overall what is the exact behavior of a bundle that recognizes
that its version is higher than the one of the installed bundle?
Greetings,
Mit freundlichen Grüßen
Christian Hausknecht
Entwicklung
BeraCom
Beratung und Software-Entwicklung GmbH & Co. KG
Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
http://www.beracom.de
=============================================
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932
Persönlich haftende Gesellschafterin: BeraCom Beratung und
Software-Entwicklung GmbH
Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss
Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt.
Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher
schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist
sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der
Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung
überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für
ihre Richtigkeit.
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually,

Rob Mensching
http://RobMensching.com LLC
Christian Hausknecht
2012-10-01 07:24:15 UTC
Permalink
Ok.

It would be "cool" if you could use a Burn-Package like a Msi-Package and it would know, if it is allowed to perform an upgrade. I have tested yet, that the WiXStBA stops with an error, if one tries to install an older bundle over a newer yet installed one. So I was hoping that you can specify the "allowed" versions in order to get a better failing message. But now it seems to me, that I need a custom BA if I want to achieve that goal?

For our upgrades it could be possible, that a Msi-Package is sufficient - but first of all I am not sure about that yet and on the other hand I am not sure if it is possible to make the full installation via a burn bundle and the upgrades only via a Msi.

As my C# knowledges are not so profound yet, I would like to avoid writing a custom BA...

-----Ursprüngliche Nachricht-----
Von: Rob Mensching [mailto:***@robmensching.com]
Gesendet: Montag, 1. Oktober 2012 06:12
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Burn and Upgrades

No. Why do you need min-max version restrictions?

Today, if you have multiple Bundles with the same UpgradeCode, the higher version upgrades the lower versions.

You can also upgrade other Bundle's UpgradeCodes by adding a RelatedBundle with the Action='upgrade' and the Id='UpgradeCodeOfOtherBundles'.
Post by Christian Hausknecht
Hello folks,
is there anything in Burn that provides a possibility to define a
minimum and a maximum bundle version for and upgrade like the
<UpgradeVersion>-Tags in WiX? And if not is there a way to handle a
check without writing a custom BA? Overall what is the exact behavior
of a bundle that recognizes that its version is higher than the one of the installed bundle?
Greetings,
Mit freundlichen Grüßen
Christian Hausknecht
Entwicklung
BeraCom
Beratung und Software-Entwicklung GmbH & Co. KG Weidestr. 134, 22083
Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
http://www.beracom.de
=============================================
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich
haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung
GmbH Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist
vertraulich und exklusiv für den/die Adressaten bestimmt.
Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit
ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In
jedem Fall ist sicherzustellen, dass keinerlei inhaltliche
Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser
Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein
Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit.
----------------------------------------------------------------------
--------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually,

Rob Mensching
http://RobMensching.com LLC
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sour
Loading...