Previous message formatting was totally off so a retry and hopefully this one
is better ;)
I didn't find a fix for it at the time sadly enough and to be honest I don't
really know anymore what I was trying to achieve. I just tried something with
Wix 3.10 and I couldn't get it to crash with tha
I didn't find a fix for it at the time sadly enough and to be honest I don't
really know anymore what I was trying to achieve.
I just tried something with Wix 3.10 and I couldn't get it to crash with that
code in My custom action..
Running the CA know with that code yields the following table
Did you ever work this out I have the same problem and a morning of googling
has got me know where.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-TableCollection-tp6180281p7599767.html
Sent from the wix-users mailing list archive at
Thank you all for suggestions! Truly appreciate all the help.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-built-for-AnyCPU-does-not-read-64-bit-registry-hive-tp7598754p7598793.html
Sent from the wix-users mailing list archive at
at build time, IIRC.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: wixtester [mailto:sangee...@hotmail.com]
Sent: Wednesday, January 7, 2015 6:49 PM
To: wix-users@lists.sourceforge.net
Sub
You should be building separate MSIs for both arcitectures:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
so build an x86 Dll for 32-bit systems and an x64 Dll for 64-bit.
In any case, AnyCpu for a Dll actually means
Regarding the comments about using "AnyCPU" this blog explains one reason why
on a x64 system AnyCPU runs a 32 bit instance of .Net
http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
--
View this message in context:
http://windows-installe
nc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: Daniel Norman [mailto:daniel.nor...@snowsoftware.com]
Sent: Thursday, January 8, 2015 6:55 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] CustomAction built for AnyCPU does not
@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction built for AnyCPU does not read 64-bit
registry hive
I may have not been clear in my earlier emails, sorry about that.
I have a C# custom action that uses Microsoft.Win32.RegistryKey. I am building
this custom action with AnyCPU. The custom action
I may have not been clear in my earlier emails, sorry about that.
I have a C# custom action that uses Microsoft.Win32.RegistryKey. I am
building this custom action with AnyCPU. The custom action searches for JRE
on the system and set a value to Session variable. I have 64-bit JRE
installed on the
Sorry, for the short response. I have done it by setting conditions. x86 vs
x64.Per Rob's blog, check this out
http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/block_install_on_os.html
and (it is also linked) http://msdn.microsoft.com/library/aa370556.aspx
I
Defer it?
On Wed, Jan 7, 2015 at 8:49 PM, wixtester wrote:
>
> The CustomAction does not permit "Win64" attribute for a managed custom
> action
>
> BinaryKey='provisionCA' DllEntry='SearchJRE' Execute="immediate"
> Return="check" Win64="yes"/>
>
>
> Error message
>
> error
The CustomAction does not permit "Win64" attribute for a managed custom
action
Error message
error CNDL0037: The CustomAction/@Win64 attribute can only be specified
with one of the following attributes:Script, VBScriptCall, or JScriptCall
present.
Note: I am using mana
See the CustomAction/@Win64 attribute.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: wixtester [mailto:sangee...@hotmail.com]
Sent: Wednesday, January 7, 2015 1
lset.
Subject: Re: [WiX-users] CustomAction to run powershell script
Also the PropCA must run before the UpdateIdentityCA in the Installexecute
sequence.
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Tuesday, December 16, 2014 12:59 PM
To: Gen
Also the PropCA must run before the UpdateIdentityCA in the Installexecute
sequence.
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Tuesday, December 16, 2014 12:59 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] CustomAction
Did you add the Execute="immediate" to the CustomAction "PropCA"?
-Original Message-
From: wixtester [mailto:sangee...@hotmail.com]
Sent: Tuesday, December 16, 2014 12:51 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction to run powershell
The quotes look good, my bad!
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Tuesday, December 16, 2014 12:35 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] CustomAction to run powershell script
The above CA has a
Thanks for pointing out the missing quote. After fixing that, I am still not
able to run the ps script. Also, I am now enclosing the quotes around the
file path like this -
-File "C:\Program Files (x86)\\Bridge
Server\Bridges\Exchange\UpdateIdentity.ps1 " testhub\ericd pwd1
Why is WixCA not
The above CA has a " missing and Execute="immediate" property missing.
--Pavan
-Original Message-
From: wixtester [mailto:sangee...@hotmail.com]
Sent: Tuesday, December 16, 2014 12:14 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CustomAction to run powershell script
ember 17, 2014 5:13 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] CustomAction to execute batch file causes uninstall to
fail
Phil is right. Just add this to the custom action sequence:
--
Phil is right. Just add this to the custom action sequence:
-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Wednesday, September 17, 2014 4:16 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] CustomAction to execute batch file causes
You're referring to it as an "install" custom action, but I see no
condition that causes it to be called only on install. In other words
it's also being called at uninstall time and failing.
---
Phil Wilson
On Wed, Sep 17, 2014 at 4:08 PM, newuser2014 wrote:
> Hi,
>
> I have a custom
I do not know, but what is the requestedExecutionLevel in the manifest for
'MyExe'?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-elevated-not-working-tp7592486p7592489.html
Sent from the wix-users mailing list archive at Nabble.com.
Hello Rob,
My guess is that running the MSI from an elevated bootstrapper (not
burn) causes the issue. I now use to force the
folders to be writeable for "Users". Probably a better approach than
relying on the installing user.
Theo
Op 23-4-2013 1:24, Rob Mensching schreef:
> Did you ever get th
Did you ever get this sorted out?
On Tue, Apr 9, 2013 at 5:57 AM, Theo Landman wrote:
> Hello,
> I'm confused about how Impersonate works. I want to run a console
> migration executable using the WiX CAQuitExec. The migration executable
> copies files from a previous version of the product to a
On 21-Feb-13 09:13, Gabriel Ivanes wrote:
> Anyone knows why does the bit FirstSequence automatically set Rollback's
> bit ?
> The same with OncePerProcess and Commit.
Because they're the same bits. msidbCustomActionTypeFirstSequence and
msidbCustomActionTypeOncePerProcess are only valid for immed
No you need to know the name of the standard or custom action that you want
it to run after or before.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-not-running-tp7263897p7269311.html
Sent from the wix-users mailing list archive at Nab
...@hyland.com]
Sent: February 8, 2012 8:19 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction not running
Well, for DLLs it is pretty easy because you can use heat.exe to generate the
authoring for you. However, it doesn't handle EXEs.
See this thread for more de
-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com]
Sent: February 8, 2012 8:19 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction not running
Well, for DLLs it is pretty easy because you can use heat.exe to generate the
authoring for you. Howe
Well, for DLLs it is pretty easy because you can use heat.exe to generate the
authoring for you. However, it doesn't handle EXEs.
See this thread for more details:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-and-COM-executable-registry-extraction-td1308713.html
http://windo
rom: jhennessey [mailto:jack.hennes...@hyland.com]
Sent: February 8, 2012 7:56 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction not running
Disclaimer: As you probably know, it is a bad practice to register files this
way during installation. The preferred way is to au
Disclaimer: As you probably know, it is a bad practice to register files this
way during installation. The preferred way is to author the actual registry
values that get written during registration.
Ignoring the disclaimer, you shouldn't rely on using the value of the
ADDLOCAL property. Instead, u
My second installer is not MSI installer, it is old VisualBasic Installer
that can run parallely with my MSI.
So the sollution is not in that.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-another-installer-not-working-tp6969663p697339
Running an installer from within an installer is not supported. The msiexec
processes that are already running are going to block the "inner" install. To
achieve the effect of what you want, you'll need to use a chaining bootstrapper
like burn, DotNetInstaller, or something similar.
--
John M
On 27-Apr-11 03:06, Rune Moberg wrote:
> A little googling seems to suggest that the proper way to do this
> would be by using a deferred action. If I understand this correctly,
> the deferred action will be executed by the installer service and has
> a good chance of running elevated. Fine, except
On Mon, Apr 25, 2011 at 1:56 AM, Bob Arnson wrote:
> Deferred custom actions can only get a couple of system properties. To
> get any other properties (public or not), you need an immediate CA that
> writes CustomActionData for the deferred CA.
Funnily enough, this played straight into what I am
On Tue, Apr 26, 2011 at 6:26 AM, Blair wrote:
> Depends on when your custom action is scheduled. Can you describe in more
> detail what you are trying to achieve?
My installer installs an empty database.
On upgrade, I need to call a stored procedure on said database. My
plan was to have a custom
Depends on when your custom action is scheduled. Can you describe in more
detail what you are trying to achieve?
Blair
-Original Message-
From: Rune Moberg [mailto:jjfl...@gmail.com]
Sent: Saturday, April 23, 2011 1:18 PM
To: General discussion for Windows Installer XML toolset.
Subject:
On 23-Apr-11 20:33, Aaron Klor wrote:
> a similar manner. If the CA is deferred, (again, unless I'm mistaken) you'll
> only have access public properties (directory ids and such defined in
> ALLCAPS), but you should be able to get the paths you need.
Deferred custom actions can only get a couple o
Unless I misunderstand your question, you should be able to get it easily by
using [directoryid] (e.g. the ConfigurableDirectory of the feature) or
[#fileid] as input parameters to your CA. From within an immediate custom
action, you should be able to read the properties from the session object in
Thanks will post questions there. :-)
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-fails-with-error-code-1603-tp6000977p6009679.html
Sent from the wix-users mailing list archive at Nabble.com.
---
users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction fails with error code 1603??
Thanks Neil!
Following is code from my config file for dotNetInstaller:
Its giving error "failed to install SQL Server 2008". I have checked the
comma
Thanks Neil!
Following is code from my config file for dotNetInstaller:
Its giving error "failed to install SQL Server 2008". I have checked the
command line and its working fine.
I have 2 more questions:
1. Here Mysitesetup.msi is my mai
-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction fails with error code 1603??
Thanks for th reply Neil.
If possible can you please provide an example of the configuration file
used with dotNEtInstaller that checks if SQL Server is installed or not
and if not available installs
Thanks for th reply Neil.
If possible can you please provide an example of the configuration file used
with dotNEtInstaller that checks if SQL Server is installed or not and if
not available installs it?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.
No a bootstrapper runs the SQL install and then your install.
Neil
-Original Message-
From: kim [mailto:contactme...@gmail.com]
Sent: 07 February 2011 18:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction fails with error code 1603??
Thanks so much for the
Thanks so much for the suggestions guys :-)
I will definitly look at the dotNetInstaller bootstapper.
Please correct me if I have misunderstood:
I can still call this bootstrapper from my msi, which will install all the
prerequisites and once all is successful, my msi can resume with
installat
You should build / use a bootstrapper for this.
Installing other MSI files from within a CA (especially managed ones) are a
scenario for deasaster (As far as I have seen at least) and are highly
discouraged!
Check out if you can use Burn; I have good hopes for it, although I haven't
found the time
It is not possible to install SQLExpress from within an MSI as nested
installs are not supported by Windows Installer, you will need to use
some sort of bootstrapper. I use dotNetInstaller
(http://dotnetinstaller.codeplex.com/) to do this.
Neil
-Original Message-
From: kim [mailto:contact
Yes.
On Fri, Jan 28, 2011 at 1:34 AM, Rune Moberg wrote:
> On Thu, Jan 27, 2011 at 5:09 PM, Rob Mensching
> wrote:
> > IIRC, a Commit Custom Action *always* runs at the end of the install.
>
> After all files have been removed..?
>
> --
> Rune
>
>
>
On Thu, Jan 27, 2011 at 5:09 PM, Rob Mensching wrote:
> IIRC, a Commit Custom Action *always* runs at the end of the install.
After all files have been removed..?
--
Rune
--
Special Offer-- Download ArcSight Logger for
IIRC, a Commit Custom Action *always* runs at the end of the install.
On Thu, Jan 27, 2011 at 6:16 AM, Rune Moberg wrote:
> FileKey="MM3ServerExe" Return="ignore"/>
>
> REMOVE ~=
> "ALL"
>
>
> In the log file I see this:
>
> MSI (s) (84:D0) [15:01:37:844]: Note: 1: 2205 2: 3: A
You can't log or, IIRC, launch other dialogs from a custom action activated
by a DoAction. MSI limitation.
On Tue, Aug 17, 2010 at 12:16 PM, Umesh Joglekar wrote:
>
>
> Hi,
>
> I have a custom action executable written in c++. This pops up the browser
> to the appropriate download link for a pre
On 30-Aug-10 12:41, alexander.nevs...@acronis.com wrote:
> Of course, there is no custom action "[CustomSerialValidateProp]". But
> property CustomSerialValidateProp contains actual custom action.
As in VBScript or JScript? It looks like that's not supported. Feel free
to file a bug -- and get
On 8/11/2010 11:34 AM, Christian Tusch wrote:
> Yes, I'm using WixUI_InstallDir.
Are you running the install with UI? Check out a verbose log to see what
MSI planned.
--
sig://boB
http://joyofsetup.com/
--
This SF.n
Yes, I'm using WixUI_InstallDir.
On 7 August 2010 16:55, Bob Arnson wrote:
> On 8/5/2010 5:50 AM, Christian Tusch wrote:
>> could anybody tell me why this won't show me a message box?
>>
>
> Do you have a full UI in your package? Silent installations don't show UI.
>
> --
> sig://boB
> http://joy
On 8/5/2010 5:50 AM, Christian Tusch wrote:
> could anybody tell me why this won't show me a message box?
>
Do you have a full UI in your package? Silent installations don't show UI.
--
sig://boB
http://joyofsetup.com/
---
"asyncWait" means start the action and move on with the sequence, but don't
let the entire installation transaction end until the action has ended. I
think you want "check", which would not let the sequence continue with the
next action until your action ends.
-Original Message-
From: Jere
mailto:s...@noida.interrasystems.com]
Sent: 29 June 2010 06:15
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] CustomAction on Uninstall but not upgrade
use condition
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
cge wrote:
> I have a custom action
use condition
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
cge wrote:
> I have a custom action that should only run on uninstall, but not run during
> an upgrade. After browsing the list archives and other sites, I came up with
> the following:
>
>After='MsiUnpublishAssemblies'>Installed
Looks like this is the ticket:
Installed AND REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-on-Uninstall-but-not-upgrade-tp5232029p5232458.html
Sent from the wix-users mailing list archive at
Yes, I can see in my log where UPGRADINGPRODUCTCODE and UPGRADEFOUND are
being set to the appropriate GUIDs. What I don't understand is how I can
prevent my CustomAction from being executed when the old outgoing product is
being uninstalled. I only want my CustomAction to execute when an uninstall
I can't tell from that which product versions are being referred to, but during
an upgrade there are two things going on - the install of the new incoming
product and the uninstall of the previous outgoing product, and:
UPGRADINGPRODUCTCODE is set in the outgoing product when it is being
uninst
In case anyone was wondering, it seems MSI does not like the
Session.Database object being called from within a VBScript function. So
the work around is as follows...
Dim gSessionDatabase, gComboBoxView
Set gSessionDatabase = Session.Database
Function GetComboBoxView( oSessionDatabase, oProperty
VERSION < 200) OR (
WIX_DIRECTX_VERTEXSHADERVERSION = "NotSet" ) )
Dominique.
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: 02 October 2009 22:15
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] CustomAction Error
According to the wix docs, those properties are NotSet if the API errors
out. So, without testing, I would suppose that you would need (for your
error message's condition):
((WIX_DIRECTX_PIXELSHADERVERSION < 200) OR NOT
WIX_DIRECTX_PIXELSHADERVERSION) AND ((WIX_DIRECTX_VERTEXSHADERVERSION < 200)
O
methods, so it seems only a C/C+/C# etc solution would work
> for that.
>
> Dominique.
>
> -Original Message-
> From: Thomas Due [mailto:thomas@scanvaegt.dk]
> Sent: 02 October 2009 06:47
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [W
c solution would work
for that.
Dominique.
-Original Message-
From: Thomas Due [mailto:thomas@scanvaegt.dk]
Sent: 02 October 2009 06:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] CustomAction : Enumerating SQLServer
Instancesacrossthe network us
This would be perfect for http://wixrepo.codeplex.com/
Also: Looks good, looking forward to playing around with it, although
the company I work for, will have to support 2008 as well in the near
future.
/Thomas
-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.c
Regards,
Takashi SEKIDO
> -Original Message-
> From: Blair [mailto:os...@live.com]
> Sent: Monday, August 31, 2009 12:59 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] CustomAction Exectuion by Feature
>
> Are all of y
hat please elaborate more.
-Original Message-
From: takashi.sek...@jp.yokogawa.com [mailto:takashi.sek...@jp.yokogawa.com]
Sent: Sunday, August 30, 2009 7:15 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction Exectuion by Feature
Dear Sebastian Brand,
> When se
(Instyler Software)
> [mailto:wix+us...@instyler.com]
> Sent: Tuesday, August 25, 2009 6:39 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] CustomAction Exectuion by Feature
>
> When sequencing the custom action, use &
ler.com]
> Sent: Tuesday, August 25, 2009 6:39 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] CustomAction Exectuion by Feature
>
> When sequencing the custom action, use &MyFeature=3 to
> schedule it whenever the MyFeature f
enko [mailto:y...@sitecore.net]
Sent: Tuesday, August 25, 2009 11:01
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] CustomAction Exectuion by Feature
You should set the "same" condition to your custom action as to the feature.
I have quoted the "same"
You should set the "same" condition to your custom action as to the
feature. I have quoted the "same" word because the actual condition
might differ between Feature and Custom elements. When feature condition
evaluates to true, it sets the feature level to the value defined in
element. This level
Sent: Wednesday, February 25, 2009 11:37 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction following specific CustomAction fails
Both customactions are executed during UI for the mentioned buttons
(browsefile and execute managed action) I publish the DoAction.
The original prob
lto:j...@visionpeople.dk]
> Sent: Wednesday, February 25, 2009 2:29 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] CustomAction following specific CustomAction
> fails
>
>
> Can I do anything to find out what is happening in this install project. I
> guess t
balle [mailto:j...@visionpeople.dk]
Sent: Wednesday, February 25, 2009 2:29 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction following specific CustomAction fails
Can I do anything to find out what is happening in this install project. I
guess the OpenDialog customaction seems
Can I do anything to find out what is happening in this install project. I
guess the OpenDialog customaction seems okay, with the change Rob suggested.
Yan, you had a good suggestion but it doesn't seems like the managed action
is actually invoked.
My guess is that it is related to the action inv
I have created a small test project with only the parts related to this from
my original project.
It includes my c++ customaction and I think the smallest manged CustomAction
possible:
[CustomAction]
public static ActionResult TestAction(Session session)
{
sess
("Stop for debugging:
MyManagedCA", Process.GetCurrentProcess().ProcessName);
This works in 100% cases for me.
Hope this helps.
-- Yan
-Original Message-
From: jballe [mailto:j...@visionpeople.dk]
Sent: Tuesday, February 10, 2009 8:19 PM
To: wix-users@lists.sourceforge.net
Sub
Fascinating. I have no idea what would cause that. I don't write managed code
CustomActions... maybe someone who does has ideas.
-Original Message-
From: jballe [mailto:j...@visionpeople.dk]
Sent: Tuesday, February 10, 2009 10:19
To: wix-users@lists.sourceforge.net
Subject: Re:
Rob Mensching-2 wrote:
>
> Uhh, it looks like you have failing CustomActions.
>
> Install1.log:
>
> Action start 09:12:39: UpdatePropsWithSelectedWebSite.
> MSI (c) (1C:8C) [09:12:39:637]: Creating MSIHANDLE (30) of type 790542 for
> thread 5772
> MSI (c) (1C:14) [09:12:39:638]: Invoking remo
]: Closing MSIHANDLE (30) of type 790542 for
thread 4996
Action ended 09:13:09: ClearMsmqTable. Return value 3.
-Original Message-
From: jballe [mailto:j...@visionpeople.dk]
Sent: Monday, February 09, 2009 00:25
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction following
Thank you. I'am probably using unicode as I am using Visual Studio.
I have changed as you described, but unfortunately it didn't solve the
issue.
I attach two logfiles:
http://n2.nabble.com/file/n2296247/Install1.log Install1.log
http://n2.nabble.com/file/n2296247/Install2.log Install2.log
In
Are you compiling with UNICODE defined? If so I believe you have a buffer
overrun here:
ofn.nMaxFile = sizeof(szOriginalPath);
You should use countof() instead of sizeof().
Otherwise, I'm not really sure what the issue is. Showing the part of the log
file that has the error might be help
In article <1233004461998-2220704.p...@n2.nabble.com>,
jballe writes:
>
>
> Richard-45 wrote:
> >
> > I haven't really been following this thread, but this is the standard
> > way of communicating custom table data to deferred CAs. The MSI SDK
> > documentation provides an example of do
Richard-45 wrote:
>
> I haven't really been following this thread, but this is the standard
> way of communicating custom table data to deferred CAs. The MSI SDK
> documentation provides an example of doing this for creating user
> accounts.
>
Thank you for answering.
You say that I should n
In article <21662327.p...@talk.nabble.com>,
jballe writes:
> I solved the issue by an immediate customaction scheduled in the ui just
> after writing to the customtable. This custom action creates the
> CustomActionData class and saves it to a public property which can be used
> to schedule
Just if someone else is reading this thread.
I solved the issue by an immediate customaction scheduled in the ui just
after writing to the customtable. This custom action creates the
CustomActionData class and saves it to a public property which can be used
to schedule the actions in "after Instal
Ok so I probably have to get around this issue by setting some properties or
similar. I will give it a try.
Thank you for your assistance.
Rob Mensching-2 wrote:
>
> I do have CustomActions that do this sort of thing but I don't use DTF.
> Somewhere there is probably a bug.
>
--
View this
I do have CustomActions that do this sort of thing but I don't use DTF.
Somewhere there is probably a bug.
-Original Message-
From: jballe [mailto:j...@visionpeople.dk]
Sent: Thursday, January 22, 2009 08:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomA
Thank you for your answer, Rob!
Do you (or anyone else) have anything I could try to come over this issue.
Are there another way to acheive this - have noone else used a CustomTable
and CustomActionData before??
Would it make sense to use any kind of nightly build? Or is it not a wix
issue anywa
Sorry, no extra data for you. It seems like it should work.
-Original Message-
From: jballe [mailto:j...@visionpeople.dk]
Sent: Wednesday, January 21, 2009 03:42
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction accessing CustomTable
Hello all,
Can I do
Hello all,
Can I do anything to clearify the issue. Is it not supposed to work?
I am using WIX 3.0.4805.0, developing using Visual Studio 2008 with Votive
Thank you!
Jesper
jballe wrote:
>
> Hello all,
>
> I am writing my first complex setup using wix and managed custom actions
> using c#.
I wouldn't use the vbs CA due to problems with virus scanners
On Sat, Dec 20, 2008 at 9:48 PM, siaj wrote:
> Hello,
>
>
>
> I know custom Action in managed code is discouraged but to be more specific
> I have a requirement of doing SharePoint specific operations like creating
> groups, registerin
That fixed it.
TY
Eric
Date: Mon, 3 Nov 2008 14:09:41 -0800From: "Ian Elliott (Excell Data
Corporation)" <[EMAIL PROTECTED]>Subject: Re: [WiX-users] CustomAction after
Install or Repair?To: General discussion for Windows Installer XML
toolset.Message-ID:<[EMAIL P
A condition of "NOT REMOVE" will run during both install and repair.
-Original Message-
From: Eric Maines [mailto:[EMAIL PROTECTED]
Sent: Monday, November 03, 2008 2:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CustomAction after Install or Repair?
Hi, I have a CustomA
Try running the script from the command line to debug it:
Dim fso, dest, src
Set fso = CreateObject("Scripting.FileSystemObject")
dest = Session.Property("C:\InstallDir")
src = Session.Property("C:\SourceDir")
fso.CopyFolder src, dest
On Tue, Aug 5, 2008 at 1:06 PM, Rohit Lodha
<[EMAIL PROTEC
1 - 100 of 195 matches
Mail list logo
