it giveses you the Package Id. The Package Id defaults to the name of the
package if you don't specify it.
On Wed, Oct 24, 2012 at 8:15 AM, Hans ter Horst wrote:
> Oops, sorry, I think it works fine. I expected to find the PackageGroup Id
> string, but instead it games me the last part of the So
Heat simply calls the ::DllRegisterServer() entry point and captures the
data. The DLL must be writing different values on different OSs.
On Wed, Oct 24, 2012 at 9:59 AM, john.burak wrote:
> Hi,
>
> We recently automated Heat on our COM-registered libraries. I ran it on
> the
> same DLLs on a 6
Nothing supported natively in WiX toolset.
On Wed, Oct 24, 2012 at 5:44 PM, Johann A. Hough <
joh...@silverskysoftware.com.au> wrote:
> Thanks Peter, good to know.
>
> I however re-use the $(var.VERSION) variable in quite a few other places
> like directories, shortcuts, websites, etc. and find t
I’ve been using WiX for a few years. I have a question that’s about
installation but not strictly about WiX. But this is the only forum I know
dealing with installation on Windows. If this is out of place please feel
free to redirect me elsewhere, I’d appreciate it.
My company currently has Prod
Hi,
I have a windows service project called MyExe.exe, which takes arguments to its
Main method.
I created below wix installer project to install my service using
ServiceInstall below, everything works fine.
What I want to accomplish now is do something on the uninstall of this service.
Is the
Thanks Peter, good to know.
I however re-use the $(var.VERSION) variable in quite a few other places like
directories, shortcuts, websites, etc. and find that have four are excessive,
so I'm trying to see if there is a simple way to reduce it to 3 or even 2 for
those usages.
Any ideas?
-O
Thanks Narina!
Just for future new WiXers, I ended up modifying the wxs as follows:
And
Much appreciated,
Filip
-Original Message-
From: Narina, Chandra [mailto:chandra.nar...@wolterskluwer.com]
Sent: Wednesday, October 24, 2012 2:34 PM
To: General discussion for Windows Ins
I have a custom action:
NOT Installed
if execute=immediate runs before it should BUT the MSI properties are read
in by my customaction dll, however it fails since the files haven't been
installed yet :(
If I set the execute=deferred it runs when it is supposed to BUT the
properties
Try adding Sequence="ui" to your SetProperty element. I can't remember if
AppSearch is executed twice. The next question would be how would you allow a
user to override this when installing with no UI, which I would suggest using
the "remember me property pattern" Rob had blogged about a while
Thanks everyone, finally got this working.
There were several mistakes from syntax error to using the right property name.
I had something like this in my wix project for all properties
My first mistake was assigning custom value from cmd to WIXUI_LABNAME, instead
you should assign it to LABNAM
If I use the following then the value specified by the user does get used.
So, I assume it somehow is related to using
but I'm not sure how.
Any suggestions are most welcome.
Regards
Gavin
On Thu, Oct 25, 2012 at 5:20 AM, Phil Wilson wrote:
> It's hard to be specific, but it loo
Hi,
Use Directory attribute instead of property. (it's a Type 35 Custom
Action) and Schedule this action after InstallValidate in the Execute
sequence - that's when directories are checked for write access and
truly set.
Something like this...
Thanks & Regards
Narina Chandra Sekhar
-Ori
NOOB Alert: I have been learning the ins and outs of WiX for appoximately a
day. I am having problems setting the TARGETDIR path. I used dark.exe to
reverse engineer a working MSI and read any posts I could find on this subject
but I seem to be unable to set the TARGETDIR to point to the path
It's hard to be specific, but it looks like the dialog you're using with its
BrowseFolder result is not propagating the user input to TARGETDIR or
INSTALLFOLDER.
Phil W
-Original Message-
From: Gavin Bray [mailto:gavb...@gmail.com]
Sent: Tuesday, October 23, 2012 11:29 PM
To: wix-user
There are some things you can do based around the MsiSourceListAddSource ()
function (and scripting equivalents) that let you define alternate paths to
locate the MSI that Windows requires. So you can put it on a network server
and then tell Windows to look there for repair (or adding features etc)
I have a deferred custom action in a merge module that is a call to a C#
customaction dll I created, but I want it to be quiet so I did this:
CA: Setting
CustomAction to configure the connection strings for
Web.config...
CA:
Configuring the connection strings f
You guys all rock. The latest version worked perfectly. I should of thought
of that. Thanks for all your quick responses and help.
Thanks Jacob for the info.
Definitely owe you guys a drink if you are ever in Canada LOL
Richard Compton
On Oct 24, 2012 12:11 PM, "Hoover, Jacob"
wrote:
> That is
That is where Wix caches packages if you have told the bundle to save them for
later offline or without a CD reinstall/repair/uninstall operations. I have a
feeling that your bundle left some files behind during a previous uninstall.
If you were using a VM, I'd tell you to revert to a clean sta
Just trying the latest WIX to see if that helps.
What exactly am I looking for in the Program Cache. On my test machine
(where the installer works) I see some folders with my msi in them. Is
that normal? Other folders have a data folder in them? What should I
see? What should I not see?
T
Hi,
We recently automated Heat on our COM-registered libraries. I ran it on the
same DLLs on a 64-bit machine and a 32-bit machine and noticed a couple
differences in the .wxs output. Heat on the 32-bit machine added
ProxyStubClassId32 attributes to the elements, and added
ThreadingModel="apart
If you check in %ProgramData%\PackageCache, are there any sub folders? It may
be as Neil suggested that you are using an outdated version (non-stable
release).
-Original Message-
From: Richard Compton [mailto:rich.comp...@curvedental.com]
Sent: Wednesday, October 24, 2012 10:58 AM
To:
Will try that thanks.
We have narrowed it down to what I think is a bootstrapper (Bindle)
problem. We have a Bundle that will check for a few pre-requisites,
download and install them then finally install the main msi. I run the
main msi alone and all goes well.
Not sure if that helps.
*Ri
Thanks for the quick response.
It is a clean enough machine. Our product is not on this machine. As
far as I can tell no related bundles to our product are there. How
would I find this out? Just by scrolling through the programs
installed? How do I check this file you speak of? Or the pack
Might not matter but would suggest using the release version of WiX v3.6.3303
yours is quite old.
Neil
-Original Message-
From: Richard Compton [mailto:rich.comp...@curvedental.com]
Sent: 24 October 2012 15:41
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix problems
I have
Is this a clean machine or did you have the bundle on it before? Are there any
related bundles already on the machine? Just a gut feel tells me there will be
a bundle in the package cache and possibly the state data file is corrupt.
(There is a file alongside the bundle in the package cache whi
I have an installer that we are currently using. I am using a
Bootstrapper. When I click on the installer it does nothing. The log
file shows the following.
[0690:1054][2012-10-24T08:43:02]: Burn v3.6.2221.0, path:
C:\Users\Owner6\Desktop\CurveImage-1_2_0-live.exe, cmdline: ''
[0690:1054][20
You can use a 4 field version for a product. Windows stores but ignores the
final field.
-Original Message-
From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au]
Sent: 24 October 2012 16:44
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Product Version via (bind.FileVer
Hi All
I'm using the approach of defining a variable for the product version which is
bound from one of the assemblies.
This ends up as a number like "1.0.0.0" - how can I strip this down to "1.0.0"?
Thanks,
Johann
--
Rob,
From http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset, you
hinted at 3.7 being a very short release cycle. I'm very interested in the
build system improvements but was wondering if you had even a rough estimate of
when you plan to have 3.7 in a RC.
Thanks,
Jacob
Oops, sorry, I think it works fine. I expected to find the PackageGroup Id
string, but instead it games me the last part of the SourceFile of the
MsiPackage or ExePacke, which is absolutely fine.
Hans
On Wed, Oct 24, 2012 at 3:26 PM, Hans ter Horst wrote:
> Hello,
> I would like to know the ind
Hello,
I would like to know the individual names of the packages installed and one
of the first things I do is to register the event handlers:
this.Bootstrapper.ApplyComplete += this.OnApplyComplete;
this.Bootstrapper.DetectPackageComplete +=
this.OnDetectPackageComplete;
Hi Christian,
If it was up to me, I would gladly open-source it, I think I too would
benefit from other people's ideas, since I'm not really an expert in the
Win Installer field. This bootstrapper thing is just a side project I'm
working on. Anyway, if you or anyone else on this list have any ques
Hello,
I have the following question: What can I do, that the repair function works
from the "add or remove programs" panel, or from the same MSI?
If the MSI package was installed via msiexec /qn /I ".msi", the
MSI searches for the original package only in the folder , not
where the operating s
33 matches
Mail list logo
