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

New Post: Creating WixSharp Setup in asp.net website.

October 30, 2015, 6:39 am
$
0
0
How i can check the Wix# compiler output? I can't find a property in wix# to create log when it is generating setup.
↧
Search

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

October 30, 2015, 10:52 am
$
0
0
Thank you, that seemed to work!

My next issue is uninstalling what I just installed. When I bring up the control panel's Uninstall window, I can see the name of my bootstrapper and the Adobe installation in the list.

When I click on uninstall, the application installed with the MSI part of the bundle gets un-installed, and my bootstrapper un-installs itself. But the Adobe app remains installed.

How do I link the uninstall of the the bootstrapper with Adobe's uninstall? I want the entire stack of applications linked/bundled together so everything installs and uninstalls in one request.

BTW: I don't know if the adobe setup exe is an "exe+msi" or just an "exe". How does one determine if an exe file is both?

Sorry about all these new-bee beginner questions. I have never written an installer before and WixSharp seemed easier to learn since I am comfortable with C#.

Thanks!
↧
↧

New Post: Creating WixSharp Setup in asp.net website.

October 30, 2015, 6:02 pm
$
0
0
There is no property for this. You will need to debug your application and investigate any exceptions thrown. There can be a few exception causes: Wix# specific errors (e.g. WiX compilers are not found) or common applications errors (e.g. concurrency, permissions).

Eix# uses WiX compilers as external processes thus it cannot catch and rethrow any WiX errors. Thus WiX prints its all errors in the Console.StandardOutput. Though Wix# redirects it into debugger output so you will see all the errors.
↧

New Post: Registry don't working

November 1, 2015, 12:50 am
$
0
0
Use Registry sample as is 
static public void Main(string[] args)
    {
        //uncomment the line below if the reg file contains unsupported type to be ignored
        //RegFileImporter.SkipUnknownTypes = true;

        var fullSetup = new Feature("MyApp Binaries");

        var project =
            new Project("MyProduct",
                new Dir(@"%ProgramFiles%\My Company\My Product",
                    new File(fullSetup, @"readme.txt")),
                new RegFile(fullSetup, "MyProduct.reg"), //RegFile does the same Tasks.ImportRegFil
                new RegValue(fullSetup, RegistryHive.LocalMachine, "Software\\My Company\\My Product", "Message", "Hello"), 
                new RegValue(fullSetup, RegistryHive.LocalMachine, "Software\\My Company\\My Product", "Count", 777),
                new RegValue(fullSetup, RegistryHive.ClassesRoot, "test\\shell\\open\\command", "", "\"[INSTALLDIR]test.exe\" \"%1\""));

        project.GUID = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
        project.UI = WUI.WixUI_ProgressOnly;

        project.PreserveTempFiles = true;
        project.BuildMsi();
    }
But registry is empty.

Windows 8.1 x64
↧

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

November 3, 2015, 9:02 pm
$
0
0
> I don't know if the adobe setup exe is an "exe+msi" or just an "exe". How does one determine if an exe file is both?
It's actually easy. If the product can be installed by executing a stand alone *.exe (e.g. setup.exe) then the .msi is embedded into the bootstraper application (.exe file). However if the setup .exe requires an .msi to be present in the same location then it is an "exe+msi" setup and the product can be installed only if both msi and exe are present.

The actual choice of the model (single exe vs exe+msi) will always depend on the implementation of the deployment framework that was used to author the bootstrapper application. For example WiX Burn always embeds msi files into exe (at least by default).

> ...my bootstrapper un-installs itself. But the Adobe app remains installed.
It is actually not an unusual problem. Particularly when you are using third-party bootstrappers (setup.exe) inside of your bootstrapper. One of the possible reasons is that during uninstall your bootstrapper doesn't pass the 'magic' uninstall argument into your dependency setup.exe. This can be '/u' or '/uninstall' or what ever Adobe guys decided to use. You normally control this with ExePackage.UninstallCommand.
Another possible reason is that during the uninstall session your bootstrapper doesn't detect correctly that Adobe reader is already installed. You normally use ExePackage.DetectCondition. This is what the doculmentation says about it:
A condition that determines if the package is present on the target system. This condition can use built-in variables and variables returned by searches. This condition is necessary because Windows doesn't provide a method to detect the presence of an ExePackage. Burn uses this condition to determine how to treat this package during a bundle action; for example, if this condition is false or omitted and the bundle is being installed, Burn will install this package.
It is a generic WiX/Burn challenge and most likely you will find something on the subject if you google for "burn uninstall adobe".
↧
↧

New Post: Registry don't working

