Quantcast
Channel: wixsharp Discussions Rss Feed
Viewing all 1354 articles
Browse latest View live
↧

New Post: Error18 Installer is no longer responding.

November 30, 2015, 3:27 am
$
0
0
Indeed this popup happens after >30 mins of inactivity. Interestingly enough MSI runtime doesn't create any error log entry to reflect this condition. From MSI point of view everything is OK and it is consistent with your and mine observation when 'Retry' successfully installs the product as nothing happens.

Further testing revealed that this behavior can only be observed with MSIs based on EmbeddedUI model (Project.ManagedUI). And Managed Setup with native UI does not exhibit any symptoms of the problem. Thus I am guessing the WiX/MSI runtime, which hosts embedded UI assembly has some sort of activity monitoring and warns user on the idle timeout.

Further testing has confirmed this suggestion. The MSI embedding the the standard EmbeddedUI from WiX sample "SampleEmbeddedUI.cs" shows the same popup as the one build with Wix#.

I tried (ambitiously) to invoke the Session object methods from the dialog OnTimer (every minute) but it had no affect what so ever. Meaning that unfortunately I cannot offer you any work around.

Sorry but it means that it can only be fixed by the WiX team.
↧
Search

New Post: Placing an executable and an MSI in a bundle, in a bootstrapper

November 30, 2015, 4:47 am
$
0
0
Thank you.

I am a bit confused though. Do I also have to write up an XML with the Wix Tool Set to compose this code in the example you gave? I was hoping for an example with C#/WixSharp

Is there an example of what I need in the sample code?

Thanks again.
↧
↧

New Post: Error18 Installer is no longer responding.

November 30, 2015, 9:18 am
↧

New Post: Placing an executable and an MSI in a bundle, in a bootstrapper

November 30, 2015, 9:53 pm
$
0
0
Indeed typically Wix# produces the all required XML behind the scene so you don't need to deal with raw XML.

However if some WiX features are not supported directly then you may need to define the corresponding XML explicitly (see InjectXML sample). The same applies to the fragments. The fragments are pure XML decoration feature of WiX and as such it's hard to map it to the object model of the Wix# project definition.

