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

New Post: Change Target Install Directory

August 23, 2016, 10:40 am
$
0
0
Hi! I am using WIX# to create MSI for my project. I set the Install Dir in my code as new Dir(@"inetpub\wwwroot", getDirStructure()),. It is installing the setup files to C:\ drive in Dev environment as there is no other disc available but in the Test environment it is installing the setup files to D:\ drive which is creating issue for me. I tried adding the InstallDir as new Dir(@"C:\inetpub\wwwroot", getDirStructure()),but it gave error whilw building the code as the character ":" not allowed. Please suggest how to fix this. How i can set the default Install Dir to "C:\" drive.

Thanks in advance.
↧
Search

New Post: Upgrading program

August 23, 2016, 6:55 pm
$
0
0
  • I just tested the GetProductCode and in my environment it works for both CPU types just fine:
class Program
{
    staticpublicvoid Main(string[] args)
    {
        var installed = AppSearch.IsProductInstalled("{1D6432B4-E24D-405E-A4AB-D7E6D088CBC9}");
        Console.WriteLine(installed);
    }
}
As I explained GetProductCode uses native MsiGetProductInfo (from msi.dll) thus troubleshooting CPU type (or environment) implications of msi.dll interop is outside of Wix# scope. It is a generic .NET problem. You have the code (my prev post) so you can create your own interop that works in your conditions. You can even query registry directly if you need to.
 
  • project.GUID is not a product code. But Project.ProductId is. You can assign it explicitly. If you don't then Wix# will auto allocate it for you. It will be derived from project.GUID. After the build Wix# always prints out the all allocated ids:
 ProductName: MyProduct
 Version    : 1.0.0.0
 ProductId  : {6f330b47-2577-43ad-9095-1861ca25889c}
 UpgradeCode: {6f330b47-2577-43ad-9095-1861ba25889b}
You can also retrieve the auto-generated ProductId after the build:
project.BuildMsi();
Console.WriteLine(project.ProductId);
MSI product identity model is described in this Wix# wiki page: https://wixsharp.codeplex.com/wikipage?title=Deployment%20scenarios#_naming
↧
↧

New Post: Sending data from main function to custom dialog

August 23, 2016, 6:58 pm
$
0
0
Yes.
var project =
    new Project("MyProduct",
        new Dir(@"%ProgramFiles%\My Company\My Product",
            new File(@"Files\Bin\MyApp.exe")),
            new Dir(@"Docs\Manual",
                new File(@"Files\Docs\Manual.txt") { NeverOverwrite = true }),
        new Property("<prop name>", "<prop value>"));
↧

New Post: Change Target Install Directory

August 23, 2016, 7:15 pm
$
0
0
You can set the install dir to the absolute path as in the InstallDir_AbsolutePath sample:
staticpublicvoid Main()
{
    var project = new Project("MyProduct",
                        new Dir(@"D:\MyCompany\MyProduct",
                            new Files(@"files\*.*")));

    project.UI = WUI.WixUI_ProgressOnly;

    Compiler.PreserveTempFiles = true;
    Compiler.BuildMsi(project);
}
BTW yourgetDirStructure()probably does what '*.*' does so you may want to have a look at "WildCard Files" and particularly "Release Folder" samples.