November 3, 2015, 9:08 pm
$
0
0
Most likely it didn't check the right registry node. The setup above installs into HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\My Company\My Product

Is it the case?
↧

New Post: Creating WixSharp Setup in asp.net website.

November 4, 2015, 3:44 am
$
0
0
Hi,

I have tested with DefaultAppPool Identity is set to ApplicationPoolIdentity of IIS . I am posting the Console Output. The problem is in Light.exe Validation Script.

Question:- Is it Possible to avoid the validation. Is there any property or configuration to disable validation?

Console Output:-
'w3wp.exe' (CLR v4.0.30319: /LM/W3SVC/1/ROOT/ScreenSaverF-1-130909346140359954): Loaded 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\screensaverf\559dcde5\4b1c325e\assembly\dl3\9b4e9424\2cf362b7_66f8d001\WixSharp.dll'. Cannot find or open the PDB file.
The thread 0x16e8 has exited with code 259 (0x103).
'w3wp.exe' (CLR v4.0.30319: /LM/W3SVC/1/ROOT/ScreenSaverF-1-130909346140359954): Loaded 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\screensaverf\559dcde5\4b1c325e\assembly\dl3\6fd580ee\00dc5c53_cb12d001\Microsoft.Deployment.WindowsInstaller.dll'. Cannot find or open the PDB file.
A first chance exception of type 'System.Xml.XmlException' occurred in System.Xml.dll
A first chance exception of type 'System.Xml.XmlException' occurred in System.Xml.dll
"D:\Development\workspace\abc\WixSharpLibraries\bin\candle.exe" -sw1026 -ext "D:\Development\workspace\abc\WixSharpLibraries\bin\WixUIExtension.dll" "D:\Development\workspace\abc\UserData\30\Setup\SetupFile\setup.wxs" -out "D:\Development\workspace\abc\UserData\30\Setup\SetupFile\setup.wixobj"
Windows Installer XML Toolset Compiler version 3.10.0.2103
Copyright (c) Outercurve Foundation. All rights reserved.

setup.wxs
"D:\Development\workspace\abc\WixSharpLibraries\bin\light.exe" -sw1076 -sw1079 -b "D:\Development\workspace\abc\UserData\30\Setup\SetupFile" "D:\Development\workspace\abc\UserData\30\Setup\SetupFile\setup.wixobj" -out "D:\Development\workspace\abc\UserData\30\Setup\SetupFile\setup.msi" -ext "D:\Development\workspace\abc\WixSharpLibraries\bin\WixUIExtension.dll" -cultures:en-US
Windows Installer XML Toolset Linker version 3.10.0.2103
Copyright (c) Outercurve Foundation. All rights reserved.

light.exe : error LGHT0217 : Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".

light.exe : error LGHT0217 : Error executing ICE action 'ICE02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".

light.exe : error LGHT0217 : Error executing ICE action 'ICE03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
light.exe : error LGHT0217 : Error executing ICE action 'ICE04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
light.exe : error LGHT0217 : Error executing ICE action 'ICE05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
light.exe : error LGHT0217 : Error executing ICE action 'ICE06'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
light.exe : error LGHT0217 : Error executing ICE action 'ICE07'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
light.exe : error LGHT0216 : An unexpected Win32 exception with error code 0x643 occurred: Action - 'ICE09' Fatal error during installation
↧

New Post: Creating WixSharp Setup in asp.net website.

November 4, 2015, 3:20 pm
$
0
0
OK. Great. Now we can completely rule out Wix# from the equation.

The problem you are experiencing is caused by the light.exe not being happy about its runtime conditions. Quick googling immediately reviled a few WiX issue reports of a similar nature: http://wixtoolset.org/issues/4922/ and http://wixtoolset.org/issues/4877/. Unfortunately none of them is processed yet. As I see it the problem is caused by the insufficient privileges of your application process.

You can disable validation with Project.LightOptions however there is a little chance it will help. Probably a better approach is to stick with the AppPool settings that work for you.
↧
Search

New Post: Bundling an unknown number of MSIs into a bootstrapper

November 5, 2015, 9:06 am
$
0
0
Hi there

I've been trying a more complicated use case whereby I have an unknown number of MSIs that I want to bundle into one bootstrapper. So far I have attempted the following (edit for brevity):
static void Main()
{
    //Get list of projects to build from app.config
    msiFiles = Dictionary<string, string> from config;

    ChainItem[] chainItems = { };

    //Loop through list and build each MSI - this works
    foreach(var kvp in msiFiles)
    {
        chainItems.Add(new MsiPackage(CreateMsiFile(kvp)));
    }

    BuildBoostrapper(chainItems);
}