This is how you can inject the required XML it in your case:
bootstrapper.WixExtensions.Add("WixUtilExtension");
bootstrapper.WixNamespaces.Add("xmlns:util=\"http://schemas.microsoft.com/wix/UtilExtension\"");
bootstrapper.WixSourceGenerated += Bootstrapper_WixSourceGenerated;
...
staticvoid Bootstrapper_WixSourceGenerated(System.Xml.Linq.XDocument document)
{
    var ns = document.Root.GetNamespaceOfPrefix("util");

    document.Root.Add(new XElement("Fragment",
                            new XElement(ns + "FileSearch")
                                .AddAttributes(@"Id=AdobeSearch;
                                                Variable=AdobeInstalled;
                                                Result=exists;
                                                Path=[ProgramFilesFolder]Adobe\\...\\adobe.exe")));

    document.Select("Wix/Bundle/Chain")
            .AddBeforeSelf(new XElement(ns+"FileSearchRef")
                                .SetAttribute("Id=AdobeSearch"));
}
However the next Wix# release will have a method extension that will simplify the task a little
document.Select("Wix/Bundle")
        .AddWixFragment(new XElement(WixExtension.Util.ToXName("FileSearch"),
                                   @"Variable=AdobeInstalled;
                                     Result=exists;
                                     Path=[ProgramFilesFolder]Adobe\\...\\adobe.exe".ToXAttributes()));
↧

New Post: How to catch the OnBuildCompleted event to sign my setup file?

December 1, 2015, 1:49 am
$
0
0
I need to sign (by certificate) my setup.msi file after it has been built.
In Setup.cs I have next code:
staticvoid Main()
        {
            ManagedProject project = CreateSetupProject();

            ValidateAssemblyCompatibility();

            project.BuildMsi(); 
            
            SignSetupFile(project); // after "Clean, Rebuild" no all files are made by BuildMSI, so the setup.msi doesn't exist at the moment when I want to sign it with signtool.exe. Only  setup.wix file exists in output folder.
        }
The problem appears only on "Clean" build (after Clean, and Rebuild commands)
I thought that method BuildMsi will return path (looking into the source code), but it returns null.
if I delete sign file logic or to second build after the first one - all is OK. Looks like the creation of msi is async process.
So, is there any buildComplete event to be sure, that BuildMsi has finished own work and all files have been created?

Or what is you suggestion for this?
↧
↧

New Post: Placing an executable and an MSI in a bundle, in a bootstrapper

December 1, 2015, 12:04 pm
$
0
0
Thank you, again!

Just one more.... is there a way to do that with the registry instead of looking for the "adobe.exe" binary that gets installed?

The registry for Adobe is in the "current user" section under @"Software\Adobe\Acrobat Reader\11.0"
↧

New Post: Placing an executable and an MSI in a bundle, in a bootstrapper

December 1, 2015, 3:15 pm
$
0
0
Yes there is a way. You will need to use RegistrySearch fragment instead of FileSearch. BTW the yesterday release has delivered AddWixFragment API.

However if you are asking about the registry key that indicates that AdobeReader is installed then you will need to do your own research on this as the way the product is deployed is entirely up to the software vendor.
↧

New Post: How to catch the OnBuildCompleted event to sign my setup file?

December 1, 2015, 3:54 pm
$
0
0
The creation of msi is not an async process. It doesn't return until the build succeeds or fails. An empty return value indicates that your build fails. Your comment "setup.msi doesn't exist" confirms that. Meaning that on a first attempt some input files are not ready/found and this is the problem that you need top fix.

Have a look at the BuildMsi output of analyse Compiler.ToolsOutputReceived event data to see what exactly upsets WiX compilers.

BTW you may want to have a look at Signing sample, which demonstrates how to sign MSI with Wix#:
string msi = Compiler.BuildMsi(project);
        
int exitCode = Tasks.DigitalySign(msi,
                                  "wixsharp.pfx",
                                  "http://timestamp.verisign.com/scripts/timstamp.dll",
                                  "my_password");

if (exitCode != 0)
    Console.WriteLine("Could not sign the MSI file.");
else
    Console.WriteLine("the MSI file was signed successfully.");
↧
Search

New Post: How to catch the OnBuildCompleted event to sign my setup file?

December 2, 2015, 12:58 am
$
0
0
An empty return value indicates that your build fails. Your comment "setup.msi doesn't exist" confirms that.
But how could it be, that build doesn't fail, if the last line of my code is project.BuildMsi(), but fails, if after that string there will be even your Tasks.DigitalySign() method?
Each time and only on clean build. It means, that some files during the first build are creating (writing) too long and msi is not ready to be created and the process is fininshing in a background (direct async writing to the files for example).
↧
↧

New Post: How to catch the OnBuildCompleted event to sign my setup file?

December 2, 2015, 1:13 am
$
0
0
> But how could it be, that build doesn't fail, if the last line of my code is project.BuildMsi(),
I cannot explain that. But you've seen the Wix# source code, It always wait fro WiX compiler to finish with Process.WaitForExit().

The easiest way to solve the problem would be to create a "Hello World" style project that exhibits the problem and send it to me.

If it cannot be done you can test your asynch build assumption. You can modify the code as below:
var msi = project.BuildMsi();
Console.WriteLine("MSI: " + msi);
//have here whatever code that fails the build
This should produce the following output:
ProductName: MyProduct
Version    : 1.0.0.0
ProductId  : {6fe30b47-2577-43ad-9095-1861ca25889c}
UpgradeCode: {6fe30b47-2577-43ad-9095-1861ba25889b}
 
Auto-generated InstallDir ID:
  INSTALLDIR=%ProgramFiles%\My Company\My Product
MSI: c:\users\<user>\documents\visual studio 2015\Projects\WixSharp Setup15\WixSharp Setup15\MyProduct.msi
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
The output above was produced by the default Wix# project template. The placement of the "MSI: c..." below the "INSTALLDIR..." line indicates that execution in my case was synchronous. Let's see what it does in your case.
↧

New Post: How to install multiple subdirectories under ProgramFiles64Folder

December 2, 2015, 2:13 am
$
0
0
I have made a WixSharp 64bit installer that should install files under two different directories under "Program Files". Here is a stripped down version of the code:
using System;
using WixSharp;
using File = WixSharp.File;

public class Script {

    public static void Main(string[] args) {
       var project =
           new Project("My Product",
               new Dir(@"%ProgramFiles%",
                   new Dir(@"SubDir1", new File(@"Files\test2.txt")),
                   new Dir(@"SubDir2", new File(@"Files\test2.txt"))
               ));

        project.Platform = Platform.x64;
        project.GUID = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");    
        Compiler.BuildMsi(project);
    }
}
The problem is that the subdirectories will be created under "c:\%ProgramFiles64%\" instead of being under "c:\Program Files\".

If I just install one sub-directory, then the directory will be installed correctly into "c:\Program Files".

If I do the same without specifying the platform as x64 the files will correctly go under "c:\Program Files(x86)".

What am I doing wrong here? How could I get the two directories there.

I first suspected I might be hitting the wrong overload of the Dir constructor, but the behavior is the same when using the following code to ensure it goes into the Dir(string targetPath, params WixEntity[] items) constructor:
       new Dir(@"%ProgramFiles%",new WixEntity[] {
            new Dir(@"SubDir1", new File(@"Files\test2.txt")),
            new Dir(@"SubDir2", new File(@"Files\test2.txt"))
        }
↧

New Post: How to install multiple subdirectories under ProgramFiles64Folder

December 2, 2015, 5:07 pm
$
0
0
The problem you are experiencing is caused by not having a single root installation dir.
Wix# still assigns (as it always does) the INSTALLDIR to the first common parent %ProgramFiles%. However this in turns breaks the MSI Id assignment constrain for the well-known directories (e.g. Program Files). This can be easily avoided by you defining the dir id explicitly:
new Project("MyProduct",
            new Dir(new Id("ProgramFiles64Folder"), "%ProgramFiles%",
                new Dir(@"SubDir1", new File(@"Files\test2.txt")),
                new Dir(@"SubDir2", new File(@"Files\test2.txt"))
                 ...
This will install the files as you would expect. However, your whole scenario creates an ambiguity about your installation directory. What is it? Is it SubDir1 or SubDir2? You will have difficulties of engaging any functionality that relies on the concept of a single root install directory (MSI fundamental paradigm). MSI InstallDir dialog will pick your first sub dir and treat it as the install dir and will completely prevent you from changing the second one. Wix# ManagedUI dialogs are under the same scrutiny too.

Everything would work just fine if you only have a root directory defined:
new Project("MyProduct",
            new Dir("%ProgramFiles%\MyProduct",
                new Dir(@"SubDir1", new File(@"Files\test2.txt")),
                new Dir(@"SubDir2", new File(@"Files\test2.txt"))
                 ...
↧

New Post: How to install multiple subdirectories under ProgramFiles64Folder

December 2, 2015, 11:49 pm
$
0
0
Thank you Oleg for the quick answer and the workaround.

The real case from which the example was stripped, is an AutoCAD plugin which I'm developing which must be installed under the "Program Files/AutoDesk/ApplicationPlugins/" so that Autocad will find it and load it. The plugin is communicating with our own product which is installed under another program files subdirectory.

Initially I had made two separate installers, one for the plugin and one for our own product. But our PO wanted a single installer to run to make it easy for the user, which is quite understandable. So I combined the two installers into one, but apparently this is a bad approach as there is no common installdir folder.

What would be a good way of handling the above scenario? Should I use a bootstrapper that runs two separate msi:s?
↧
↧

New Post: How to catch the OnBuildCompleted event to sign my setup file?

December 3, 2015, 1:42 am
$
0
0
Ok, I'll try and continue to test. Thanks
↧

New Post: How to install multiple subdirectories under ProgramFiles64Folder

December 3, 2015, 3:12 am
$
0
0
OK, I see. Then indeed you need to have multiple install dirs.
.
  1. The problem is that you are assuming that AutoCAD is installed in ProgramFiles. But what if it's not (e.g. user changed the installdir). Then you have a real problem. Your plugin integration will be broken. One of the most reliable approaches is to make the plugin deployment a part of your product configuration step. Thus you can pack the plugin into your product msi and after the installation you start you app config util. In this util at startup you can dynamically locate the AutoDesk (according various algorithms) and deploy the plugin files there. This very same config utill will allow user to remove/update the plugin file anytime without resorting to ARP. This is in fact a common and recommended approach for post Vista Windows. However it is only applicable if the plugin manual deployment involves no more than just copying a few files.
    .
  2. However if you are certain in the AutoDesk location (e.g. it doesn't allow user to change the installdir) then you can go with the solution from my previous post. Just remember that your product dir supposed to be first. In this case MSI will allow user to change your app installdir but not the plugin dir.
    .
  3. An alternative approach indeed would be a bootstrapper.
Arguebly #2 is the simplest one.
↧
Search

New Post: Rollback custom action after pressing Cancel button

December 3, 2015, 6:03 am
$
0
0
I did some more tests, and here are my findings when pressing Cancel button on Progress dialog:
  • My rollback custom actions are not executed because the referenced assemblies are not extracted from msi. For exemple, if the log says 
SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI9D2C.tmp-\
the C:\WINDOWS\Installer\MSI9D2C.tmp-\ folder is not created on disk. I mention that all temporary folders created for running the normal custom actions, before presssing Cancel button, exist on disk.
  • On upgrade rollback, the ExecXmlFileRollback action (it is not mine), which is supposed to modify an xml file, throws error:
MSI (s) (D8:98) [14:46:00:498]: Executing op: ActionStart(Name=ExecXmlFileRollback,,)
MSI (s) (D8:98) [14:46:00:501]: Executing op: CustomActionRollback(Action=ExecXmlFileRollback,ActionType=3329,Source=BinaryData,Target=ExecXmlFileRollback,CustomActionData=0€C:\Program Files (x86)\MyCompany\MyApp\web.config€
MSI (s) (D8:AC) [14:46:00:508]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIB793.tmp, Entrypoint: ExecXmlFileRollback
ExecXmlFileRollback:  Entering ExecXmlFileRollback in C:\WINDOWS\Installer\MSIB793.tmp, version 3.10.2103.0
ExecXmlFileRollback:  Error 0x80070002: Failed to get modified date of file C:\Program Files (x86)\MyCompany\MyApp\web.config.
CustomAction ExecXmlFileRollback returned actual error code 1602 but will be translated to success due to continue marking
For now, I will disable the Cancel button on Progress dialog.
↧

New Post: Attended mode takes much more time than unattended mode

December 3, 2015, 9:58 am
$
0
0
Hi,

I have a Managed Setup with Embedded UI, installing an application containing about 400 files. If I run the setup in attended mode, it takes 10 times more time than if I run it in silent mode. ( 7 minutes vs 40 seconds).
I looked into the log file and every single operation takes more time in attended mode. (register component, copy file, etc)
Surprisingly, my custom actions take the same time in both installation modes.
I tried to set MSIFASTINSTALL = 7, but I did not see any improvement.

Is there a chance to speed up the installation between Ready To Install and Completed Successfully dialogs?
Thank you.
↧
↧

New Post: Rollback custom action after pressing Cancel button

December 3, 2015, 3:50 pm
$
0
0
> ...the C:\WINDOWS\Installer\MSI9D2C.tmp-\ folder is not created on disk.
Yes indeed it does look like a SFXCA problem. If you really want to get at the bottom of it you may want to log the defect at WiX wiki. The easiest way to do this is to call BuildMsiCmd and this will produce a batch file that will only use WiX tools and your wxs sources. This way your test case will not be polluted with Wix# logic and this WiX friendlier version will be easier to deal with for the WiX guys.

> I mention that all temporary folders created for running the normal custom actions, before presssing Cancel button, exist on disk.
I am not sure it is true. I have observed very different behavier. WiX SFXCA runtime creates a fully self sufficient temporary dir for every single CA even if the action is using the same set of dlls.
↧

New Post: Attended mode takes much more time than unattended mode

December 3, 2015, 4:13 pm
$
0
0
It is really outside of Wix# domain :)

Wix# is only responsible for authoring MSI and it cannot possibly control MSI performance at runtime. Remember Wix# is a compilation tool but not a runtime system. Effectively it has as much to do with MSI performance as VisualStudio with the performance of the application it compiled.

True, Wix# implements navigation between ManagedUI (specific case of EmbeddedUI) dialogs, but not for the hosting EmbeddedUI itself. And it seems that the navigation is not where you get you performance penalty. BTW EmbeddedUI hosting is not actually a Wix# feature but MSI/WiX one.

I would suggest that you (for the sake of experiment) build your msi file with the EmbeddedUI provided by WiX samples and see if there any performance difference. It is very easy, you just use <wix# samples>/Custom_UI/EmbeddedUI sample as the VS project.
↧

New Post: Attended mode takes much more time than unattended mode

December 9, 2015, 2:34 am
$
0
0
I have tried many settings to improve the installation time.

I tried <wix# samples>/Custom_UI/EmbeddedUI sample with my files, and I got the same installation time for attended and unattended modes (the longer time).

At some point, I tried to remove the embedded cabinet file from MSI file and bingo, the clean installation time dropped off from 7 minutes to 2 minutes. So it seems that not embedding the cabinet file is a solution for me for UI installations to run faster.
↧
Viewing all 1354 articles
Browse latest View live
Search

Latest Images

WATCH: What you need to know about the Pacquiao-Barrios title fight

WATCH: What you need to know about the Pacquiao-Barrios title fight

July 19, 2025, 6:46 am
Review: Skil PWRCore 20 18-Gauge Brad Nailer

Review: Skil PWRCore 20 18-Gauge Brad Nailer

July 19, 2025, 5:00 am
Why Not Try Sanity?

Why Not Try Sanity?

July 19, 2025, 4:17 am
Inside sick ‘child fight clubs’ where gangs lure teens into savage street...

Inside sick ‘child fight clubs’ where gangs lure teens into savage street...

July 19, 2025, 3:59 am
Met Eireann’s 24-hour weather alert kicks in with ‘heavy rain’ and ‘isolated...

Met Eireann’s 24-hour weather alert kicks in with ‘heavy rain’ and ‘isolated...

July 19, 2025, 3:00 am
Manny Pacquiao vs Mario Barrios undercard thrown into chaos as fighter is...

Manny Pacquiao vs Mario Barrios undercard thrown into chaos as fighter is...

July 19, 2025, 2:52 am
Former Hampton Roads Baseball Star Honored by Mets as Number is Officially...

Former Hampton Roads Baseball Star Honored by Mets as Number is Officially...

July 19, 2025, 12:45 am
Israel and Syria agree to ceasefire, US envoy says after days of airstrikes...

Israel and Syria agree to ceasefire, US envoy says after days of airstrikes...

July 18, 2025, 3:42 pm
Speed limit is pulled back to only 20mph across new spots as ‘slow zones’...

Speed limit is pulled back to only 20mph across new spots as ‘slow zones’...

July 18, 2025, 1:27 pm
Britain’s most popular car to RETURN after being axed two years ago – but not...

Britain’s most popular car to RETURN after being axed two years ago – but not...

July 18, 2025, 9:35 am
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>