But most likely you want to change the install dir depending on the runtime conditions. This means that you need to update MSI INSTALLDIR property to your desired location just before MSI runtime starts installing the files. This is what usually MSI GUI does. You can modify your ManagedUI (C#) InstallDir dialog to do the runtime INSTALLDIR assignment.

Though a more reliable approach would be to do it in one of the ManagedSetup events. Have a look at "Setup Events" sample. It does exactly that.
↧

New Post: Upgrading program

August 24, 2016, 2:43 am
$
0
0
Thanks a lot.
Is it any way to find out project GUID (UpgradeCode) if I know ProductId.
I can install 2 programs with the same ProductName but different GUIDs. During the upgrading I want to detect program with the same UpgradeCode.
↧
↧

New Post: Upgrading program

August 24, 2016, 3:24 am
$
0
0
> Is it any way to find out project GUID (UpgradeCode) if I know ProductId.
Yes there is. Have a look at Project properties. You will find that it has UpgradeCode.

Checking the upgrade code of the installed product most likely is possible (e.g. with MsiGetProductInfo). Though not sure what exactly is involved.

Normally you never ever need to know UpgradeCode. It only plays any role during an upgrade and it is an operation that a developer never implements directly but relies on MSI Minor/Mojor upgrade process. Something tells me that you may be investing into something that is already dome by MSI. Have a look at MajorUpgrade Wix# samples. The documentation (wiki) also describes the topic.
↧

New Post: Bugs in setting version

August 25, 2016, 1:06 am
$
0
0
Hi, Oleg!
I found 2 bugs:
  1. After project.SetVersionFrom(fileID)
    project.Version isn't changed, it's still 1.0.0.0
    After installing in programs and features version of program is right
  2. After project.SetVersionFromFile(file)
    file version is 5.2.30128.0
    project.Version is 5.2.3.0
↧

New Post: Bugs in setting version

August 25, 2016, 5:49 pm
$
0
0
  1. It is an intended behavior. And the fact that after installing you see the correct version confirms that the feature works. SetVersionFrom isn't supposed to change the the project.Version instead it sets some special WiX instructions so WiX compiler extracts and assigns the version at compile time. The code documentation does reflect this behavior:
    Image
  2. Most likely the file you are specifying does have v5.2.3.0 or it has some inconsistency between AssemblyFile and Assembly version (see the documentation). A simple test (below) reveals that the feature works correctly:
    Image
↧
Search

New Post: Can't understand that the program is uninstalling

August 29, 2016, 2:09 am
$
0
0
Hi!
My installer has ManagedUI.
I click Remove button in MaintenanceTypeDialog. In BeforeInstall event handler e.IsUninstalling is false.
Why is it false?

Remove button click event handler:
void remove_Click(object sender, System.EventArgs e)
{
MsiRuntime.Session["REMOVE"] = "All";

int index = Shell.Dialogs.IndexOf(ProgressDialog);
if (index != -1)
    Shell.GoTo(index);
else
    Shell.GoNext();
}
↧
↧

New Post: Bugs in setting version

August 29, 2016, 2:17 am
$
0
0
I use project.SetVersionFrom(fileID)
After the build Wix# prints out version 1.0.0.0, it's not right.
↧

New Post: Bugs in setting version

August 29, 2016, 4:37 am
$
0
0
Correct. Section #1 in my prev post explains why project.Version is not changed during the build.

If you use SetVersionFrom then Wix# is no longer responsible for setting the product version. This task is delegated to WiX so the whole project.Version value becomes completely irrelevant.

Just to improve the build output accuracy I changed the implementation to include clause about the value and the origin of the new overwritten version for the SetVersionFrom use-case.

If you eager to test it you can grab it from Git (<git>/src/WixSharp.Samples/WixSharp.dll).
↧

New Post: Problem with transfering data

August 30, 2016, 12:41 am
$
0
0
Hi, Oleg!
I have a problem with transfering data from UIInitialized event handler to my custom dialog.

static void project_UIInitialized(SetupEventArgs e)
{
e.Data["TEST"] = "test";
}

void dialog_Load(object sender, EventArgs e)
{
string testData = MsiRuntime.Data["TEST"];
}

MsiRuntime.Data["TEST"] throw KeyNotFoundException in Load form event handler
↧

New Post: Can't understand that the program is uninstalling

August 30, 2016, 12:57 am
$
0
0
Thank you for reporting this. I have created an issue report on your behalf: https://wixsharp.codeplex.com/workitem/138
It is solved in codebase right now and the fix will be available in the next release. But the binaries can be already downloaded from Git.
As a work around you can change your code as this:
MsiRuntime.Session["REMOVE"] = "ALL";
↧
↧

New Post: Uninstall previous version of MSI befor installing a later one

August 30, 2016, 4:08 am
$
0
0
Hi! I am using WIX# to build MSI for my Client. There is a requirement from Client that the MSI installed earlier should be uninstalled automatically while installation of a fresher MSI file i.e. the installed MSI should be uninstalled first programmatically then the newer MSI will be installed.

I am trying do this using the following method:- 
        private static bool uninstallProgram(string ProgramName)
{
            try
            {
                ManagementObjectSearcher mos = new ManagementObjectSearcher(
                  "SELECT * FROM Win32_Product WHERE Name = '" + ProgramName + "'");
                foreach (ManagementObject mo in mos.Get())
                {
                    try
                    {
                        if (mo["Name"].ToString() == ProgramName)
                        {
                            object hr = mo.InvokeMethod("Uninstall", null);
                            return (bool)hr;
                        }
                    }
                    catch (Exception ex)
                    {
                        Console.WriteLine(string.Format("{0}- Exception Occurred: {1}", DateTime.Now, ex.Message + Environment.NewLine + ex.StackTrace + Environment.NewLine + ex.Source));
                        //this program may not have a name property, so an exception will be thrown
                    }
                }

                //was not found...
                return false;

            }
            catch (Exception ex)
            {
                Console.WriteLine(string.Format("{0}- Exception Occurred: {1}", DateTime.Now, ex.Message + Environment.NewLine + ex.StackTrace + Environment.NewLine + ex.Source));
                return false;
            }
        }
But this method is not working the Control Flow hangs up in the line:-
object hr = mo.InvokeMethod("Uninstall", null);

Is there any better approach from WIX# perspective to do this. Please sugges. Thanks in advance.
↧

New Post: Problem with transfering data

August 30, 2016, 4:21 am
$
0
0
Thank you. Yes it is a problem with e.Data: https://wixsharp.codeplex.com/workitem/139.

e.Data dictionary was introduce as an equivalent of Session dictionary but with the ability to survive the journey to the deferred actions. Something that MSI Session cannot do. Though in your case you are not dealing with deferred actions so you don't have to use Data and you can save the data directly in the session dictionary:
staticvoid project_UIInitialized(SetupEventArgs e) 
{
    e.Session["TEST"] = "test";
} 

void dialog_Load(object sender, EventArgs e) 
{
    string testData = MsiRuntime.Session["TEST"];
}
However the defect you have repored is a defect and it needs to be fixed.
The issue is solved now (Git) and I am planing to do the release tomorrow (or so).
↧
Search

New Post: Uninstall previous version of MSI befor installing a later one

August 30, 2016, 11:43 pm
$
0
0
Of course it's hard to comment but because ManagementObjectSearcher is using COM interface under the hood. And there can be many reasons for a failure.

Let's assume that it is a problem with mo.InvokeMethod("Uninstall".... This can be fixed with something more conservative as this:
string productCode = mo["ProductIdentification"]; //not sure about exact name of the property
Process.Start("msiexec.exe", "/u "+productCode).WaitForExit();
If you want to hide the console window of msiexec.exe then you can adjust StartInfo to do so:
process.StartInfo.UseShellExecute = false;
Though quite possibly you don't have to go through this pain. If the product you are installing is the same product that you need to remove then you can find quite a few Upgrading samples in Wix# downloadables. This would be the best approach.

However if it is a different product then indeed you need to uninstall it manually. When doing so please be aware that if you are at active stage of installing the product you cannot do any other MSI activity (e.g. uninstall). Thus if it is in fact what you are doing in your code then your mo.InvokeMethod("Uninstall"... supposed to fail.

MSI only allows a single setup being active at the time. Though having setup GUI collecting user input is not part of this constrain. The "SimplifiedBootstrapper" sample exercises exactly this quality. It installs an additional dependency product from UI sequence before starting the primary installation. In your case you want to uninstall instead of install.

Though... "SimplifiedBootstrapper" is a lab effort to allow chained installs/uninstalls before support for a proper WiX bootstrapper became available. Thus because now Wix# is fully integrated with Burn (WiX bootstrapper building tool) you can evaluate if it can be used for the task. Typically botstrapper chains all required installs and all uninstalls. In your case you are doing a mixed operation uninstall-on-install so I am not sure how and if Burn supports it. You may need to do some research for this.

But... for something "quick and dirty", not as I am promoting it :), you may consider SimplifiedBootstrapper.
↧

New Post: How to use the Language culture

August 31, 2016, 9:37 am
$
0
0
Hi,

I try to use the localize with project.Language = "fr-FR";
but it's stay in en-us. It's seems to only have the WixUI_en-us.wxl embedded in the resource

How can I get the french translate to work?

Martin
↧
↧

New Post: How to use the Language culture

August 31, 2016, 9:25 pm
$
0
0
Hi Martin,

The localisation resources are not part of Wix# but WiX.

Thus some specific languages may (or may not) be included into WiX distributed with Wix#. I am guessing that WiX website may have individual resource packages available for downloading.

Of course you can do the translation by yourself (e.g. CustomUIDialog sample). But considering the wide usage of French someone probably already did the translation and you just need to find it.

This is the one that I found immediately: https://github.com/AnalogJ/Wix3.6Toolset/blob/master/RC0-source/wix36-sources/src/ext/UIExtension/wixlib/WixUI_fr-fr.wxl. Though not sure how good/complete it is.

Cheers,
Oleg
↧

New Post: ExeFileShortcut set working directory to %TEMP%

September 6, 2016, 9:24 am
$
0
0
I have the following code which works great to install my application. However, I need to set the shortcut to the .exe to have the working directory (or "Start in:" on shortcut properties of the icon) set to %TEMP% (which changes on each client PC). I can set the working directory to pretty much any value but %TEMP% or %TMP%. How can I set the working directory to this value?

Thanks.
var project =
      new Project("MYClient",      
          new Dir(@"C:\ZZZ\BBBXXX\CCC\bin\",
          new File(@"Files\XXX\1.dll"),
          new File(@"Files\XXX\2.dll"),
          new File(@"Files\XXX\3.bmp"),
          new File(@"Files\XXX\4.dll"),
          new File(@"Files\XXX\5.dll"),
          new File(@"Files\XXX\6.dll"),
          new File(@"Files\XXX\7.exe")),          
                            
          new Dir(@"%Desktop%",                
            new ExeFileShortcut("{Shortcut}",@"[INSTALLDIR]7.exe",@"{Options}") {  IconFile = @"c:\Temp\logo-Icon.ico" , WorkingDirectory=@"%TEMP%"  }
          ));
              
       project.Version = new Version("8.13.0.{Revision}");
  project.MajorUpgradeStrategy = MajorUpgradeStrategy.Default;

  project.UI = WUI.WixUI_ProgressOnly;
  project.GUID = new Guid("79049b26-354f-425f-a938-3ca77183fb13");
  
  project.PreserveTempFiles = true;
  
  Compiler.BuildMsi(project);
↧

New Post: ExeFileShortcut set working directory to %TEMP%

September 6, 2016, 9:17 pm
$
0
0
There are a few things that prevents your code from working. The temporary directory WiX property name is TempFoder thus you need to encode it as below:
WorkingDirectory="%TempFolder%"//or 
WorkingDirectory="[TempFolder]"//or
WorkingDirectory="TempFolder"
Though I just added to support for %Temp% as well and it will be available in the next release.

The second problem is MSI/WiX but not Wix# related. The WiX Shortcut element must be a Directory or Property identifier (not path). Thus if you have in your wxs file WorkingDirectory="TempFolder" then it is exactly what you need. However there is a problem here and I will illustrate it with the code. This is a fragment from Shortcut sample that has been modified to set working directory for an application shortcut and for the exe (msiexe.exe) shortcut: 
new File(@"AppFiles\MyApp.exe",
    new FileShortcut("MyApp", "INSTALLDIR"), //INSTALLDIR is the ID of "%ProgramFiles%\My Company\My Product" new FileShortcut("MyApp", @"%Desktop%")
    {
        IconFile = @"AppFiles\Icon.ico",
        WorkingDirectory = "%Temp%"
    }),
new ExeFileShortcut("Uninstall MyApp", "[System64Folder]msiexec.exe", "/x [ProductCode]")
{
    WorkingDirectory = "%Temp%"
}),
This would lead to the correct wxs for both shortcuts:
<ShortcutId="INSTALLDIR.Uninstall_MyApp"WorkingDirectory="TempFolder"Target="[System64Folder]msiexec.exe"Arguments="/x [ProductCode]"Name="Uninstall MyApp.lnk"/><ShortcutId="Shortcut.MyApp.exe.MyApp.1"WorkingDirectory="TempFolder"Directory="DesktopFolder"Name="MyApp.lnk"Icon="IconFile1_Icon.ico"IconIndex="0"/>
This also produces correct msi table content:
Image
However for some unknown reason the final result is mixed. One shortcut gets correct working dir another one doesn't:
Image

Meaning that even after fixing your code the final result is not guaranteed.

Cheers
↧
Viewing all 1354 articles
Browse latest View live
Search