//This method works fine.
static string CreateMsiFile(KeyValuePair<string>, <string> projectInfo)
{
    ...
    ...
    ...
}

static void BuildBoostrapper(ChainItem[] msiFiles)
{
    var bootstrapper = 
        new Bundle("MyBundle", msiFiles)
        {
            Version = new Version(),
            UpgradeCode = new Guid("MYGUID"),
            OutDir = "Path\To\Dir",
            Manufacturer = "MyCorp",
            Compressed = true,
            OutFileName = "Mysetup.exe"
        };

    bootstrapper.Build();
}
Trouble is, I get "A Chain element must have at least one child element of type MsiPackage, ExePackage, or PackageGroupRef." error on build. Can I not pass an array of ChainItem as I am doing to the new Bundle? If not, how can I include a variable number of MSI's in the bootstrapper without hard coding them in?

Many thanks

Steve
↧
↧

New Post: Bundling an unknown number of MSIs into a bootstrapper

November 5, 2015, 5:49 pm
$
0
0
Passing the array of ChaiItem to the constructor is the correct way to do this.
The constructor doesn't actually do much:
public Bundle(string name, params ChainItem[] items)
{
    WixExtensions.Add("WiXNetFxExtension");
    WixExtensions.Add("WiXBalExtension");
    Name = name;
    Chain.AddRange(items);
}
Anyway, I just modified the Samples\Bootsrapper\WixBootsrapper sample as below and it works just fine:
ChainItem[] msiFiles  = new ChainItem[] { new MsiPackage(crtMsi) { DisplayInternalUI = true },
                                          new MsiPackage(productMsi) { DisplayInternalUI = true }};

var bootstrapper =
new Bundle("MyBundle", msiFiles)
{
    Version = new Version(),
    UpgradeCode = new Guid("6f330b47-2577-43ad-9095-1861bb25889b"),
    Manufacturer = "MyCorp",
    Compressed = true,
    OutFileName = "Mysetup"
};
Ensure you set bootstrapper.PreserveTempFiles = true; before calling Build() and it will preserve the generated wxs file. The clue to your problem will be there.
↧

New Post: Bundling an unknown number of MSIs into a bootstrapper

November 6, 2015, 4:12 am
$
0
0
Good to know I'm not going mad, I was certain what I was doing was right. However, changing the sample app as above did not work for me, but I have solved it.
I'm not really sure why, but using 
    ChainItem[] items = { };
and pasing that ended up empty, but using
var chainItems = new List<ChainItem> {new PackageGroupRef("NetFx40Web")};
    chainItems.AddRange(msiFiles.Select(kvp => new MsiPackage(CreateMsiFile(kvp))));

     //Create the bootstrapper
     BuildBootstrapper(chainItems.ToArray());
That worked like a charm. In the end I referenced your source directly instead of the NuGet packages, added debug statements and worked backwards to solve it, and I can now send a number of MSIs to the bootstrapper which is only known at run time.

Just as an FYI, chaning the sample as you did does not work directly - you get an argument exception, but it's the same as you'd get if you called 
var chainItems[] chainItems = { new MsiPackage("package1"), new MsiPackage("package2") };
    var bootstrapper = new Bundle("MyProject", new PackageGroupRef("NetFx40Web"), chainItems);
Many thanks for the help again

Steve
↧

New Post: Bundling an unknown number of MSIs into a bootstrapper

November 6, 2015, 4:45 am
$
0
0
Hi Steve. I'm glad you solved it.

The sample I gave you should work. I tested the change before suggesting it to you.

You probably didn't notice that that in the code in my post I didn't include PackageGroupRef. Thus my code was
//should workvar bootstrapper = new Bundle("MyBundle", msiFiles)
but not
//shouldn't workvar bootstrapper = new Bundle("MyBundle", new PackageGroupRef("NetFx40Web"), msiFiles)
Though by skipping the PackageGroupRef I actually defined a bundle that is slightly different to the unmodified sample. Fortunatelly it didn't stop you from solving the problem. :)

Cheers,
Oleg
↧

New Post: Custom Action conditions that contain XML markup

November 10, 2015, 1:37 am
$
0
0
Hi,

It would be good if the Custom Actions conditions would be wrapped up in CDATA block if the conditions contain data that could be interpreted as XML markup.
Regards.
↧
↧

New Post: Use WiX properties in VBScript custom action

November 10, 2015, 9:04 am
$
0
0
Hi,

