Search Results

Search found 1161 results on 47 pages for 'msi'.

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 9/47 | < Previous Page | 5 6 7 8 9 10 11 12 13 14 15 16  | Next Page >

  • Using WIX to install a WMI provider.

    - by Simmen
    I have developed a WMI provider in C# using the System.Management.Instrumentation namespace. I need to install the provider into the GAC and register it with the WMI repository using MSI. How might I accomplish this with WIX?

    Read the article

  • Registering a COM control during installation

    - by Curtis
    One of our applications needs to register a COM control during installation. If a newer version of that control is already registered, we don't want to overwrite it with the older. What are the Windows MSI install conditions I would user to control this? Or is there some other 'best-practice' method I'm not aware of? Thanks

    Read the article

  • WiX installer - Update scenario Custom UI

    - by iulianchira
    For my application I have an .msi developed with WiX. For the update scenario I want to do the following: if the installed version is never than the update version display an error if the installed version is older than the update version show a button with text Update if the installed version is the same as the update version show a button with text Repair I have found how to define custom UI dialogs, but if I create a dialog with all these controls (Error label, Update/Repair buttons) how can I display just the appropriate one according to the situation.

    Read the article

  • Network error during uninstallation

    - by varunp88
    Hi, We are using WiX to create a setup. The installation works fine, but during uninstallation an error says that the [FileName].msi is missing in C:\Windows\Installer and the setup starts rolling back. It is not reproduced in all the machines. It happens only in few machines. Could someone please give a solution to this ? What may be the reason that this happens only in 5 machines out of some 100 machines ? Thanks and Regards, Varun

    Read the article

  • Published software not displayed in Add/Remove Programs

    - by vikramsjn
    I just followed How to use Group Policy to remotely install software in Windows Server 2003 to try publishing a software (MSI file). I could follow all the steps, but the supposedly successfully published software does not appear on client/user machine's Add/Remove Programs. Could some help figure why this may not be working. Update: On reading this question on Experts-Exchange, tried gpresults. Output extract follows: COMPUTER SETTINGS The following GPOs were not applied because they were filtered out XADistribution Filtering: Denied (Security) Default Domain Policy Filtering: Denied (Security)

    Read the article

  • Make wix installation set upgrade to same folder

    - by Magnus Akselvoll
    How can I make a major upgrade to an installation set (MSI) built with Wix install into the same folder as the original installation? The installation is correctly detected as an upgrade, but the directory selection screen is still shown and with the default value (not necessarily the current installation folder). Do I have to do manual work like saving the installation folder in a registry key upon first installing and then read this key upon upgrade? If so, is there any example? Or is there some easier way to achieve this in MSI / Wix? As reference I paste in my current Wix file below: <?xml version="1.0" encoding="utf-8"?> <!-- Package information --> <Package Keywords="Installer" Id="e85e6190-1cd4-49f5-8924-9da5fcb8aee8" Description="Installs MyCompany Integration Framework 1.0.0" Comments="Installs MyCompany Integration Framework 1.0.0" InstallerVersion="100" Compressed="yes" /> <Upgrade Id='9071eacc-9b5a-48e3-bb90-8064d2b2c45d'> <UpgradeVersion Property="PATCHFOUND" OnlyDetect="no" Minimum="0.0.1" IncludeMinimum="yes" Maximum="1.0.0" IncludeMaximum="yes"/> </Upgrade> <!-- Useless but necessary... --> <Media Id="1" Cabinet="MyCompany.cab" EmbedCab="yes" /> <!-- Precondition: .Net 2 must be installed --> <Condition Message='This setup requires the .NET Framework 2 or higher.'> <![CDATA[MsiNetAssemblySupport >= "2.0.50727"]]> </Condition> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="MyCompany" Name="MyCompany"> <Directory Id="INSTALLDIR" Name="Integrat" LongName="MyCompany Integration Framework"> <Component Id="MyCompanyDllComponent" Guid="4f362043-03a0-472d-a84f-896522ce7d2b" DiskId="1"> <File Id="MyCompanyIntegrationDll" Name="IbIntegr.dll" src="..\Build\MyCompany.Integration.dll" Vital="yes" LongName="MyCompany.Integration.dll" /> <File Id="MyCompanyServiceModelDll" Name="IbSerMod.dll" src="..\Build\MyCompany.ServiceModel.dll" Vital="yes" LongName="MyCompany.ServiceModel.dll" /> </Component> <!-- More components --> </Directory> </Directory> </Directory> <Feature Id="MyCompanyProductFeature" Title='MyCompany Integration Framework' Description='The complete package' Display='expand' Level="1" InstallDefault='local' ConfigurableDirectory="INSTALLDIR"> <ComponentRef Id="MyCompanyDllComponent" /> </Feature> <!-- Task scheduler application. It has to be used as a property --> <Property Id="finaltaskexe" Value="MyCompany.Integration.Host.exe" /> <Property Id="WIXUI_INSTALLDIR" Value="INSTALLDIR" /> <InstallExecuteSequence> <!-- command must be executed: MyCompany.Integration.Host.exe /INITIALCONFIG parameters.xml --> <Custom Action='PropertyAssign' After='InstallFinalize'>NOT Installed AND NOT PATCHFOUND</Custom> <Custom Action='LaunchFile' After='InstallFinalize'>NOT Installed AND NOT PATCHFOUND</Custom> <RemoveExistingProducts Before='CostInitialize' /> </InstallExecuteSequence> <!-- execute comand --> <CustomAction Id='PropertyAssign' Property='PathProperty' Value='[INSTALLDIR][finaltaskexe]' /> <CustomAction Id='LaunchFile' Property='PathProperty' ExeCommand='/INITIALCONFIG "[INSTALLDIR]parameters.xml"' Return='asyncNoWait' /> <!-- User interface information --> <UIRef Id="WixUI_InstallDir" /> <UIRef Id="WixUI_ErrorProgressText" />

    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

  • How can I force a major upgrade to not switch to maintenance mode using the old installation package

    - by Brian
    I have an installer that I would like to use for a major upgrade. I have done the following: Increased the version number (from a.b.c to a.b.c+1) Changed the ProductCode Kept the same UpgradeCode Made the appropriate entry in the Upgrade table Changed the component ID of an existing component Changed the name of the installer package Changed the PackageCode Basically I've done everything I can think of to force MSI to treat this as a major upgrade. However, when I attempt to install this new package, the installer log says "Product registered: entering maintenance mode" and proceeds to try to find the old installer file (which fails, since the new installer is in a different folder than was used for the original installation, and wasn't even what I wanted to happen). What am I missing? Why does the installer switch to maintenance mode right away rather than perform the major upgrade? Thanks!

    Read the article

  • Web setup project removes files after upgrade from VS2008 to VS2010

    - by Craig Shearer
    I have a web setup project built using VS2008. I've converted my solution to VS2010 and now when I build my new installer and run the install from the MSI it installs fine, then at the last step, removes all the files it's just installed. I have RemovePreviousVersions set to true. If I turn this off the files remain in place (but I get multiple instances in the Programs and Features in the control panel). If I run the install again, the files reappear. From then on, the files always remain, even when installing another version. So, the problem seems to be with running an installer built using VS2008 and then running the same installer built by VS2010. The upgrade GUIDs on each installer are the same. What is the cause and how can I fix this?

    Read the article

  • WiX, how to prevent files from uninstalling though we forgot to set Permanent="yes"

    - by Doc Brown
    We have a product installer created with Wix, containing a program package ("V1") and some configuration files. Now, we are going to make a major upgrade with a new product code, where the old version of the product is uninstalled and "V2" is installed. What we want is to save one of the configuration files from uninstalling, since it is needed for the V2, too. Unfortunately, we forgot to set the Permanent="yes" option when we delivered V1 (read this question for more information). Here comes the question: is there an easy way of preventing the uninstall of the file anyhow? Of course, we could add a custom action to the script to backup the file before uninstallation, and another custom action to restore it afterwards, but IMHO that seems to be overkill for this task, and might interfere with other parts of the MSI registration process.

    Read the article

  • WiX: .Net 3.5 prerequisite

    - by Mike Pateras
    I have a WiX installer that I would like to check for .Net 3.5, and install it if it does not exist. I have the following lines in my wixproj file: <BootstrapperFile Include="Microsoft.Net.Framework.3.5"> <ProductName>.NET Framework 3.5</ProductName> </BootstrapperFile> <BootstrapperFile Include="Microsoft.Windows.Installer.3.1"> <ProductName>WIndows Installer 3.1</ProductName> </BootstrapperFile> When I create the installer, a DotNetFX35 folder is created, and in it are 4 different versions of .Net (including 3.5), and an installer file. I have two questions: How do I have it only bring in version 3.5 (so that the user doesn't have to install 100+ MB of files)? How do I tell WiX to package these files up into the MSI file, so that the user only has to download 1 file?

    Read the article

  • Choosing an installer product that is free and will download/install the .NET Framework

    - by Coder7862396
    I'm currently using the Visual Studio Installer (Setup Project) in Visual Studio 2010 as the installer for MyProgram. It has some quirky bugs and is not very customizable so I would like to switch to another installer product. Here are my requirements: Must be free (and licensed for commercial use) Must install the Windows Installer 3.1 and .NET Framework 4.0 if the client doesn't have them The installer will download them if they are not available The code for detecting the .NET Framework and downloading it must be written by Microsoft (I do not want to have to update hard-coded URLs and registry keys in the future). I know that the Windows SDK includes a setup bootstrap that does this (C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper) In the future, when .NET Framework 5 is released and MyProgram uses it, no installer code will need to be changed, the updated installer product should see that MyProgram now uses the .NET Framework version 5 and will install that Here are my current choices: Visual Studio Installer: Automatically detects/downloads/installs Windows Installer and .NET Framework using a bootstrapper Setup.exe (Good!) Limited/buggy functionality (Uninstall shortcuts in the Start Menu cause empty folders to be left behind during uninstall, asking the user if they want a desktop shortcut requires a lot of work, etc.) NSIS: Doesn't natively support the .NET Framework so adding it as a prerequisite requires excessive coding, hardcoded URLS, etc. Inno Setup: Doesn't natively support the .NET Framework so adding it as a prerequisite requires excessive coding, hardcoded URLs, etc. WiX: Steep learning curve... not sure if I want to spend weeks learning it only to find out that it has the same uninstall problem as the Visual Studio Installer (because they both use MSI files) InstallShield LE 2010: Downloading it requires me to setup a fake email account to register just to download it. Then once it is installed it has to contact the company's servers and transmit some private information to them before I'm even allowed to try the free version. This is the most insidious form of DRM that there is and I will not accept it.

    Read the article

  • Is it possible to install into Program Files with limited privileges?

    - by Marek
    I have an application that will be deployed as MSI package (authored in WiX). I am deciding whether to specify elevated or limited privileges as required for the installer. The application does not include anything requiring elevated privileges besides the default install location, which is under Program Files. Now the problem: If I specify elevated privileges, then the user is prompted by UAC for administrator password during the installation. This is not required and prevents non-admin users from installing. If I specify limited privileges, then the user is presented with a dialog to select install location with Program Files being default. In case they do not change the install location (95 % of end users probably won't), then the installer will fail with a message that they should contact the Administrator or run the application as administrator. If they launch the installer as Administrator then they can install into Program Files without problem - but most of the users won't probably know how to launch an installer as administrator. I can potentially set the default install location to e.g. C:\Company name\Program\, but this seems nonstandard to me and majority of users will not probably like this (they are probably used to installing into Program Files). How do you solve this problem with installing applications under limited user accounts?

    Read the article

  • WIX installer with Custom Actions: "built by a runtime newer than the currently loaded runtime and cannot be loaded."

    - by Rimer
    I have a WIX installer that executes Custom Actions over the course of install. When I run the WIX installer, and it encounters its first Custom Action, the installer fails out, and I receive an error in the MSI log as follows: Action start 12:03:53: LoadBCAConfigDefaults. SFXCA: Extracting custom action to temporary directory: C:\DOCUME~1\ELOY06~1\LOCALS~1\Temp\MSI10C.tmp-\ SFXCA: Binding to CLR version v2.0.50727 Calling custom action WIXCustomActions!WIXCustomActions.CustomActions.LoadBCAConfigDefaults Error: could not load custom action class WIXCustomActions.CustomActions from assembly: WIXCustomActions System.BadImageFormatException: Could not load file or assembly 'WIXCustomActions' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. File name: 'WIXCustomActions' at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.AppDomain.Load(String assemblyString) at Microsoft.Deployment.WindowsInstaller.CustomActionProxy.GetCustomActionMethod(Session session, String assemblyName, String className, String methodName) ... the specific problem from above is "System.BadImageFormatException: Could not load file or assembly 'WIXCustomActions' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded." The wordage of that error seems to indicate something like an incorrectly referenced .NET framework or something (I'm targeting 3.5 in both my custom actions and its dependencies), but I can't figure out where to make a change to address this problem. Any ideas? .... Not sure if this will help but it's the CustomActions package batch file I run to create the .dll package containing the custom action functions: =============== call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" @echo on cd "C:\development\trunk\PortalsDev\csharp\production\Installers\WIX\customactions\PAServicesWIXCustomActions" csc /target:library /r:"C:\program files\windows installer xml v3.6\sdk\microsoft.deployment.windowsinstaller.dll" /r:"C:\development\trunk\PortalsDev\csharp\production\Installers\WIX\customactions\PAServicesWIXCustomActions\bin\Debug\eLoyalty.PortalLib.dll" /out:"C:\development\trunk\PortalsDev\csharp\production\Installers\WIX\customactions\PAServicesWIXCustomActions\bin\Debug\WIXCustomActions.dll" CustomActions.cs cd "C:\Program Files\Windows Installer XML v3.6\SDK" makesfxca "C:\development\trunk\PortalsDev\csharp\production\Installers\WIX\customactions\PAServicesWIXCustomActions\bin\Debug\BatchCustomerAnalysisWIXCustomActionsPackage.dll" "c:\program files\windows installer xml v3.6\sdk\x86\sfxca.dll" "C:\development\trunk\PortalsDev\csharp\production\Installers\WIX\customactions\PAServicesWIXCustomActions\bin\Debug\WIXCustomActions.dll" customaction.config Microsoft.Deployment.WindowsInstaller.dll

    Read the article

  • WiX - create a bootstrap that passes arguments to the msi

    - by Dror Helper
    I need to create a bootstrap for my WiX project I've tried using setupbld.exe but it will only allow me to create an executable that will show my UI or one that will behave as a silent installer but not both. I need to be able to run the resulting executable with argument that will tell it wether or not to show the UI during installation. I've found this post by John Robbins that explains how to re-build the setup.exe stub used in the creation of the bootstrap but I was hoping there is a simpler way to do what I need. Does anyone know of a way to create a bootstrap that I use to run either as a simple (with UI) install or as a silent install.

    Read the article

  • Missing UAC shield overlay on desktop shortcut icon when created by msi created from VS 2008

    - by Alain Hogue
    I created a setup program to deploy my VBNet program using Visual Studio 2008. Inside this setup program I created a shortcut to the "primary output" to be installed on the user desktop. Now, everything is working correctly. The program is installed under "C:\Program Files" and the shortcut is created on the desktop. Also, when I use this shortcut I am prompted by UAC to autorize running this program as administrator. So far, so good... But! My desktop icon does not have the UAC shield overlay even if the program is compiled with the manifest stating that it must run as administrator. Also, if I manually create a new shortcut on the desktop to the same executable after the installation, this new shortcut WILL have the shield overlay! I have tried to reboot and delete the iconCache.db file but it did not work. So my question is: How can I have my desktop shortcut appear WITH the UAC shield overlay when installed initially. Thanks!

    Read the article

  • Why won't Windows Installer use the UI in the .msi file during removal?

    - by billmcc
    Has anyone been able to get Windows Installer to use the InstallUISequence table during removal? I started with an MSI file produced by the Visual Studio msi builder, decompiled it into WiX source code and handcrafted it, but I cannot get the installer to use my UI during removal. It insists on using a default UI provided by Windows Installer. I have also analyzed several MSI files, and I have been unable to find one where Windows Installer will use the provided UI during removal. I captured the msiexec logs during removal, and sure enough, Windows Installer appears to be ignoring the InstallUISequence table. It seems that msiexec runs with minimal UI during removal. If I specify the /qf switch (use full UI) during removal, then Windows Installer does take the UI from the .msi file. However, this doesn't help the regular user, because she won't do the removal from msiexec. Does anyone know of a way to convince Windows Installer to use the UI in the MSI file by default?

    Read the article

  • Detect an Uninstall in a Launch Condition using Wix MSIs

    - by coxymla
    I've been playing around with Wix, making a little app with auto-generated installer and three versions to test the upgradability, 1.0, 1.1 and 2.0. 1.1 is meant to be able to upgrade from 1.0, and not to allow the user to install 1.1 if 1.1 is already present. <Upgrade Id="F30C4129-F14E-43ee-BD5E-03AA89AD8E07"> <UpgradeVersion Minimum="1.0.0" IncludeMinimum="yes" Maximum="1.0.0" IncludeMaximum="yes" Property="OLDERVERSIONBEINGUPGRADED" /> <UpgradeVersion Minimum="1.1.0" IncludeMinimum="yes" OnlyDetect="yes" Property="NEWERVERSIONDETECTED" /> </Upgrade> <Condition Message="A later version of [ProductName] is already installed. Setup will now exit."> NOT (NEWERVERSIONDETECTED OR Installed) </Condition> Problem #1: 1.1 can't be uninstalled, because the condition is set and checked during the uninstall. 2.0 is meant to be able to upgrade from 1.1, and not to upgrade from 1.0 ('too old'.) It shouldn't be able to install on top of itself either. <Upgrade Id="F30C4129-F14E-43ee-BD5E-03AA89AD8E07"> <UpgradeVersion Minimum="1.1.0" IncludeMinimum="yes" Maximum="1.1.0" IncludeMaximum="yes" Property="OLDERVERSIONBEINGUPGRADED" /> </Upgrade> <Upgrade Id="F30C4129-F14E-43ee-BD5E-03AA89AD8E07"> <UpgradeVersion Minimum="2.0.0" OnlyDetect="yes" Property="NEWERVERSIONDETECTED" /> </Upgrade> <Upgrade Id="F30C4129-F14E-43ee-BD5E-03AA89AD8E07"> <UpgradeVersion Minimum="1.0.0" IncludeMinimum="yes" Maximum="1.0.0" IncludeMaximum="yes" Property="TOOOLDVERSIONDETECTED" /> </Upgrade> <Condition Message="A later version of [ProductName] is already installed. Setup will now exit."> NOT NEWERVERSIONDETECTED OR Installed </Condition> <Condition Message="A version of [ProductName] that is already installed is too old to be upgraded. Setup will now exit."> NOT TOOOLDVERSIONDETECTED </Condition> Problem #2: If I try to upgrade from 1.1, I hit my modified later version condition. (Error: A later version of Main Application 1.1 is already installed. Setup will now exit.) Problem #3: The installer allows me to install 2.0 over the top of itself. What am I doing wrong with my Upgrade code and conditions to get these problems in my MSIs?

    Read the article

  • Wix XmlFile is keeping SqlDatabase from creating databases

    - by Grandpappy
    I've got a Wix project made up of several fragments. One of those fragments has the database components, another has a component that manipulates xml files. When I include the XmlFile element to manipulate a file, the databases defined by the SqlDatabase do not get created. If I comment out the XmlFile, then the databases do get created. Here are the two wix files with fragments that are being used: Database: <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:sql="http://schemas.microsoft.com/wix/SqlExtension"> <Fragment> <DirectoryRef Id="TARGETDIR"> <Component Id="Database1Creation" Guid="GUID_HERE"> <sql:SqlDatabase Id="Database1" Server="[DATABASE_SERVER]" Database="[DATABASE_NAME]" CreateOnInstall="yes" ConfirmOverwrite="no" DropOnUninstall="yes"> </sql:SqlDatabase> </Component> </DirectoryRef> </Fragment> </Wix> Xml Manipulation: <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:sql="http://schemas.microsoft.com/wix/SqlExtension" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"> <Fragment> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="INSTALLDIR" Name="MyDirectory"> <Component Id="ServiceExecutables" Guid="GUID_HERE"> <File Id="File1" Name="File1.xml" Source="Source/File1.xml" /> <util:XmlFile Id="UpdateFile1" File="[INSTALLDIR]File1.xml" Action="setValue" ElementPath="//SomeContainer/SomeElement" Value="[SOME_VALUE]" /> </Component> </Directory> </Directory> </Directory> </Fragment> </Wix> There are other things that are also installed, but they don't appear to have any influence on the issue (I've removed everything else and tested the install). When looking at the install logs when using XmlFile and when not, they are almost exact copies of each other, except that the SqlDatabase calls would be completely missing, and the XmlFile calls would be in their place. Is there a known bug here? Or am I doing something I shouldn't be? This isn't a killer for our app, since I can move the things I'm putting in the xml file into the registry, but I'd rather not do that. I am using Wix 3.5.

    Read the article

  • wix: does INSTALLDIR always end in a slash?

    - by Cheeso
    I think the default dir gets a trailing slash. But what if the user selects a different directory? Is there a way for the INSTALLDIR to NOT have a trailing slash? It's not that I want it to not have a trailing slash. I want to know if I can count on it, so that, for example, [INSTALLDIR]Filter.dll ...will always resolve to a real, valid filesystem path. Currently I use [INSTALLDIR]\Filter.dll and I get a double-slash in there. It's valid and resolves, but I'd like to eliminate the double slash. thanks.

    Read the article

  • WIX Merge Module : Trying to use $(var.Project.TargetFileName)

    - by Stephen Bailey
    I have created a simple Wix 3 Merge Module in VS 2005 ( .wxs ) <?xml version="1.0" encoding="UTF-8"?> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Module Id="TestMergeModule" Language="1033" Version="1.0.0.0"> <Package Id="ef2a568e-a8db-4213-a211-9261c26031aa" Manufacturer="Me" InstallerVersion="200" /> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="MergeRedirectFolder"> <Component Id="Test_ModuleComponent" Guid="{1081C5BC-106E-4b89-B14F-FFA71B0987E1}"> <File Id="Test" Name="$(var.Project.TargetFileName)" Source="$(var.Project.TargetPath)" DiskId="1" /> </Component> </Directory> </Directory> </Module> </Wix> And I have added the project "Project" as a reference to this Merge Module, however I continue to get this error Error 7 Undefined preprocessor variable '$(var.Project.TargetFileName)'. Any suggestions, I am sure I am just missing the obvious here.

    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 | 5 6 7 8 9 10 11 12 13 14 15 16  | Next Page >