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

New Post: registry COM dll

July 15, 2016, 4:58 am
$
0
0
How Registry COM dll in Wix#. In Wix toolset i use heat.exe.
result 
<Component Id="AxCVS1.dll" Guid="{64B778A3-361D-4B60-AF62-E1842E206CA4}">
        <File Id="AxCVS1.dll" KeyPath="yes" Source="G:\TFS\Cameras\Cameras\SetupCameras\DllforReg\AxCVS1.dll">
          <TypeLib Id="{11B2DD15-5613-4EAB-9D46-CF9B52EB5C0B}" Description="AxCVS1 1.0 Type Library" HelpDirectory="CommonFilesFolder" Language="0" MajorVersion="1" MinorVersion="0">
            <AppId Description="AxCVS1" Id="{EBFD3E6B-9613-48DE-857F-234390A76082}">
              <Class Id="{1ACEA3EB-6681-496E-9878-DFC4D0481AF7}" Context="InprocServer32" Description="axcvs Class" ThreadingModel="apartment" Version="1.0" Programmable="yes" SafeForScripting="yes" SafeForInitializing="yes" Control="yes">
                <ProgId Id="AxCVS1.axcvs.1" Description="axcvs Class">
                  <ProgId Id="AxCVS1.axcvs" Description="axcvs Class" />
                </ProgId>
              </Class>
            </AppId>
            <Interface Id="{2406F45E-19C8-4475-896A-7E923AD3CC22}" Name="Iaxcvs" ProxyStubClassId32="{00020424-0000-0000-C000-000000000046}" />
            <Interface Id="{79B62A3A-CB3B-41E7-8D1E-EB4F13CBF354}" Name="_IAxCVSEvents" ProxyStubClassId32="{00020420-0000-0000-C000-000000000046}" />
          </TypeLib>
        </File>
        <RegistryValue Root="HKCR" Key="AppID\AxCVS1.DLL" Name="AppID" Value="{EBFD3E6B-9613-48DE-857F-234390A76082}" Type="string" Action="write" />
        <RegistryValue Root="HKCR" Key="CLSID\{1ACEA3EB-6681-496E-9878-DFC4D0481AF7}\MiscStatus\1" Value="131473" Type="string" Action="write" />
        <RegistryValue Root="HKCR" Key="CLSID\{1ACEA3EB-6681-496E-9878-DFC4D0481AF7}\MiscStatus" Value="0" Type="string" Action="write" />
        <RegistryValue Root="HKCR" Key="CLSID\{1ACEA3EB-6681-496E-9878-DFC4D0481AF7}\ToolboxBitmap32" Value="[#AxCVS1.dll], 103" Type="string" Action="write" />
      </Component>
↧
Search

New Post: registry COM dll

July 16, 2016, 2:46 am
$
0
0
WiX doesn't provide direct support for COM registration And Wix# does rely what WiX offers for COM handling neither.

This means that you will need to rely on WiX recommended approaches mapped to Wix#:
  • Running regsvr32
    • You can run is as WixQuietExecAction. Have a look at "WixQuietExecAction" sample
    • You can run it as C# Process.Start. Have a look at ManagedCA sample or even better run it in BeforeInstall ManagedProject event.
  • Merging heat.exe emitted wxs fragment with main wxs file.
    • You can do this with Project.AddWixFragment:
