Hello All.
Considering using WiX to build an installation system for a clients product.
However their file set can change quite dramatically depending on the customer
for whom the installation is meant for - installs are specific to a customer.
They propose to manage this by simply copying only
OK thanks, I think I'm getting there smile
So, I have my MsiPackage for my download...
MsiPackage
SourceFile=..\SharedComponents\bin\Release\SharedComponents.msi
InstallCondition=(ProductAInstalled) OR (ProductBInstalled)
Support for username/password is not available today, you could add it to
the url using something like http://username:passw...@site.com/ (not sure
this work but might be worth trying).
I would point out that it won't be very secure as the contents of the
bundle could be extracted to reveal the
Thanks Neil, I knew security would be an issue / can of worms, but at least I
can now stop looking for something that doesn't exist :)
Cheers again.
--
View this message in context:
You can easily use a HeatDirectory task to achieve what you want. Basically
it will walk the directory tree and create a wix file that you can use in
your project.
On Wed, Apr 10, 2013 at 2:44 AM, Gareth Williams
gar...@trinitydigital.co.uk wrote:
Hello All.
Considering using WiX to build
Is it smart enough to always generate the same guid in the face of the same
file for 'upgrades' etc.?
Seems I have a lot more learning to do.
Thanks
Best regards
Mr. Gareth Williams
Trinity Digital
-Original Message-
From: ptr [mailto:ptrajku...@gmail.com]
Sent: 10 April 2013 13:09
Classification: Public
Yes I know,
However, you are not assigning WHAT values your Radio buttons are..
RadioButton X=17 Y=9 Height=15 Width=291 Text= Trusted (Windows
Authentication) Value=1 / RadioButton X=17 Y=27 Height=15
Width=291 Text= Specify Username and Password (SQL Authentication)
This process will not generate the same GUIDs and other identifiers you need
for patching. It will only generate a unique usable WIX fragment you can
include.
You can use this for upgrades as you do not use component GUIDs as much in the
upgrade process, but if you want to support patches you
Yes wix seems to use some MD5 checksum guid on the relative path of the
file. So if you won't move the file to a different subdirectory the guid
will stay the same
Raj
On Wed, Apr 10, 2013 at 6:26 AM, Gareth Williams
gar...@trinitydigital.co.uk wrote:
Is it smart enough to always generate
That's great - thanks for this info.
Best regards
Mr. Gareth Williams
Trinity Digital
-Original Message-
From: ptr [mailto:ptrajku...@gmail.com]
Sent: 10 April 2013 14:03
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wildcards
Yes wix seems to use
Thanks for responding - I think patches are not probably needed, but full
upgrades as new site layouts for their monitoring system is probably all they
would need.
Best regards
Mr. Gareth Williams
Trinity Digital
-Original Message-
From: Skildum, Mathew
Works on my machine... because I edited the file but forgot to push the
changes. :( I have it in now, ready for the next build. Sorry.
On Mon, Apr 8, 2013 at 10:30 PM, Sean Farrow
sean.far...@seanfarrow.co.ukwrote:
Hi,
It appears that the issue still exists in the 408 build.
I've tried
The GUIDs will only be stable if you use the -ag switch to heat.exe (I
forget the switch in HeatDirectory task to do the same).
On Wed, Apr 10, 2013 at 7:05 AM, Gareth Williams
gar...@trinitydigital.co.uk wrote:
Thanks for responding - I think patches are not probably needed, but full
What about [dirA]. The [$dirA] would be trying to get the directory of
a Component matching that Id, right?
On Mon, Apr 8, 2013 at 4:00 PM, Alain Forget afor...@cmu.edu wrote:
Hi all,
Say we have the following structure:
Directory Id=dirA Name=A
Directory Id=dirB Name=B
Directory Id=dirC
Thanks for the reply. I thought the syntax [dirA] was only for properties.
Does the Directory element also count as (or create) a
property?
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: April 10, 2013 10:38
To: General discussion for Windows Installer XML
I had a whole series of very old blog entries on the directory table. I
think this is one of the later blog posts in the series:
http://blogs.msdn.com/b/robmen/archive/2005/11/04/489346.aspx
Basically Directories are Properties after CostFinalize.
I should turn that series of blog entries into a
The username and password could be stored encrypted in the bundle (when
passwords are supported or in a custom BA).
I've done this in MSIs / custom chainers before with custom actions, also for
persisting credentials in the registry.
Dave
-Original Message-
From: Spud
Indeed, directories are properties.
http://blogs.msdn.com/b/robmen/archive/2006/10/17/deciphering-the-msi-directo
ry-table-part-7-directories-are-properties.aspx
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: 10 April 2013 16:02
To: 'General discussion for Windows
I was able to access the command line paramaters from my managed bootsrapper
suggested to either use extension method or define an inteface IYourCommand
which wrap the Command
This will allow you to create unit tests as well
I implemented something like this
Classification: Public
Be nice for all these nice additions that people are writing themselves into
the WIX burn/bootstrapper engine :) It is all OpenSource :)
Steve
-Original Message-
From: tom [mailto:tomer.d...@intergraph.com]
Sent: April-10-13 1:47 PM
To:
Not sure I understand your comment, did I use inappropriate language?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Accessing-command-line-parameters-tp7585010p7585052.html
Sent from the wix-users mailing list archive at Nabble.com.
Classification: Public
What. no no...
I meant that people are adding cool stuff to the burn/Bootstrapper engine and
it would be nice if it was added into the WIX project so all could be able to
use the cool new features :)
Steve
-Original Message-
From: tom
Yep, confirmed about directories being properties. Thanks...I should have
noticed it in my installer logs as well. Duh.
I no longer need to get just a filename without its full path, but in case I or
someone else wants to do this in the future, how
could it be done?
-Original Message-
GetCommandLineArgs() is a member on the Command struct provided to your BA.
Basically, it was already contributed. smile/
tom is just noting that you can use it.
On Wed, Apr 10, 2013 at 11:11 AM, Steven Ogilvie
steven.ogil...@titus.comwrote:
Classification: Public
What. no no...
I meant
You can use [#ComponentId] to get the directory of the Component containing
the file. It's all laid out here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368609(v=vs.85).aspx
On Wed, Apr 10, 2013 at 11:19 AM, Alain Forget afor...@cmu.edu wrote:
Yep, confirmed about directories
hey all
I have a custom managed boostrapper that installs .NET4 framework as a
prereq. Let's call this OurProductWix.exe.
Now we have old installshied based installers , let's call it
OurProductSheild.exe
Now consider this workflow
1) User has OurProductShield.exe already installed.
2) User
I have associated the Burn Version to the build system as at each build it will
have new version changing the last value 1.0.0.0 = 1.0.0.1To make the new
installer not to add anoter item to the ARP I have attached the event
PlanRelatedBundle and then I have set
e.State = RequestState.Absent;
Yes, that I know, but I *don't* want the directory. I only want the file's
name. For example, say some File element installs a file to
C:/My/Path/To/File.exe, I'd like some formatted string type thing to return
just File.exe.
-Original Message-
From: Rob Mensching
If you get to Apply() then you need to return Result.Cancel from one of the
callbacks before apply phase is complete to cause rollback.
On Wed, Apr 10, 2013 at 2:41 PM, ptr ptrajku...@gmail.com wrote:
hey all
I have a custom managed boostrapper that installs .NET4 framework as a
prereq.
Oh, sorry, misread question. The answer is there is no way to do that. You
already know the file's name so there isn't a way to look it up at runtime.
On Wed, Apr 10, 2013 at 2:51 PM, Alain Forget afor...@cmu.edu wrote:
Yes, that I know, but I *don't* want the directory. I only want the file's
It seems like I need to force a Plan and bail out like you mention.
A simple scenario like this
1) A Custom BA which has a .NET prereq
2) .NET is installed.
3) Customer doesn't agree to our License agreement and hits cancel
It seems like if you simply do a Engine.Quit the bundle is still
That's what I thought. It's too bad that we can't somehow parse out just the
filename from the full path (maybe with some regex?), but I guess it's a pretty
uncommon request that can be bypassed by just setting the file name to a
Property, and referring to that.
-Original Message-
Oh, sorry, it's the pre-req that is registering your product. Yeah, this
case is a little screwy if the user chooses to install the pre-req but then
cancels the actual product install. You actually need to uninstall.
On Wed, Apr 10, 2013 at 3:56 PM, ptr ptrajku...@gmail.com wrote:
It seems
33 matches
Mail list logo