I try to add a ScriptAction to my collection of project.Actions. Is it possible to use properties values in my VB Script code string?
Like: 
Set oShell = CreateObject ("Wscript.Shell")
oShell.CurrentDirectory = "[INSTALLDIR]"
It seems I cannot use the properties in the VB Script code.

Thanks.
↧

New Post: Use WiX properties in VBScript custom action

November 10, 2015, 8:23 pm
$
0
0
As far as I remember you cannot do this as VB script action is sandboxed. Though I can be wrong.

However you can achieve the same with the custom C# action:
publicclass CustomActions
{
    [CustomAction]
    publicstatic ActionResult MyAction(Session session)
    {
        try
        {
            var p = new Process();
            p.StartInfo.WorkingDirectory = session["INSTALLDIR"];
            p.StartInfo.FileName = ...
            p.Start();
        }
        catch (Exception e)
        {
            session.Log(e.ToString());
            return ActionResult.Failure;
        }
        return ActionResult.Success;
    }
...
Or even simpler with the events (e.g. deferred actions):
project.AfterInstall += project_AfterInstall;
...
staticvoid project_AfterInstall(SetupEventArgs e)
{
    try
    {
        var p = new Process();
        p.StartInfo.WorkingDirectory = e.InstallDir;
        p.StartInfo.FileName = ...
        p.Start();
    }
    catch (Exception ex)
    {
        e.Session.Log(ex.ToString());
    }
}
Have a look at "Managed Setup" samples for more details.
↧
Search

New Post: .Net 4.6 breaks external UI installer

November 12, 2015, 2:34 am
$
0
0
Can I just ask what you mean by "breaks external UI installer"? I am going round in circles trying to get an MSI with a managed UI and custom dialog to show when using a bootstrapper: If I use a standard bootstrapper I get just the bootstrapper UI (no use to me) and if I use the silent bootstrapper I get nothing. I am using DisplayInternalUI = true to no avail, and we do have 4.6 installed as we are using V2015. Is this what you are talking about, or am I encountering something else? The documentation isn't providing a lot of help as it tends to only deal with isolated, granular examples that do not seem to stack well.

EDIT: Wondering if I'm encountering the problem discussed in this Wix Toolset feature request

Thanks
↧

New Post: .Net 4.6 breaks external UI installer

November 12, 2015, 4:05 am
$
0
0
>Can I just ask what you mean by "breaks external UI installer"?

The author of the initial post only indicated that it was a CLR compatibility issue but no further details are available. Given that later releases delivered fixes for the actual compatibility defects I assume this issue is solved. At least until I have further reports indicating otherwise.

However your problem is completely different and not related to CLR compatibility at all. It was in fact already reported a few times. Unfortunately it is a Burn defect and I am really limited with what I can offer you as a solution. The problem actually logged as defect on WiX issue tracker (issues#4918). It was asknowledged by the WiX team and eventually ended up being a feature request (feature#4921). The current status is "Needs research and a WIP"

I captured the all important points related to this matter in this discussion: https://wixsharp.codeplex.com/discussions/645838

I hope it helps. Or at least explains.
↧
↧

New Post: How to add preprocessor tags?

November 16, 2015, 4:55 am
$
0
0
Hi, how can I added preprocessor directives? eg: <?include Constants.wxi ?>

(Not sure if this is feasible via XElement either)
↧

New Post: How to add preprocessor tags?

November 16, 2015, 5:57 am
$
0
0
Adding an XProcessingInstruction is a potential solution: 
    static void project_WixSourceGenerated(XDocument document)
    {
        var proc2 = new XProcessingInstruction("define", "ProductVersion=\"!(bind.FileVersion.fil7212AA8A8B46015A04DEF2311F206827)\"");
        document.Root.AddBeforeSelf(proc2);
    }
↧

New Post: Absolute path

November 16, 2015, 8:06 am
$
0
0
I'm trying to make simple managed setup with absolute path like this:
var project = new ManagedProject("My Product",
                          new Dir(@"C:\MyProduct",
                              new Files(@"Data\*.*")));
Also specifying one custom dialog like in Samples
        project.ManagedUI.InstallDialogs.Add<WelcomeDialog>()
                                .Add<InstallDirDialog>()
                                .Add<MyProduct.UserNameDialog>()
                                .Add<ProgressDialog>()
                                .Add<ExitDialog>();
Everything builds ok, but while installation in InstallDirDialog it shows me ABSOLUTEPATH as dir value. (See picture: https://yadi.sk/i/ENQRR09xkVkSB )
Hence, it installs in right directory : "C:\MyProduct"
I'm using version 1.0.28
Is it an issue or am I doing something wrong?
Thanks
↧
Viewing all 1354 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>