var comWxs = "<your heat.exe generated wxs file>";
project.AddWixFragment("Wix/Product", XElement.Load(comWxs));
I wouldn't mind even to provide a simple interface for heat.exe. Even prototyped it:
var wxs = Tasks.EmmitComWxs(dll);
However I quickly realized that heat interface is a bit flaky. It immediately emitted:
The harvest type was not found in the list of loaded Heat extensions.
The error was logged in 2013 (https://sourceforge.net/p/wix/bugs/3199/) but it seems at it came back. Thus until it's fixed or some work around found I cannot really integarate it.
↧
↧

New Post: FeaturesDialog and "Back" action

July 16, 2016, 5:38 am
$
0
0
> The Back button is always disabled.
It's just a mistake. An accidental hard-codded Enabled=False.

> After return back to FeaturesDialog the feature tree recreated incorrectly
This one was trickier. The selection state is preserved between navigations. However it was a a deficiency in the selection save/restore algorithm caused by the mismatch in the feature name and feature description.

I have created the Issue#133 for the problem.

The issue has been fixed now in the NuGet release v1.0.41.1
↧

New Post: Error on ManagedUI in XP

July 18, 2016, 7:42 am
$
0
0
Good day.
If you create msi using code like this
projectRT.ManagedUI = new ManagedUI();
project.ManagedUI.InstallDialogs.Add<WelcomeDialog>()
                                            .Add<LicenceDialog>()
                                            .Add<SetupTypeDialog>()
                                            .Add<FeaturesDialog>()
                                            .Add<InstallDirDialog>()
                                            .Add<ProgressDialog>()
                                            .Add<ExitDialog>();

            project.ManagedUI.ModifyDialogs.Add<MaintenanceTypeDialog>()
                                           .Add<FeaturesDialog>()
                                           .Add<ProgressDialog>()
                                           .Add<ExitDialog>();
when you install it on XP, you will get "silent" installations
also e.ManagedUIShell in Project_UILoaded is empty only in xp
Video
http://screencast.com/t/uh6hMNqF
Test project
https://dl.dropboxusercontent.com/u/50919138/WixSharp%20Setup6.zip
↧

New Post: Error on ManagedUI in XP

July 18, 2016, 8:52 am
$
0
0
Hi Satrn,

Can you please test if you can run Custom_UI/EmbeddedUI sample on your XP. It looks like the whole EmbeddedUI MSI model is failing for whatever reason. "e.ManagedUIShell" is just a symptom of the same problem.

Thank you
↧
↧

New Post: Error on ManagedUI in XP

July 18, 2016, 12:02 pm
$
0
0
Same result.
Look at another computer with another virtual xp.
Again no UI
↧

New Post: Error on ManagedUI in XP

July 18, 2016, 9:28 pm
$
0
0
Hm... then it looks like that target system MSI doesn't support EmbeddedUI. "Custom_UI/EmbeddedUI" sample is an extremely lean setup project that doesn't have any Wix# infrastructure. It's purpose is to only demonstrate how to use MSI EmbeddedUI model. As opposite to ManagedUI which is based on EmbeddedUI model and on top of it it deliverers integrated fully redefined custom UI resembling standard MSI UI.

Thus preliminary analysis makes me to interpret the problem as one of these possible scenarios:
  1. WinXP limitations prevents MSI runtime from handling EmbeddedUI. It is quite plausible as EmbeddeUI was brought to MSI much later. It's pure WinXP/MSI problem. Nothing we can do about it.
  2. WinXP has older version of MSI runtime present so the old runtime cannot handle EmbeddedUI from your msi file. It is less probable as most likely MSI runtime would complain about new msi file format. Though I never tested it. It's pure WinXP/MSI problem but it can be fixed by upgrading MSI runtime.
  3. Wix# EmbeddedUI integration has some limitations, which are exposed only on WinXP. It's possible but can only be confirmed by testing. I am travelling right now so it's hard for me to find a PC (or virtual image) with WinXP for testing.
I'll be back next week and see what can be done.
In a mean time can you please use logging to have a look if the runtime even trying to load EmbededUI?
Txs
↧

New Post: Error on ManagedUI in XP

July 18, 2016, 9:53 pm
$
0
0
I just found that I have a copy of virtual XP on my laptop. I will investigate it but a very quick test reveled that runtime reports no error whatsoever. This confirms (not 100% yest) that on XP EmbeddedUI is just ignored. I will do some further research but if you really need to target XP with custom UI then the only choice you have is a CustomCLRDialog. I tested and it works on XP. You will find the sample.
↧
Search

New Post: Error on ManagedUI in XP

July 18, 2016, 10:04 pm
$
0
0
OK. The mystery is solved. EmbeddedUI is stored in the MsiEmbeddedUI table and this table is not supported on Windows Installer 4.0 or earlier.This table is available beginning with Windows Installer 4.5. And WinXP MSI is v3.5. Thus this table is just completely ignored on XP.

This means that the problem cause is #2 item from my prev post. It's strange there is no any warning at runtime, but nothing we can do about that.

Thus will need either prompt user to upgrade MSI or you can use CustomCLRDialog approach. Later one is arguably more practical.
↧
↧

New Post: FeaturesDialog and "Back" action

July 20, 2016, 2:57 am
$
0
0
Oleg, the Issue#133 has fixed.
Thank you!

PS
The source codes contain the weak file "WelcomeDialog.scaling.cs"
We should to remove it manually....
↧

New Post: FeaturesDialog and "Back" action

July 20, 2016, 9:17 am
$
0
0
Thank you.
I also has added the missing file.
↧

New Post: .net Framework installation

July 22, 2016, 7:33 am
$
0
0
I have the following in my project:

static void Main()
    {

        setupproduct();
        string msiproject = buildmsi();

        var bootstrapper = new Bundle(productname,
                                new PackageGroupRef("NetFx461Web"),
                                new MsiPackage(msiproject) { DisplayInternalUI = true });
        bootstrapper.Version = new Version("1.0.0.0");
        bootstrapper.UpgradeCode = new Guid("929339fd-c7c1-43eb-9fad-a24a23b99802");
        bootstrapper.Application = new SilentBootstrapperApplication();
        bootstrapper.Build();

    }
setupproduct just sets the names and stuff about the product in some global strings to make it easier to move to the next product since I have six installs to make if I can manage to get it to work. I'm trying to move to WIx from InnoSetup. (I long for the inno way of installing the .net at this point...)

Then buildmsi is just the standard var project ect that comes with the VS standard template only in a method that returns the BuildMsi.

Everything compiles perfectly if I comment out the bootstrapper. And the resulting MSI installs the product perfectly.

But the bookstrapper is a problem since it errors out with a code of -1. Do you see why its doing it and what I need to do to fix it?

And is SilentBookstrapper the right option? Its the one I saw in the code I found elsewhere in the discussions...

Also another problem is I believe this bootstrapper, if I had written it correctly, will download and install net 4.6.1 if its not already installed. I'd much rather change it to check for a specific net version and then if its not there download and install 4.6.1(or whatever the latest is). Is that possible with WixSharp?
↧

New Post: .net Framework installation

July 22, 2016, 10:16 am
$
0
0
I'm not sure if I've accomplished anything or not but I created this class

public class DotNetFrameworkInstall
{
public static int netversion;
public static string netdownloadversionurl;

[CustomAction]
public static void  InstallNETIfNeeded(SetupEventArgs e)
{
    if (!IsNET4Installed())
    {
        var netFile = System.IO.Path.ChangeExtension(System.IO.Path.GetTempFileName(), ".exe");
        netdownloadToFile(netdownloadversionurl, netFile); 
        System.Diagnostics.Process.Start(netFile).WaitForExit();
    }
}
static bool IsNET4Installed()
{
    using (var key = Microsoft.Win32.Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full\\"))
    {
        if (key == null)
        {
            return false;
        }
        int releaseKey = System.Convert.ToInt32(key.GetValue("Release"));
        return releaseKey >= netversion;
    }
}

static void netdownloadToFile(string url, string file) 
{
    System.Net.WebClient Client = new System.Net.WebClient();
    Client.DownloadFile(url, file);
}
}

Then I assigned the version and the download link to my static class variables
Then added to project.afterinstall += InstallNETIfNeeded;

And that compiles and spits out a msi that installs appropriately.

The problem... all my computers have .net so I don't know if its really working. Is this breaking any rules of Wix or msis?
↧
↧

New Post: .net Framework installation

July 22, 2016, 1:40 pm
$
0
0
I may have discovered a bug.

I was playing around with my original setup without my class and changed the main to this:

static void Main()
    {

        setupproduct();
        string msiproject = buildmsi();

        var bootstrapper = new Bundle(productname+" And Net FrameWork",
                                new PackageGroupRef("NetFx46Web"),
                                new MsiPackage(msiproject) { DisplayInternalUI = true });
        bootstrapper.Version = Tasks.GetVersionFromFile(msiproject); //new Version("1.0.0.0");
        bootstrapper.UpgradeCode = new System.Guid("929339fd-c7c1-43eb-9fad-a24a23b99802");
        bootstrapper.Application = new SilentBootstrapperApplication();
        bootstrapper.OutFileName = productname + "netfx";

        bootstrapper.Build();

    }
That compiles into an exe that will install the program. (Or at least begins to since I hit cancel when the window with the license appeared since its already installed with the msi)

So the problem seemed to be that the bootstrapper didn't like not having a file name assigned (I noticed it was yelling about using setup.exe which is why I looked into changing that) and it also doesn't recognize the PackageRef for net framework 4.6.1 but it does for 4.6.0 and earlier.
↧

New Post: Is Wix# suitable for "larger" installations

July 23, 2016, 12:08 am
$
0
0
Hi,

we are installing about 2500 files.
About 55 COM registrations and a few regasm ones.

Currently we use InstallShield, however I am wondering if Wix# would be suitable for an installation with that many files.
Are there some best practices on how to handle that much files?
I am asking because we kinda want to have more advanced UI ( EmbeddedUI ) and I found Wix# during my searches and now I am thinking about switching the whole project.

Regards
↧
Search

New Post: Is Wix# suitable for "larger" installations

July 23, 2016, 2:23 am
$
0
0
I think the following information/points can help.

Both Wix#/WiX and InstallShield provide an interface for authoring MSI setups. The final result is the same regardless what authoring framework you are using. And both of them are suitable for COM installations. The major difference comes to the user/developer experience.

InstallShield, being wizard based, is more suitable with people with little or no programming experience. It is expensive. InstallShield is also a close system with very little flexibility.

WiX on the other hand is a programming interface so it does require some understanding of the major software development concepts. But it's free and extremely flexible. Certain 'sharp edges' of WiX are leveraged by Wix# via the power of C#.

Thus it all comes down to the level of programming experience the setup developer has.
↧

New Post: .net Framework installation

July 23, 2016, 3:51 am
$
0
0
There are a few things points that you may want to review/scrutinize/collect more info about.

I an not convinced you discovered a bug (at least not just yet). All bootstrapper samples that come with Wix# do not set bootstrapper.OutFileName and all of them build sootstrapper without any problems.

There is nothing wrong with using SilentBookstrapper but I am not sure it is the best choice for your case. You have no other msi (with UI) to chain so having setup without any visual feedback is kind of questionable from UX point of view.

Your very first code snippet is practically identical to the "WixBootstrapper_UI" sample. Thus if you cannot build this sampole then your environment somehow is not ready wor WiX/Wix#. However if you can (build the sample) then you may want to check the difference between your and samples PackageGroupRef/MsiPackage definitions.

> I noticed it was yelling about using setup.exe which is why I looked into changing that...
The latest Burn update made 'setup.exe' file name for the output file illegal. Don't ask! Someone decide it's a great security improvement. Wix# provides a work around for this and if it doesn't work fork for some reason I would really like to have a test case so it can be fixed.


In any case, if you still have problems you can compose a simple 'Hello World' style project and share it so I can have a look at it.
↧
↧

New Post: .net Framework installation

July 23, 2016, 9:00 am
$
0
0
I just commented out the bootstrapper.Application = new SilentBootstrapperApplication(); and that compiled. Hopefully that will show the net stuff...

It could be on my machine.

However if it is a bug, its not in Wix Sharp. Its in the toolset itself. Because I used the BuildCMD to create the Wix source code and tried to compile that.

<?xml version="1.0" encoding="Windows-1252"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="MyProduct And Net FrameWork" Condition="NOT WIX_IS_NETFRAMEWORK_452_OR_LATER_INSTALLED" UpgradeCode="929339fd-c7c1-43eb-9fad-a24a23b99802" Version="1.0.6048.20640" >
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
  <WixStandardBootstrapperApplication LicenseUrl="" xmlns="http://schemas.microsoft.com/wix/BalExtension" />
</BootstrapperApplicationRef>

<Chain>
  <PackageGroupRef Id="NetFx46Web" />

  <MsiPackage DisplayInternalUI="yes" SourceFile="MyProduct.msi">
    <MsiProperty Name="WIXBUNDLEORIGINALSOURCE" Value="[WixBundleOriginalSource]" />
  </MsiPackage>
</Chain>
</Bundle>
</Wix>

That compiles with the target being 4.6.0 framework

But if I change it to the latest 4.6.1 framework with notepad++

<?xml version="1.0" encoding="Windows-1252"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="MyProduct And Net FrameWork" Condition="NOT WIX_IS_NETFRAMEWORK_452_OR_LATER_INSTALLED" UpgradeCode="929339fd-c7c1-43eb-9fad-a24a23b99802" Version="1.0.6048.20640" >
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
  <WixStandardBootstrapperApplication LicenseUrl="" xmlns="http://schemas.microsoft.com/wix/BalExtension" />
</BootstrapperApplicationRef>

<Chain>
  <PackageGroupRef Id="NetFx461Web" />

  <MsiPackage DisplayInternalUI="yes" SourceFile="MyProduct.msi">
    <MsiProperty Name="WIXBUNDLEORIGINALSOURCE" Value="[WixBundleOriginalSource]" />
  </MsiPackage>
</Chain>
</Bundle>
</Wix>

It does not compile. It says error LGHT0094 : Unresolved reference to symbol 'ChainPackageGroup:NetFx461Web' in section 'Bundle: My Product and Net... (There was more to the line but its not part of the screenshot I took of it since it went off screen)

I think they forgot to include <PackageGroupRef Id="NetFx461Web" /> as a valid entry. But it could also be my machine. I'm using the wix 3.10.3.3007 compiler. But I've only been playing with Wix through WixSharp for three days... So...
↧

New Post: .net Framework installation

July 24, 2016, 12:19 am
$
0
0
OK. It kind of makes sense. WiX comes with some packages prepared for you. This applies to NetFx46Web. And most likely the WiX version you are using just doesn't have NetFx461Web included. But not because they forgot but because they just haven't implemented it yet. At least this is what the "unresolved symbol" error indicates. This means that you will need to check if the very latest WiX version includes the package you are interested in and use it (WiX) if it does. However if it doesn't then you have no other choice but to prepare the package by yourself. The WixBootstrapper sample shows how to prepare Web-based package.

Wix# does change the dev experience a lot comparing to the use of raw WiX however it's not the case for Burn (building bootstrappers). This is where Wix# interface is practically identical to the WiX. Thus it doesn't matter much if you are doing it with WiX or with Wix#. The only significant benefit Wix# brings is the ease of building integrating bootstrapper own UI (BA UI).
↧

New Post: .net Framework installation

July 24, 2016, 12:23 am
$
0
0
One thing I forgot to comment.

> I just commented out the bootstrapper.Application = new SilentBootstrapperApplication(); and that compiled...
It shouldn't be like that. SilentBootstrapperApplication shouldn't cause any problems. Can you please send me the copy of your project so I can see if there is any real problem with SilentBootstrapperApplication. And, of course, remove any sensitive content from it.

Thank you.
↧
Viewing all 1354 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>