Search Results

Search found 320 results on 13 pages for 'wix'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 6/13 | < Previous Page | 2 3 4 5 6 7 8 9 10 11 12 13  | Next Page >

  • How can my WiX uninstall restore a registry value change?

    - by Thomas
    The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.

    Read the article

  • WiX custom action with DTF... quite confused...

    - by Joshua
    Okay, I have decided the only way I can do what I want to do with WiX (thanks to an old installer I didn't write that I now have to upgrade) is with some CUSTOM ACTIONS. Basically, I need to back up a file before the RemoveExistingProducts and restore that file again after RemoveExistingProducts. I think this is what's called a "type 2 custom action." The sequencing I think I understand, however, what I don't understand is first of all how I pass data to my C# action (the directory the file is in from the WiX) and how to reference my C# (DTF?) action with the Binary and CustomAction tags. Also, does all this need to be in a tag? All the examples show it that way. Here is what I have so far in the .WXS file... <Binary Id="backupSettingsAction.dll" SourceFile="backupSettingsAction.CA.dll"/> <CustomAction Id="BackupSettingsAction" BinaryKey="backupSettingsAction.dll" DllEntry="CustomAction" Execute="immediate" /> <InstallExecuteSequence> <Custom Action="backupSettingsAction.dll" Before="InstallInitialize"/> <RemoveExistingProducts After="InstallFinalize" /> <Custom Action="restoreSettingsAction.dll" After="RemoveExistingFiles"/> </InstallExecuteSequence> The file I need to back up is a settings file from the previous install (which needs to remain intact), it is located in the directory: <Directory Id="CommonAppDataFolder" Name="CommonAppData"> <Directory Id="CommonAppDataPathways" Name="Pathways" /> </Directory> And even has a Component tag for it, though I need to back the file up that exists already: <Component Id="Settings" Guid="A3513208-4F12-4496-B609-197812B4A953" NeverOverwrite="yes" > <File Id="settingsXml" ShortName="SETTINGS.XML" Name="Settings.xml" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\Settings\settings.xml" Vital="yes" /> </Component> And this is referencing the C# file that Visual Studio (2005) created for me: namespace backupSettingsAction { public class CustomActions { [CustomAction] public static ActionResult CustomAction1(Session session) { session.Log("backing up settings file"); //do I hardcode the directory and name of the file in here, or can I pass them in? return ActionResult.Success; } } } Any help is greatly apprecaited. Thank you!

    Read the article

  • How to register file types/extensions with a WiX installer?

    - by OregonGhost
    I didn't find an explicit answer to this question in the WiX Documentation (or Google, for that matter). Of course I could just write the appropriate registry keys in HKCR, but it makes me feel dirty and I'd expect this to be a standard task which should have a nice default solution. For bonus points, I'd like to know how to make it "safe", i.e. don't overwrite existing registrations for the file type and remove the registration on uninstall only if it has been registered during installation and is unchanged.

    Read the article

  • Stuck on preserving config file in WIX major upgrade!

    - by Joshua
    ARGH! Wix is driving me crazy. So, of course I have seen the many posts both here on stackoverflow and elsewhere about WiX and major upgrades. I inherited this software project using WiX and am releasing a new version. I need this new version to leave ONLY the one configuration file if it's present, and replace everything else. This installer works EXCEPT no matter what I have done so far, the new XML file replaces the old on every install. Even attempting to use NeverOverwrite="yes" and even trying and messing back and forth with OnlyDetect="no"! I am simply stuck and humbly request a little guidance. The file that needs to be preserved is called SETTINGS.XML and is in the All Users-ApplicationData directory. Here is (most of) my .wxs file! <Package Id='$(var.PackageCode)' Description="Pathways Directory Software" InstallerVersion="301" Compressed="yes" /> <WixVariable Id="WixUILicenseRtf" Value="License.rtf" /> <Media Id="1" Cabinet="Pathways.cab" EmbedCab="yes" /> <Upgrade Id="$(var.UpgradeCode)"> <UpgradeVersion OnlyDetect="no" Maximum="$(var.ProductVersion)" IncludeMaximum="no" Language="1033" Property="OLDAPPFOUND" /> <UpgradeVersion Minimum="$(var.ProductVersion)" IncludeMinimum="yes" OnlyDetect="no" Language="1033" Property="NEWAPPFOUND" /> </Upgrade> <!-- program files directory --> <Directory Id="ProgramFilesFolder"> <Directory Id="INSTALLDIR" Name="Pathways"/> </Directory> <!-- application data directory --> <Directory Id="CommonAppDataFolder" Name="CommonAppData"> <Directory Id="CommonAppDataPathways" Name="Pathways" /> </Directory> <!-- start menu program directory --> <Directory Id="ProgramMenuFolder"> <Directory Id="ProgramsMenuPathwaysFolder" Name="Pathways" /> </Directory> <!-- desktop directory --> <Directory Id="DesktopFolder" /> </Directory> <Icon Id="PathwaysIcon" SourceFile="\\Fileserver\Release\Pathways\Latest\Release\Pathways.exe" /> <!-- components in the reference to the install directory --> <DirectoryRef Id="INSTALLDIR"> <Component Id="Application" Guid="EEE4EB55-A515-4872-A4A5-06D6AB4A06A6"> <File Id="pathwaysExe" Name="Pathways.exe" DiskId="1" Source="\\Fileserver\Release\Pathways\Latest\Release\Pathways.exe" Vital="yes" KeyPath="yes" Assembly=".net" AssemblyApplication="pathwaysExe" AssemblyManifest="pathwaysExe"> <!--<netfx:NativeImage Id="ngen_Pathways.exe" Platform="32bit" Priority="2"/> --> </File> <File Id="pathwaysChm" Name="Pathways.chm" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\Pathways.chm" /> <File Id="publicKeyXml" ShortName="RSAPUBLI.XML" Name="RSAPublicKey.xml" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\RSAPublicKey.xml" Vital="yes" /> <File Id="staticListsXml" ShortName="STATICLI.XML" Name="StaticLists.xml" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\StaticLists.xml" Vital="yes" /> <File Id="axInteropMapPointDll" ShortName="AXMPOINT.DLL" Name="AxInterop.MapPoint.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\AxInterop.MapPoint.dll" Vital="yes" /> <File Id="interopMapPointDll" ShortName="INMPOINT.DLL" Name="Interop.MapPoint.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\Interop.MapPoint.dll" Vital="yes" /> <File Id="mapPointDll" ShortName="MAPPOINT.DLL" Name="MapPoint.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\Interop.MapPoint.dll" Vital="yes" /> <File Id="devExpressData63Dll" ShortName="DAAT63.DLL" Name="DevExpress.Data.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.Data.v6.3.dll" Vital="yes" /> <File Id="devExpressUtils63Dll" ShortName="UTILS63.DLL" Name="DevExpress.Utils.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.Utils.v6.3.dll" Vital="yes" /> <File Id="devExpressXtraBars63Dll" ShortName="BARS63.DLL" Name="DevExpress.XtraBars.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.XtraBars.v6.3.dll" Vital="yes" /> <File Id="devExpressXtraNavBar63Dll" ShortName="NAVBAR63.DLL" Name="DevExpress.XtraNavBar.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.XtraNavBar.v6.3.dll" Vital="yes" /> <File Id="devExpressXtraCharts63Dll" ShortName="CHARTS63.DLL" Name="DevExpress.XtraCharts.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.XtraCharts.v6.3.dll" Vital="yes" /> <File Id="devExpressXtraEditors63Dll" ShortName="EDITOR63.DLL" Name="DevExpress.XtraEditors.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.XtraEditors.v6.3.dll" Vital="yes" /> <File Id="devExpressXtraPrinting63Dll" ShortName="PRINT63.DLL" Name="DevExpress.XtraPrinting.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.XtraPrinting.v6.3.dll" Vital="yes" /> <File Id="devExpressXtraReports63Dll" ShortName="REPORT63.DLL" Name="DevExpress.XtraReports.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.XtraReports.v6.3.dll" Vital="yes" /> <File Id="devExpressXtraRichTextEdit63Dll" ShortName="RICHTE63.DLL" Name="DevExpress.XtraRichTextEdit.v6.3.dll" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\DevExpress.XtraRichTextEdit.v6.3.dll" Vital="yes" /> <RegistryValue Id="PathwaysInstallDir" Root="HKLM" Key="Software\Tribal Data Resources\Pathways" Name="InstallDir" Action="write" Type="string" Value="[INSTALLDIR]" /> </Component> </DirectoryRef> <!-- application data components --> <DirectoryRef Id="CommonAppDataPathways"> <Component Id="CommonAppDataPathwaysFolderComponent" Guid="087C6F14-E87E-4B57-A7FA-C03FC8488E0D"> <CreateFolder> <Permission User="Everyone" GenericAll="yes" /> </CreateFolder> <RemoveFolder Id="CommonAppDataPathways" On="uninstall" /> <RegistryValue Root="HKCU" Key="Software\TDR\Pathways" Name="installed" Type="integer" Value="1" KeyPath="yes" /> <File Id="settingsXml" ShortName="SETTINGS.XML" Name="Settings.xml" DiskId="1" Source="\\fileserver\Release\Pathways\Dependencies\Settings\settings.xml" Vital="yes" /> </Component> <Component Id="Database" Guid="1D8756EF-FD6C-49BC-8400-299492E8C65D"> <File Id="pathwaysMdf" Name="Pathways.mdf" DiskId="1" Source="\\fileserver\Shared\Databases\Pathways\SystemDBs\Pathways.mdf" /> <RemoveFile Id="pathwaysLdf" ShortName="Pathways.ldf" Name="Pathways_log.LDF" On="uninstall" /> </Component> </DirectoryRef> <!-- shortcut components --> <DirectoryRef Id="DesktopFolder"> <Component Id="DesktopShortcutComponent" Guid="1BF412BA-9C6B-460D-80ED-8388AC66703F"> <Shortcut Id="DesktopShortcut" Target="[INSTALLDIR]Pathways.exe" Name="Pathways" Description="Pathways Tribal Directory" Icon="PathwaysIcon" Show="normal" WorkingDirectory="INSTALLDIR" /> <RegistryValue Root="HKCU" Key="Software\TDR\Pathways" Name="installed" Type="integer" Value="1" KeyPath="yes"/> </Component> </DirectoryRef> <DirectoryRef Id ="ProgramsMenuPathwaysFolder"> <Component Id="ProgramsMenuShortcutComponent" Guid="83A18245-4C22-4CDC-94E0-B480F80A407D"> <Shortcut Id="ProgramsMenuShortcut" Target="[INSTALLDIR]Pathways.exe" Name="Pathways" Icon="PathwaysIcon" Show="normal" WorkingDirectory="INSTALLDIR" /> <RemoveFolder Id="ProgramsMenuPathwaysFolder" On="uninstall"/> <RegistryValue Root="HKCU" Key="Software\TDR\Pathways" Name="installed" Type="integer" Value="1" KeyPath="yes"/> </Component> </DirectoryRef> <Feature Id="App" Title="Pathways Application" Level="1" Description="Pathways software" Display="expand" ConfigurableDirectory="INSTALLDIR" Absent="disallow" AllowAdvertise="no" InstallDefault="local"> <ComponentRef Id="Application" /> <ComponentRef Id="CommonAppDataPathwaysFolderComponent" /> <ComponentRef Id="ProgramsMenuShortcutComponent" /> <Feature Id="Shortcuts" Title="Desktop Shortcut" Level="1" Absent="allow" AllowAdvertise="no" InstallDefault="local"> <ComponentRef Id="DesktopShortcutComponent" /> </Feature> </Feature> <Feature Id="Data" Title="Database" Level="1" Absent="allow" AllowAdvertise="no" InstallDefault="local"> <ComponentRef Id="Database" /> </Feature> <!-- <UIRef Id="WixUI_Minimal" /> --> <UIRef Id ="WixUI_FeatureTree"/> <UIRef Id="WixUI_ErrorProgressText"/> <UI> <Error Id="2000">There is a later version of this program installed.</Error> </UI> <CustomAction Id="NewerVersionDetected" Error="2000" /> <InstallExecuteSequence> <RemoveExistingProducts After="InstallFinalize"/> </InstallExecuteSequence> </Product>

    Read the article

  • Wix, Launch application after installation complete, with UAC turned on.

    - by Christopher Roy
    Good day. I've been building an installer for our product using the WIX(Windows Installer XML) technology. The expected behavior is that the product is launched, if the check box is checked after installation. This has been working for some time now, but we found out recently that UAC of Win 7, and Vista is stopping the application from launching. I've done some research and it has been suggested to me that I should add the attributes Execute='deferred' and Impersonate='no'. Which I did, but then found out that to execute deferred, the CustomAction has to be performed, between the InstallInitialize, and IntallFinalize phases; which is not what I need. I need the product to launch AFTER install finalize, IF the launch checkbox is checked. Is there any other way to elevate permissions? Any and all answers, suggestions, or resonings will be appreciated. Cheers, Christopher Roy.

    Read the article

  • Wix light.exe : error LGHT0001: The system cannot open the device or file specified.

    - by Angelo
    Today we build our product with MSBuild /m to build with multiprocess. Before we do a change to heat some files in pre-build event, build with MSBuild multiprocess can be success. Now build is failed with following exception: 124light.exe : error LGHT0001: The system cannot open the device or file specified. (Exception from HRESULT: 0x8007006E) [...MSI.wixproj] Exception Type: System.IO.FileLoadException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.MergeMod.IMsmMerge2.OpenModule(String fileName, Int16 language) at Microsoft.Tools.WindowsInstallerXml.Binder.MergeModules(String tempDatabaseFile, Output output, FileRowCollection fileRows, StringCollection suppressedTableNames) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) (Link target) - light.exe : error LGHT0001: The system cannot open the device or file specified. (Exception from HRESULT: 0x8007006E) [...Msi.wixproj] using Wix 3.8

    Read the article

  • How do I install an ASP.Net MVC application on IIS 7 using Wix?

    - by Simon Steele
    For IIS6 I can use the IIS helpers in Wix to install a web application like this: <iis:WebAppPool Id="AP_MyApp" Name="My Application Pool" Identity="networkService" /> <iis:WebApplication Id="WA_MyApp" Name="MyApp" WebAppPool="AP_MyApp"> <iis:WebApplicationExtension CheckPath="no" Executable="[NETFRAMEWORK20INSTALLROOTDIR]aspnet_isapi.dll" Verbs="GET,HEAD,POST"/> </iis:WebApplication> Unfortunately, this doesn't work for IIS7. We don't want to use the aspnet_isapi.dll mechanism, and instead want the integrated pipeline to handle the request routing. The app pool created by this script is in Classic mode not Integrated mode so none of the handlers get run correctly. How can I correctly install an MVC app on IIS 7?

    Read the article

  • WIX: How can I register a new ISAPI Extension or Script Map on an existing Web App or Site?

    - by Cheeso
    I've seen the WebApplicationExtension element, but because it must be a child of WebApplication, it appears to require the creation of a new WebApplication. I don't want that. I want to create the extension (or script map) on an existing website. On uninstall, the website should remain but the extension (script map entry) should be removed. Anyone know how to do this in WIX? If I get no good answers, I guess I will have to do it within script before InstallFinalize.

    Read the article

  • WIX/DTF - How do I elevate deffered managed custom actions?

    - by Jarrod
    We are working on creating an installer using WIX. We have a couple of custom actions that are going to require elevation to run on Vista. Our MSI obviously elevates itself, because I get a UAC prompt and it writes keys to HKLM. Our managed DTF custom actions are apparently not running elevated. If I start the MSI from an elevated command prompt, the installation runs fine. The only workaround I have seen suggested (link) is to use another exe with a manifest as a bootstrapper to run the MSI. This is not a good solution, as it doesn't allow the user to modify the installation by selecting "Change" from the Add/Remove programs dialog. Our install has multiple features that can be customized, so we want this functionality. Does anybody know how to do this?

    Read the article

  • How can I deal with the ICE60 warning in WiX?

    - by Scott Boettger
    Good Afternoon, I have created a WiX project that installs a bunch of different EXEs and DLLs. Unfortunatly when I build the project I receive the following warning for each one of them: ICE60: The file fileName is not a Font, and its version is not a companion file reference. It should have a language specified in the Language column. I have found examples and possible solutions for this and each time it is suggested to set the DefaultLanguage tag to 0 in order to fix the warning. Once doing that I then get this warning: The DefaultLanguage '0' was used for file 'fileName' which has no language or version. For unversioned files, specifying a value for DefaultLanguage is not neccessary and it will not be used when determining file versions. Remove the DefaultLanguage attribute to eliminate this warning. So this leads me to the question of how can I handle this warning? Thanks in advance for any and all help given.

    Read the article

  • How can I launch an application as Administrator after a WiX MSI has completed?

    - by ray dey
    Hi there I want to launch an application with admin rights after I have completed an installation using a WiX based MSI. I can launch the application just fine, on XP but with Windows 7, it's an issue. The application has a manifest embedded in it that says it should run as administrator and I've changed the impersonate attribute in the Custom Action to "no". I can't change the execute attribute to deferred, as this only works before the InstallFinalize action and I need it after the user has clicked Finish in the MSI. This is my Custom Action: <CustomAction Id="LaunchApp" FileKey="App" ExeCommand="[Command Line Args]" Execute="immediate" Impersonate="no" Return="asyncNoWait" /> Any help on this would be appreciated. Thanks

    Read the article

  • WiX - How do I prevent ComPlusAssembly being unregistered during uninstall?

    - by Duncan Watts
    As part of my Installer, I am adding files to an existing COM+ package. I have defined a ComPlusApplication underneath my Product element, which has the name set to a property - I then have a custom action which looks up that property - all good so far. When the installer adds the files, within the same component I have added a ComPlusAssembly which adds the assembly to the ComPlusApplication I defined above - this is also working correctly. When uninstalled however, I am receiving an error related to being unable to find the COM+ application, this is because I am not running my custom action to look up the name of the COM+ package. Basically I do not want to remove my files or unregister the component package as part of the uninstallation process - How do I achieve this? I am using WiX 3.0 with VS2008. Thanks

    Read the article

  • WIX: How to register an Application to a URL Protocol?

    - by NOP slider
    In WIX 3.5 you can register file types easily: <ProgId Id="MyApp.File" Description="MyApp File" Icon="MyAppEXE" IconIndex="0"> <Extension Id="ext" ContentType="application/x-myapp-file"> <Verb Id="open" Command="&amp;Open" TargetFile="MyAppEXE" Argument="&quot;%1&quot;"/> </Extension> </ProgId> What if I want to register an URL protocol, as specified here? Obviously, it has no extension so where would I put the Verb tag? Or should I use another approach? Thanks.

    Read the article

  • Initialise a wix CheckBox's check state based on a property?

    - by MauriceL
    How does one initalise a Wix check box based on the value of a property? So far, I've done the following: <Control Id="Checkbox" Type="CheckBox" X="0" Y="0" Width="100" Height="15" Property="CHECKBOX_SELECTION" Text="I want this feature" CheckBoxValue="1" TabSkip="no"> <Condition Action="hide">HIDE_CHECKBOX</Condition> <Condition Action="show">NOT HIDE_CHECKBOX</Condition> </Control> Currently I have two custom actions to set HIDE_CHECKBOX and CHECKBOX_SELECTION. The CHECKBOX_SELECTION custom action occurs immediately after the HIDE_CHECKBOX action. What I'm seeing is that HIDE_CHECKBOX is behaving correctly (ie. the checkbox is hidden) which suggests that I've got the ordering of custom actions correct, but CHECKBOX_SELECTION is not changing the check state of the check box. Is this a safe assumption? Also, I've confirmed that SELECTION is being set to '1' in the logs.

    Read the article

  • How do I make a WiX 3.5 installer with a completely self-contained .NET 4.0 installer?

    - by mmr
    Continuing a previous question I asked here, I now need to move to vs2010. I've gotten the most recent weekly build of WiX 3.5, the June 5th 2010 version. Here's the relevant lines from my installer: <ItemGroup> <BootstrapperFile Include="Microsoft.Net.Framework.4.0"> <ProductName>.NET Framework 4.0</ProductName> </BootstrapperFile> <BootstrapperFile Include="Microsoft.Windows.Installer.4.5"> <ProductName>Windows Installer 4.5</ProductName> </BootstrapperFile> </ItemGroup> and <GenerateBootstrapper ApplicationFile="MySetup.msi" ApplicationName="MyProgram" BootstrapperItems="@(BootstrapperFile)" Path="C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\" ComponentsLocation="Relative" OutputPath="$(OutputPath)" Culture="en" /> However, it's just not working. In vs2010, there are exclamation points next to the .NET Framework 4.0 and Windows Installer 4.5 files, and the properties page lists them as 'Unknown BuildAction BootstrapperFile', and the build just does not appear to install .NET 4.0 at all. The relevant warning is: C:\source\depot\project\vs2010\WiXSetup\WiXSetup.wixproj(68,5): warning MSB3155: Item 'Microsoft.Net.Framework.4.0' could not be located in 'C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\'.

    Read the article

  • How to install a desktop shortcut (to a batch file) from a WiX-based installer that has "Run as Admi

    - by arathorn
    I'm installing a desktop shortcut (to a batch file) from a WiX-based installer -- how do I automatically configure this shortcut with the "Run as Administrator" setting enabled? The target OS is Windows Server 2008 R2, and the installer is running with elevated priveleges. Update: Thanks to the link provided by @Anders, I was able to get this working. I needed to do this in a C# CustomAction, so here is the C# version of the code: namespace CustomAction1 { public class CustomAction1 { public bool MakeShortcutElevated(string file_) { if (!System.IO.File.Exists(file_)) { return false; } IPersistFile pf = new ShellLink() as IPersistFile; if (pf == null) { return false; } pf.Load(file_, 2 /* STGM_READWRITE */); IShellLinkDataList sldl = pf as IShellLinkDataList; if (sldl == null) { return false; } uint dwFlags; sldl.GetFlags(out dwFlags); sldl.SetFlags(dwFlags | 0x00002000 /* SLDF_RUNAS_USER */); pf.Save(null, true); return true; } } [ComImport(), Guid("00021401-0000-0000-C000-000000000046")] public class ShellLink { } [ComImport(), InterfaceType(ComInterfaceType.InterfaceIsIUnknown), Guid("45e2b4ae-b1c3-11d0-b92f-00a0c90312e1")] interface IShellLinkDataList { void GetFlags(out uint pdwFlags); void SetFlags(uint dwFlags); } }

    Read the article

  • How to create share for a whole drive under WiX?

    - by mem64k
    I would like to create a share for a whole drive in my WiX installer project. The default approach for share creation works just fine for folders, but not for drives! The following code snippet illustrates the problem: <!-- Works! --> <Property Id="MySharePath"><![CDATA[X:\ROOT]]></Property> <!-- Works NOT! <Property Id="MySharePath"><![CDATA[X:\]]></Property> --> <Directory Id="MySharePath" Name="."> <Component Id="C__AddShare" Guid="$(var.GuidAddhare)" KeyPath="no" Permanent="yes"> <CreateFolder/> <!-- Create necessary share --> <util:FileShare Id="MY_SHARE" Name="MY_SHARE" Description="MY_SHARE"> <util:FileSharePermission ChangePermission="yes" CreateChild="yes" CreateFile="yes" Delete="yes" DeleteChild="yes" GenericAll="yes" GenericExecute="yes" GenericRead="yes" GenericWrite="yes" Read="yes" ReadAttributes="yes" ReadExtendedAttributes="yes" ReadPermission="yes" Synchronize="yes" TakeOwnership="yes" Traverse="yes" User="LukeSkywalker" WriteAttributes="yes" WriteExtendedAttributes="yes"/> </util:FileShare> </Component> </Directory> Does anybody has a hint for this?

    Read the article

  • Creating a MSI patch (.msp) by hand?

    - by Jerry Chong
    Our team has recently been considering pushing out a minor registry fix to users to modify one particular problematic key. Pretty straightforward stuff, just needed to update 1 key/value inside the registry. So at the moment, we are using Wix to build .msi installers for the product. While looking into Wix's support for generating .msp patch files, it seems that the only way to create an .msp is a somewhat overcomplicated multi-step process to: Get a copy of the original MSI, and compile a new copy of the fixed MSI Write a new Wix file that points to both installers Compile the Wix file into a .wixobj with Candle to a .psp Run Torch/Pyro over before/after snapshots of the original installers and the .psp, or alternatively using MsiMsp.exe Now my question is, can't I simply describe the registry change into a Wix file and directly compile it into the .msp, without step 1 and 4 - which is a huge amount of effort for just a simple change?

    Read the article

  • Installing Win32 shared SxS policy via WiX 3.0 MSM fails for 2nd app

    - by dr-stevep
    I am attempting to author a merge module for use by multiple application installers to install a Win32 Shared SxS Assembly and its associated Policy. I'm using WiX 3.0 to generate the MSM and test MSIs. So far it works fine for the first app installer that runs … but the second app installer fails because the Policy file already exists (HRESULT: 0x800700B7). What requirement(s) for correct Win32 Shared SxS Policy installation am I missing? I have submitted WiX bug 3005301 for this (https://sourceforge.net/tracker/?func=detail&atid=642714&aid=3005301&group_id=105970) and posted VS2008 projects that reproduce the problem. URL: ftp.digital-rapids.com/upload/SteveP/ User: drc-support Password: drc-support Link: ftp://drc-support:[email protected]/upload/SteveP/ wix-Bugs-3005201.rar contains a VS2008 solution that builds the MSM and MSIs that reproduce the issue. (~3MB) wix-Bugs-3005301_Output.rar contains the generated MSM, MSI, and wixpdb files (~40MB)

    Read the article

  • Wix - How do I specify a directory to run a batch file in?

    - by Mike Pateras
    I want to run a batch file, which I do via the following: <CustomAction Id='InstallFilter' FileKey='install' ExeCommand='' Execute='deferred' /> <InstallExecuteSequence> <Custom Action='InstallFilter' Before='InstallFinalize' /> </InstallExecuteSequence> This will execute the batch file, but it runs in C:\Windows\System32 (or something like that). I want it to run in the directory that the file is found in. It won'et let me specify a Directory attribute with a FileKey attribute. How can I tell the installer to run out of a specific directory, preferably by the directory ID. Also, when I try to uninstall my app with script, I get an error message saying "There is a problem with the Windows Installer package. A program required for the install to complete could not be run." This makes sense, as by the time the script gets run, the files have been removed. The question is: How do I specify that my action should only be run on install, not uninstall? How do I uninstall this current copy?

    Read the article

  • How to run a custom action after install which can run in quiet or a UI after Install (WIX)

    - by Jamie
    Hi, I basically want to able to run an command line tool that already exists on the desired machine against the directory the files were run to. I.e The Installer does the following: Specify a location for the files to go into (INSTALLOCATION variable) Then after copying has finished run a tool which will zip the files and attach them to attach them to another application. <CustomAction Id="InstallTo" Return="check" Directory="INSTALLLOCATION" Execute="immediate" ExeCommand='"C:\MyTool\Here\Tool.exe" -ad [INSTALLLOCATION] Poop 1.0'/> <InstallExecuteSequence> <Custom Action="InstallTo" After="InstallFinalize">$InstallTo&gt;2</Custom> </InstallExecuteSequence> At the moment I'm not sure anyuthing is being called, is there a way to basically have this two step install and report progress if the tool failed/doesn't exist etc. Thanks, Jamie

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 2 3 4 5 6 7 8 9 10 11 12 13  | Next Page >