Interesting, I was able to get it to work by simply removing the Win64
attribute altogether. I swear I tried this before and it didn't work...
Just needed a nights sleep I guess.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/util-RegistrySearch-
http://stackoverflow.com/questions/22559113/utilregistrysearch-registry-key-not-found-when-using-variable-inside-win64
Am I doing something wrong?
Thanks,
-dirt
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/util-RegistrySearch-Registry-key-not
Variables.wxi).
http://eldirte.blogspot.com/2013/10/visual-studio-pre-build-event-scripts.html
Hope this helps.
-dirt
On 2013-10-23 17:28, victorwhiskey wrote:
> Currently I'm using
>
> Version = !(bind.FileVersion.fil1241xxx)
>
> to bind the file version number to my MSI, wher
I was able to resolve this by changing
WixBA.Plan(LaunchAction.UpdateReplace) to
WixBA.Plan(LaunchAction.Install) per
http://stackoverflow.com/questions/17676657/wix-burn-bootstrapper-majorupgrade
On 2013-10-15 08:32, dirt wrote:
> Well, it's back. My first upgrade test didn't ha
Well, it's back. My first upgrade test didn't have any Errors, now my
subsequent tests have the 'Invalid package type' error below.
What causes this?
Thanks,
-dirt
On 2013-10-15 08:17, dirt wrote:
> I was able to resolve this by re-installing the new weekly buil
I was able to resolve this by re-installing the new weekly build
released last night (v3.8.1014.0).
On 2013-10-14 18:11, dirt wrote:
> I apparently made too many changes at once and now when I try to
> install an updated version of the bootstrapper I get 'Invalid pac
roduct.wxs:
=
Thanks,
-dirt
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Invalid-package-type-tp7589708.html
Sent from the wix-users mailing list archive at
s" property but nothing changes.
=Details=
v1.0.73 Installed. Exists: C:\ProgramData\Package
Cache\{971e0d36-1c42-4eca-a6ee-4804edcc83eb}\MyApp.exe
v1.0.73 Change, Update v1.0.74 Launched:
This gets created, but is empty: C:\Users\dirt\AppData\Local\Package
Cache\{971e0d36-1c42-4e
ething
in the registry at the shutdown of v1 that v2 reads to know that it
should automatically continue to the Install portion.
Thanks,
-dirt
On 2013-10-11 15:58, dirt wrote:
> How am I to detect that the bootstrapper has been invoked via an
> Update
> and thus should suppress t
he bootstrapper and MyApp
are detected as Absent and it sits at the UI waiting for you to click
Install.
Thanks,
-dirt
On 2013-10-11 11:57, dirt wrote:
> Thank you for the clarification.
>
> I have made progress and here is an updated scenario, I am not sure
> why
> the update is not
would rank them 3rd.
If you would like to try digitialocean I have a referral code :)
Sorry if this is taken in any other way than my 2 cents.
-dirt
On 2013-10-11 13:23, Rob Mensching wrote:
> The site was down for a bit this morning.
>
> FYI: We are investigating new hosting locat
ick Install.***
3) Click Install: Installs MyApp
v1.0.2 is installed successfully
v1.0.1 ui is opened again automatically (this time appears to be
hidden)
4) v1.0.2 UI shows as Complete.
Add/Remove programs shows new v1.0.2 is installed.
=
Thanks,
-dirt
On 2013-10-10 19:08, Phill Hogland wrote
logs show update
successfull then exit why v2 doesnt appear to be installed and b) why v2
is opened after v1 exits - shouldn't the install be seamless?
Thank you,
-dirt
--
October Webinars: Code for Performan
the bootstrapper (providing the guid match and version has been
incremented?)
Otherwise, I would look in the log files in your %TEMP% folder to see
what your exe installation is producing.
-dirt
On 2013-10-10 12:46, rw1017 wrote:
> Hey all!
> I'm trying to step through the code du
I've stepped through my code using breakpoints but I fail to see why
the UpdateCommand does not seem to be enabled when this.UpdateEnabled ==
true.
UpdateViewModel sets State = Initializing
DetectUpdateBegin is fired setting State = Checking
this.RaisePropertyChanged(() => this.State); ===
I'm not sure if this applies here but I am using %~dp0 to get the
current path in a cmd script used by the bootstrapper:
More info:
http://stackoverflow.com/questions/5034076/what-does-dp0-mean-and-how-does-it-work
On 2013-10-09 11:49, Phil Wilson wrote:
> And DATABASE is not a documented prop
I am using the WiX Source\Setup\WixBA as a starting point for a custom
managed bootstrapper application.
I am trying to wrap my head around how the UpdateCommand works but I
don't even see the DetectUpdateBegin method get fired.
I see the DetectComplete method get fired but that just goes strai
Ok I was able to get the actual Exception by surrounding it with a try/catch
(duh!) and the issue has nothing to do with WiX, I failed to run
ParseClient.Initialize before trying to query Parse.
/closed
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.
Results = await
query.FindAsync();
return parseResults;
}
}
...
TempLog:
MSI (c) (0C:BC) [09:24:13:569]: Doing action: LicenseCheckAction
Action 9:24:13: LicenseCheckAction.
Action start 9:24:13: LicenseCheckAction.
MSI (c) (0C:04) [09:24:13:591]: Invok
Recycle the appPool!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wixtoolset-org-reporting-503-service-unavailable-tp7589445p7589446.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Oh I have Product Id="*"... whoops. I had that confused with UpgradeCode.
http://stackoverflow.com/a/10331773/1992193
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-not-detecting-MsiPackage-as-Present-when-already-installed-tp7589349
I was able to figure it out using DefineConstants in a BeforeBuild event to
get the version of the project file and set it as a variable to be used in
Bundle Version:
Bundle.wxs:
BuildVersion=%(AssemblyVersion.Version)
So I figured out at least why the FileVersion.FileID isnt working as the
FileID is declared in the 'Setup' project and this is the 'Bootstrapper'
project.
I still don't understand why *!(bind.packageVersion.MyApp)* results in
*1.0.0.0* when the MyApp Project *AssemblyVersion *is set to *1.0.**
Hello,
Thank you for the quick reply!
Can I not combine the WixBalExtensionExt and Custom/Managed
BootstrapperApplication?
Thanks,
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Error-LGHT0094-Unresolved-reference-to-symbol-WixBootstrapperAppli
am Files (x86)\WiX Toolset v3.7\bin\Heat.exe dir
..\MyApp\bin\Debug\ -cg MyApp_Project -dr INSTALLLOCATION -scom -sreg -srd
-gg -sfrag -out MyApp_Files.wxs7> C:\Program Files (x86)\WiX Toolset
v3.7\bin\candle.exe -dDebug -d"DevEnvDir=C:\Program Files (x86)\Microsoft
Visual Studio 11.0\Common7\ID
25 matches
Mail list logo
