wix37.exe /quiet
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wix37-exe-unattended-installation-tp7589794p7589830.html
Sent from the wix-users mailing list archive at Nabble.com.
-
Well there is the bug then.
On Fri, Oct 18, 2013 at 2:31 AM, Pally Sandher wrote:
> You are correct, it's the web installer.
> The full redistributable is named dotNetFx40_Full_x86_x64.exe & is 48.1 MB
> in size.
>
> Looking at the source for the WiX installer, in
> \src\Setup\Bundle\Bundle.wxs
That doesn't sound right. Name attribute should be respected and it should
place that file in the redist\mpi_x64.msi folder relative to the output
bundle.exe.
On Fri, Oct 18, 2013 at 7:02 AM, Pally Sandher wrote:
> It'd be nice if there was some easy way to leverage the "redist" directory
> in y
Yeah, if he'd like to help work on this issue
https://github.com/robmen/tinybugs/issues/2 that'd be great.
On Fri, Oct 18, 2013 at 6:52 AM, Christopher Painter wrote:
>
>
> Rob,
>
> You were right. It was 6 lines of JQuery. :)Seriously, my friend
> made this little page to provide a basic
Aha, looked at it again and I noticed I didn't' have
[CustomAction]
public static ActionResult StopServiceForUninstall(Session session)
I only had
public static ActionResult StopServiceForUninstall(Session session)
sigh...
I am not using WIX to create the service(s) we are using NServiceBus, so
"We picked a folder ("redist" seemed as good as any) since many people want
the root of their media to be clean. Thus it's clearer to the user what to
double click on (aka: there is only one file named "setup.exe")."
I can vouch for this - I've had to do the same thing in response to QA and
custom
The problem appears to be as described in that stackoverflow link. You may
be calling the managed Dll directly from the installer, Windows is
expecting an unmanaged Dll, and so it describes the Dll as corrupt.
It might be worthwhile figuring out why the standard StopServices doesn't
always work. I
Your hunch is correct.
There are 2 main reasons for the use of Burn as far as I know.
1 - "dogfooding"
2 - WiX installs a bunch of packages now instead of one monolithic package. If
you look in \src\Setup\Bundle\Bundle.wxs you'll see it chains .NET 4.0 full,
ProjectAggregator.msi if you have Vi
It'd be nice if there was some easy way to leverage the "redist" directory in
your own Packages without a massive effort.
Setting "Name" attribute of MsiPackage only works if you have the package
embedded in your bundle. It completely ignores it in the case of a DownloadUrl
e.g.
http://do
Rob,
You were right. It was 6 lines of JQuery. :)Seriously, my friend made
this little page to provide a basic search capability.
http://codepen.io/YurikoEX/pen/hikyg
He's a really nice guy, loves open source and is a way better web developer
then I am. I can put the two of you in
I am following the DTF guidelines...
I am using service control:
But there are some instances where a service(s) hasn't stopped so this is an
extra fail safe...
Steve
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: October-18-13 9:34 AM
To: General discussion abo
Check out this
http://stackoverflow.com/questions/3560370/custom-action-in-c-sharp-used-via-wix-fails-with-error-1154
Why are you not using the service control element to ensure the service is
stopped?
http://wixtoolset.org/documentation/manual/v3/xsd%5Cwix%5Cservicecontrol.html
-Original
I have a huncgh that the installer WiX Uses now is a burn style
installer, because the install requires a check for the .NET 4
Framework.
Quoting Jens Teutenberg :
> I don’t like the installer which is used since V3.6 (Wix36.exe, Wix37.exe).
> Why it isn’t possible to release a MSI file as us
Most likely because the installer is installing pre requisites and other tools,
it is also using its "burn" technology.
There are multiple MSI's being run.
steve
-Original Message-
From: Jens Teutenberg [mailto:jens.teutenb...@t-online.de]
Sent: October-18-13 8:30 AM
To: wix-users@lists
Hi,
I am calling a custom action on uninstall just to ensure that our 5 services
are actually stopped before we try to remove them...
However I am getting an error that confuses me since everything looks kosher...
Anyone see any issues with what I am doing?
Here is the error from the log file:
I don’t like the installer which is used since V3.6 (Wix36.exe, Wix37.exe).
Why it isn’t possible to release a MSI file as used before V3.6 (Wix2.msi,
Wix3.msi, Wix35.msi)?
--
October Webinars: Code for Performance
Free In
Good point Rob. Our QA just whines me constantly that the installation
package has weird structure. I'll have to use Mr. Delambre's approach :-)
Thank you both for your replies
Best regards,
Veli-Matti Visuri
On Wed, Oct 16, 2013 at 7:12 PM, Rob Mensching wrote:
> We picked a folder ("redist"
You are correct, it's the web installer.
The full redistributable is named dotNetFx40_Full_x86_x64.exe & is 48.1 MB in
size.
Looking at the source for the WiX installer, in \src\Setup\Bundle\Bundle.wxs it
contains the following:
So /layout will always pull the web install
Hello again,
Is it possible that uninstalling my program on Windows 2008 R2 fails
removing the shortcuts, but uninstalling it on W7 works well (all the
program and shortcuts are removed) ?
This is my case It is crazy, but true.
Thanks a lot for your time.
I attach the code, perhaps here is
19 matches
Mail list logo
