Hi Everyone.
I'm trying to build an MSI who's only purpose is to run a javascript file.
I'm installing a solution into a sharepoint installation, and all I need the
javascript for is to run stsadm.
I would also like to run another javascript calling stsadm on removal.
So basically I'm trying to
;
> YYY
>
>
> Also, you want Property's Id to be in all uppercase.
> The only time when you need CDATA in condition is when condition text
> includes & > < ' " characters.
>
> Regards,
> Alex
>
>
>
>
> -Original Message---
I'm trying to create a launch condition that makes sure SharePoint is
installed. I thought this was the way to do it:
SharepointRegistry
But this always fails, even though the SharepointRegistry value does get set
before the installation begins, because if SP i
09 at 11:30 AM, Alex Ivanoff wrote:
>
>
>
> -Original Message-----
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Tuesday, February 10, 2009 13:26
> To: wix-users
> Subject: [WiX-users] 64/32 bit builds
>
> I'm trying to build two packages from the s
I'm trying to build two packages from the same set of files - a 64 bit and a
32 bit package.
I'm getting this when trying to build the 64 bit package:
ICE80: This 64BitComponent ProductComponent uses 32BitDirectory
INSTALLLOCATION
The 64 bit executable is going into the same INSTALLLOCATION
Hi all.
I'm trying to build a 32/64 bit wix project file, and part of this is the
need to read a key out of the registry.
I've seen documentation that says to use the "win64='yes/no'" flag, and wix
will allegedly use the appropriate registry key.
However, this doesn't work.
Here is what I have,
pdate since it referenced directly... inserting
> dialogs is much easier.
>
> -Original Message-
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Wednesday, January 28, 2009 14:54
> To: wix-users
> Subject: [WiX-users] Custom Dialogs
>
> I'm
I'm trying to modify the look of the exit dialog, and it seems that the
recommended method is to take the ExitDialog.wxs file and modify it to my
needs.
I'm going off of some on-line web pages I've been able to find that talk
about this, but I'm getting a strange error, and I'm not sure how to pas
I have an MSI file that seems to work perfectly and do exactly what I want.
However, I get two warnings when building it, both relating to shortcuts;
one for the desktop shortcut and one for the menu shortcut.
The warning is this:
c:\Users\colinf\Documents\RMWix\Product.wxs(76): warning LGHT1076:
I'm trying to install my component into the SharePoint directory, the
location of which I find from a registry key.
This works perfectly on a 32 bit system, but on a 64 bit system I can't get
it to work.
Here's what I currently have:
I've tried all 4 combinations of WIn64="ye
some MSBuild syntax to set the
> property you want. I'm not an MSBuild guru so I'm not much more help than
> that. Sorry.
>
>
> -Original Message-
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Wednesday, January 21, 2009 15:52
> To: wix-us
I've asked this before but haven't gotten a solid answer, so I'll try one
more time.
I need to be able to incorporate a modified form of the package version into
the .msi name.
What would be ideal would be the ability to reference the
"!(bind.fileVersion.MyPackageEXE)" as part of the output name,
ade.
> Often times the UpgradeCode in the new package is also set to the same
> value. It basically describes a family of products.
>
>
> -Original Message-
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Tuesday, January 20, 2009 5:06 PM
> To: wix-users
&
Ok, I have two products being installed, each with their own .msi package.
Each product is versioned, and is updated via a major update, which means
removal of old and install of new.
I got this working perfectly on one of my projects, and copied the xml
elements to my other .wxs file.
Unfortuna
I just noticed this at the bottom of section 4.1 in the tutorial:
For some strange reason, small updates and minor upgrades cannot be run
> simply by clicking on the .msi file—they give the error: "Another version
> of this product is already installed." We know, stupid... Anyway, you have
> to s
I am getting some very odd behaviour when trying to test upgrading my
product.
Up until now I've just uninstalled the previous version before installing
the new version. But now I'm trying to actually upgrade, and what I'm
getting is a little bit baffling.
Just to test the upgrade, I'm only chang
acturer="My Software Corp"
>UpgradeCode="ba6c6a55-3a6c-4080-b77a-92aa0efbc67d">
>
>
>
>
>
>
>
> Guid="62a436f8-b2d3-4f10-ae62-dc5616a0d34e">
>
>
That did the trick - Thanks neil!
On Mon, Jan 19, 2009 at 1:18 PM, Neil Sleightholm wrote:
> >> I would be happy with one example.
>
> I use in several
> installs.
>
> I would also point out the file version that MSI uses for replacing
> files and what you see when you right click on a file and
ng on the command line to change the final file name.
Is that possible? If so, how?
Thanks,
Colin
>
>
> -Original Message-
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Monday, January 19, 2009 09:39
> To: General discussion for Windows Installer XML toolset.
&
it belong in a
wixproj instead? If so, then how would the version be set int he .wxs?
Also - thanks Rob for the time you've spent on this. I really appreciate it.
>
> -Original Message-
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Monday, January 19, 2009
asses that into to wix through a
> preprocessor var.
>
> On Tue, Jan 13, 2009 at 6:44 PM, Michael Osmond
> wrote:
> > Colin,
> >
> > You can set an environment variable in the build process and then access
> > that inside wix as $(env.projectVersion)
> >
> &g
fsetup.com]
> Sent: Monday, January 19, 2009 09:26
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Getting the version from the Assembly file
>
> Colin Fox wrote:
> > I'm not sure why you say that this is rare or dangerous.
> >
&
wrote:
> Colin Fox wrote:
> > I'm not sure why you say that this is rare or dangerous.
> >
>
> Because MSI doesn't support changing the .msi package name except by
> major upgrade.
>
2009 at 1:47 PM, Bob Arnson wrote:
> Colin Fox wrote:
> > my_cool_software%24%28filever%29
> >
> > So is variable substitution not allowed in output names? Or is this a
> bug?
> >
>
> It would require explicit support, at least in Votive. As it's
> rare/da
for
output names.
On Fri, Jan 16, 2009 at 11:56 AM, Colin Fox wrote:
> I am using WiX v3, so I'll give this a try. I haven't heard of binder
> variables, so I'll go look them up.
>
> One other issue is that of the msi filename itself. I would really like to
> be
t variable in the build process and then access
> > that inside wix as $(env.projectVersion)
> >
> > Or you can set an Wix variable in the candle command line
> >"candle -dMyProject.Version="
> >
> > Michael
> >
> > -Original Message--
don't see many people
> putting the version number in the MSI name. Not a common request thus not
> necessarily simple to implement.
>
> -----Original Message-
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Tuesday, January 13, 2009 14:36
> To: wix-users
>
As an addendum to this issue: I'm installing a web service, and it needs to
be installable on both 64 bit and 32 bit systems.
Is it possible to build a wix that will install into both, or do I need to
build separate wix install projects?
Thanks,
cf
On Tue, Jan 13, 2009 at 3:03 PM, Rob Mensch
Hi everyone.
I'd like go be able to set the version of my application in the assembly.cs
file, and have it used in both the wix file and also in the wix file name.
So if my app is version 1.2.3, I'd like the .msi file to be called
"MyAmazingApp_1_2_3.msi" or something equivalent.
I've seen some
On Thu, Jan 8, 2009 at 8:40 PM, Curtis Jewell <
lists.wix-us...@csjewell.fastmail.us> wrote:
>
>
> >
> >
> > http://schemas.microsoft.com/wix/2006/wi";>
> >
>
> >
> >
> >
> >
>
> ...
> ...
>
> Add the line incorporated above after the (an
gt; might do what you want.
>
> Neil
>
> -Original Message-----
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: 08 January 2009 23:45
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Skipping License Page and Zipping a Folder
On Thu, Jan 8, 2009 at 11:37 AM, Bob Arnson wrote:
> Colin Fox wrote:
> > First - The fragment file that Heat produces has absolute paths for all
> the
> > file references, which is unacceptable in a multi-developer project. This
> > directory is going to change maybe on
On Thu, Jan 8, 2009 at 10:10 AM, DEÃK JAHN, Gábor wrote:
> On Wed, 7 Jan 2009 15:02:44 -0800, Colin Fox wrote:
>
> Colin,
>
> > I'm unaware of any limitations of CAB files that would get in my
> > way. My understanding of my problem is that WiX doesn't
;
> 1. Dialogs are completely yours to author. If you don't like the
> built-ins, don't use them or take them apart to use only the parts you need.
>
>
> 2. .zip files don't provide the transaction semantics the Windows
> Installer provides. That's why it is
e. I
> encourage you to go back through the archives looking at the topics around
> component rules.
>
Ok, will do - where can I find these archives?
Thanks,
cf
>
> -----Original Message-
> From: Colin Fox [mailto:greenene...@gmail.com]
> Sent: Wednesday, Januar
to add a tag as part of a component, but something
like this would be ideal:
But I can't include a tag within a component.
This seems like something that would be generally useful. Is there a
built-in way to do this?
Regards,
cf
> -Original Message-
> From:
Hey everyone - I have two quick questions.
First - is there a simple way to get the installer to NOT show a license
page? I kind of hacked a solution by programming the Next button to go to
the directory chooser, but this feels hacky. Can I just say "I don't want to
show a clickwrap license"?
Sec
On Tue, Dec 23, 2008 at 11:30 AM, Alexander Shevchuk <
alexander.shevc...@microsoft.com> wrote:
> Your custom action is type 51 (set property with a formatted text). You
> need type 35 (set directory with a formatted text). Review my first email
> for correct format.
>
> Alex
>
>
Actually, it tu
On Tue, Dec 23, 2008 at 11:19 AM, Alexander Shevchuk <
alexander.shevc...@microsoft.com> wrote:
> Also, regarding registry search.
> The way how your RegistrySearch is provided - you are looking for a *value*
> SharePoint under SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\. Is that
> what you
On Tue, Dec 23, 2008 at 10:55 AM, Alexander Shevchuk <
alexander.shevc...@microsoft.com> wrote:
> Hi Colin,
>
> Try this:
>
> - Use AppSearch to set the value of public property, say - SHAREPOINT
>
>
>
>
>
> - Schedule custom action type 35:
>
> Value="[SHAREPOINT]" />
>
>
> NOT Installed
>
On Tue, Dec 23, 2008 at 10:48 AM, Scott Sam wrote:
> Are you sure that the registry key that you are looking for exists on
> the target machine?
>
Absolutely. I'm trying to install this on my own machine, and I can see the
registry key with regedit.
--
Regards,
cf
---
I'm still having no luck setting the location of my install based on a
registry key.
I've tried all the suggestions but nothing works. And there is definitely an
AppSearch segment in my .msi file.
I've done the steps from the tutorial but they're apparently insufficient.
Also - when I check my l
On Mon, Dec 22, 2008 at 11:51 PM, Bob Arnson wrote:
> Jim Williams wrote:
> >
> >
> >
> >
> >
> >
> >
>
> WiX automatically schedules AppSearch if you have any *Search elements.
> Colin, are you using any Fragments in your setup authoring? Open your
> .msi with Orca and verify that
ything in there to help. All it says is that INSTALLDIR gets set to D:\ -
no mention of my registry search at all.
I don't know what AppSearch is, or what the InstallExecute sequence is. I
haven't seen any mention of those in the examples or tutorials.
>
> -Original Mes
I really hate to be a broken record, but there is only one issue stopping me
from getting my installer working.
I just need to be able to read a location out of a registry key and then
store 3 files there.
None of the examples really fit the bill, and the one example linked to in
the big tutorial
On Mon, Dec 22, 2008 at 4:49 PM, Colin Fox wrote:
>
>
> There is an example referenced in the tutorial that does just about the
> same thing, though he's going based on the location of the .ini file. But he
> sets the INSTALLDIR property the same way (just before the 3 nested
On Mon, Dec 22, 2008 at 4:09 PM, Bob Arnson wrote:
> Colin Fox wrote:
> > I can grab the SharePoint location out of the registry, but for the life
> of
> > me I just can't seem to get that set as the TARGETDIR. TARGETDIR always
> just
> > gets reset to D:\.
&
t/plain; charset=windows-1252; format=flowed
>
> Colin Fox wrote:
> > But TARGETDIR and SourceDir are not explained. There is no explanation as
> to
> > where they are initially set, or why the ID of the directory is
> "TARGETDIR"
> >
>
> Because that&#x
Hi everyone. I've been going over the docs and examples for about a week
now, and I have some fundamental questions that I really need some direction
on.
First off – the tutorial at http://www.tramontana.co.hu/wix is great, but
he glosses over a lot of stuff without explaining details, and the sc
49 matches
Mail list logo
