That has moved to the WixUtilExtension's PermissionEx element. WixCop.exe
should migrate code:
http://robmensching.com/blog/posts/2009/7/7/Tips-on-how-to-upgrade-from-WiX-v2-to-WiX-v3
On Thu, Jan 21, 2010 at 11:38 PM, Sharath P R wrote:
> Hi All,
>What is the alternative for the 'Extended' at
Hello list!
I'm having issues while evaluating WiX for our solutions.
(I've asked before about merge modules but I completely scrapped those.)
Setup:
- using Visual Studio 08 (VS08)
- WiX3 installed incl. VS08 support
C# Solution containing
- BaseLib
- FirstLib (referencing BaseLib)
- Sec
The linker should be providing you a very specific error message pointing at
the line of code that is duplicated. Can you provide that?
Also, make sure you're not sending the same .wixlib into the linker twice
(or more!). That'll duplicate tons of things right away.
On Fri, Jan 22, 2010 at 1:23
Huge thanks... this definitely seems to be a solution, but when i try
use it, i find following problem:
I've 2 features in my wix project:
...
...
"addOnTool" does not get installed during the installation when
conditions are not met. I use following line to install it from main
applicati
Plus @FileSource - this attribute in DirectoryRef really helps to keep
wxs files clean.
But I thought DirectoryRef/@Id and @FileSource are necessary during
compilation of Component elements. And if so, it would be problematic
to handle some situations, where ComponentGroup has ComponentRefs, not
C
Hello All,
I currently have a single WiX solution that creates both 32-bit and 64-bit
MSI's following
http://blogs.msdn.com/astebner/archive/2007/08/09/4317654.aspx Aaron
Stebner's post ; I am passing in a platform property to the WiX script and
building it twice, once for the 32-bit version and
Hi Nick,
I am not sure of this, but maybe u can build a merge module which has a 32
bit component to make whatever registry entries u wish to have. Then u
can give a reference to this 32 bit merge module in your 64 bit installer
code.(using Merge and MergeRef elements).
This way ur 64 bit installer
I had to do a similar thing in my WiX project which builds both x86 and x64
MSIs.
Here is how I did some registry keys that needed to go both registry
sections on x64 sytsems.
Hope that helps.
--
View
Hello!
On Fri, Jan 22, 2010 at 10:44 AM, Rob Mensching wrote:
> Also, make sure you're not sending the same .wixlib into the linker twice
> (or more!). That'll duplicate tons of things right away.
Oh well I guess I handled the VS08 projects in a wrong way...
I figured I had the setup project of
Currently I have some WiX projects that build both an x86 and x64 MSI. Many
of our components contain .NET assemblies that target Any CPU so the fact
that the components differ at all is just to properly support Windows
Installer method of managing x86/x64 components based on the target OS.
Now,
Just upgraded to the latest build of 3.5 (2010 b2) and now my previously
working installer (which now fails for iis7) fails to build with the execption:
The System cannot find the file 'obj\debug\_OneOfMyDllAssemblies.wsx' with type
'source' candle.exe error
Where one of my assemblies has t
Our default installation offers an option (checkbox) on the exit
dialog to log off the user (we need to reset some security thing, I'm
told). However, if during the installation a scenario occurs in which
a reboot is required (files in use, etc.), we don't need to offer that
option, as rebooting h
To help avoid duplication you can also use include files (*.wxi) to define the
registry keys and include it in each component as described below without
having to duplicate the code.
etc.
--
Bryan
From: MikeR [michael.ru...@gmail.com]
S
Note I don't know if this is your scenario or not, but if you are installing
architecture neutral components like .Net assemblies, and are installing them
into the same location regardless of your package architecture (such as the
GAC), then you should make a single Win64="no" component and incl
If you haven't released yet:
The only preprocessor "magic" you would need would be to ensure that your
component's directory lives under a 64-bit directory for 64-bit builds.
If you have released then the above won't work because your guid won't match
whatever you currentl
Turn on verbose logging via the installer logging policy. What are the
values of the feature-related properties? What happens to feature/component
states?
-Original Message-
From: Jan Bilek [mailto:bil...@gmail.com]
Sent: Friday, January 22, 2010 2:47 AM
To: General discussion for Windows
Would a custom action that calls the MsiGetMode() api be acceptable?
-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com]
Sent: Friday, January 22, 2010 7:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Exit dialog text
Our default in
The next build should include a fix for this. If not, let us know.
If you want to fix this in your current build, edit your project file in a text
editor and add "True" under your "
OneOfMyDllAssemblies" ProjectReference.
-Original Message-
From: Will Sullivan [mailto:wsulli...@softdocs
How exactly does the Guid="*" work? I've seen and read this in the WiX SDK
before.
The , , , elements support
auto-generation of GUIDs every time you build your project by specifying a *
in place of the GUID.
The way it reads to me it sounds like the GUID would get randomly changed
every time
How would using MsiGetMode help us?
We can already determine whether or not a reboot is required by
inspecting the REBOOT property, but we'd like to change the default UI
experience in order to accommodate our need for an optional
(suggested) logoff after a "normal" (no reboot required) installati
Hi,
>From my testing, it seems this may not be possible, but I thought I'd
see if anyone can give me a definitive answer.
I have a multi-instance (transforms) installer and when I double-click
the msi, I want to have a custom action pop a window up prompting for a
transform id. After I type a v
For Product, the guid is generated anew each time. Perfect for Major
Upgrades on every build (see Bob's blogs (Joy of Setup) for why that is a
good idea for many projects).
For Component, the guid is a hash of the "full keypath". As such, if the
inputs are stable, the guids will also be stable.
F
In the UI sequence after the Execute action condition a custom action to
change the WIXUI_EXITDIALOGOPTIONALTEXT value if you detect a reboot is
needed.
-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com]
Sent: Friday, January 22, 2010 12:48 PM
To: General discussion for Win
You would need some sort of action that runs after the selection that will
determine if the selected instance is installed. Whether that is
FindRelatedProducts or some CA you write...
-Original Message-
From: Kevin Garman [mailto:gar...@scadaware.com]
Sent: Friday, January 22, 2010 12:58
Thanks for your response... Good questions all... I'm trying to figure out just
what the differences are between the ones that work and the ones that don't.
It's a 32-bit machine and native code. These are third-party components, so I
really don't have much visibility into them.
--- On Fri, 1/2
Hi
I just ran into a problem. I created an MSI that contains two assemblies.
Assembly 1 targets .NET 3.5. Assembly 2 targets .NET 4. Both assemblies are
delay signed. When I build the MSI using WiX 2, I noticed that the
MsiAssemblyName table contains all the information for Assembly 1
(fileVersion
Can you please share the error and track a bug. Interally I think someone
has found the resolve for this issue. If I could get more details I might be
able to help you out.
Thanks,
Brian Rogers
"Intelligence removes complexity." - Me
http://blogs.msdn.com/icumove <-- NEW
On Fri, Jan 22, 2010 at
The new build is out:
http://wix.sourceforge.net/releases/3.5.1322.0/
It should fix the problem, but let me know how it works for you.
-Original Message-
From: Tony Paloma [mailto:apal...@microsoft.com]
Sent: Friday, January 22, 2010 10:44 AM
To: General discussion for Windows Installer
28 matches
Mail list logo
