I have one wix project file abv.wixproj and its product.wxs. I am able to generate its msi file by building it from Visual studio.
I would like to generate msi file using command (i.e. from .bat file).
I would like to generate msi file using nant. I got some code having <target> tag but not sure, in which file should I add this tag. should I create new file or in wsx file.
Kindly help me to share some example of nant commands to generate msi file using command line without Visual studio build
I have tried using "%WIX%bin\candle" *.wxs -o obj\ but it is giving below error
error CNDL0150 : Undefined preprocessor variable
I need one or more commands that will read wxs file and create msi or exe file by executing wix project
The .wixproj is an MSBuild project file. Just use the msbuild task from NAnt and let the targets files handle all the candle and light details for you.
Related
I am trying to package the binaries of an external application in my installer. This external application is managed by another department. There can be multiple versions installed and in multiple locations (ie Program Files and Program Files (x86)). There is a batch file that can find the latest version installed.
What I am trying to do is to dynamically define a preprocessor that matches the location of this external app.
Here is how I proceed.
In the Pre-build Event Command Line of the wix project, I call a batch file.
This batch file finds the path to the external app (ie C:\Program Files (x86)\Foo company\Bar program v3.4) and saves it in an environment variable (%EXTERNAL_APP_PATH%).
Then I call heat with: call "%WIX%bin\heat.exe" dir "%EXTERNAL_APP_PATH%" -cg ExternalAppBinaryFiles -dr INSTALLBINDIR -sreg -srd -var var.ExternalAppBinariesSourceDir -ag -sfrag -out "heat_generated.wxs"
Then I generate a custom file heat_var_ExternalAppBinariesSourceDir.wxs whose content looks like the following:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define ExternalAppBinariesSourceDir = "C:\Program Files (x86)\Foo company\Bar program v3.4" ?>
</Wix>
When building the project, I get the following error: heat_generated.wxs(6,0): error CNDL0150: Undefined preprocessor variable '$(var.ExternalAppBinariesSourceDir)'.
I was expecting that file heat_var_ExternalAppBinariesSourceDir.wxs which define this preprocessor variable would be sufficient for the heat generated file. Mostly because I do include heat_var_ExternalAppBinariesSourceDir.wxs in my project files.
My understanding is that heat generated files only resolves preprocessor variables from "global preprocessor variables" defined in the project properties (under Build section, label "Define preprocessor variables").
If I define this preprocessor variable as ExternalAppBinariesSourceDir=C:\Program Files (x86)\Foo company\Bar program v3.4 in the project properties, the solution builds with no error.
However, I do have to hardcode the path which is the opposite of "dynamically find the path of my application".
A possible solution would be to add a custom include file (*.wxi) in the generated heat file. Is there a way to force my heat generated file to include another file? This way I could generate a custom include file with the preprocessor variable defined.
Maybe I am not using heat as intended. If I omit the -var var.ExternalAppBinariesSourceDir part in the command line, the Source attribute of <File> elements are prefixed with SourceDir\.
The result is a build fail with the following error: error LGHT0103: The system cannot find the file 'SourceDir\myapp.exe'.
Is there a way to have absolute paths for Source attributes in a heat generated file?
I would like to keep the process as lite as possible for people that build the installer. For example, double-click the solution file in File Explorer, the solution opens in Visual Studio, right-click the Wix setup project and select Build.
I have looked at many other wix example. I have not found people that have the same use case as mine. Most use cases hardcode a preprocessor with a relative path to the binaries from the project files. Some suggest to change the arguments to candle.exe/light.exe, but like I said, I build from Visual Studio and does not call light.exe or candle.exe directly.
I suspect that I should be able to specify "search paths" for resolving paths that are prefixed with SourceDir\. Looking at my project properties in Visual Studio, there is a "paths" section, but it is all grayed out. Again, I will need to be able to specify dynamic search paths. The problem is still the same. Also search paths might be problematic if multiple directories have the same filename. This is often problematic when packaging a dll with a standard name.
I am using Visual Studio 2017 and Wix Toolset 3.11.
If you want to use an environment variable as the base for your files, you have a few options. Both MSBuild and WiX provide ways to access environment variables directly:
In MSBuild, environment variables are straight-up available as properties. So you could use $(EXTERNAL_APP_PATH) in your .wixproj and get the path. In particular, you could use it in a DefineConstants property in your .wixproj like:
<PropertyGroup>
<DefineConstants>
$(DefineConstants);
ExternalAppBinariesSourceDir=$(EXTERNAL_APP_PATH)
</DefineConstants>
</PropertyGroup>
In WiX, you can directly reference environment variables in the preprocessor using $(env.EXTERNAL_APP_PATH). That will accomplish the same as the above but without using $(var.ExternalAppBinariesSourceDir) as an intermediary.
The option I would choose is a combination of the above two. I'd use BindPaths (a WiX feature designed to allow you to specify where your files are found) along with the MSBuild support for environment variables by adding the following item to your .wixproj:
<ItemGroup>
<BindInputPath Include="$(EXTERNAL_APP_PATH)" />
</ItemGroup>
Then all the file sources rooted in SourceDir\ will automatically search the list of BindInputPaths from your .wixproj to be found.
The latter option is the most powerful and flexible. But any of the above should get you what you want... assuming you want to use the environment variable. Modifying the above to use an MSBuild property from the command line (or other options) should not be hard either.
I have a Windows application which is built using MSVC and packaged as an .MSI file using WiX. The whole build is managed by cmake and WiX is invoked using the CPackWIX module.
I am now trying to extend the build environment to also build an .APPX package. I am following the official documentation by FireGiant.
After installing the WiX Expansion Pack, I have added the extension FgAppxExtension.wixext by appending it to the variable CPACK_WIX_EXTENSIONS like so:
SET(CPACK_WIX_EXTENSIONS WixUtilExtension FgAppxExtension.wixext)
I have then edited the .wxs source code as indicated here.
The build runs without any errors but creates no .APPX package. It only creates the usual .MSI package. In the wix.log file I see the line:
"C:/Program Files (x86)/WiX Toolset v3.11/bin/light.exe" -nologo -out "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/MyApp-1.15.0+115-default-eb4abec2e9d2+.msi" -ext "FgAppxExtension.wixext" -ext "WixUIExtension" -ext "WixUtilExtension" -cultures:de-DE;en-US "-loc" "C:/dev/MyApp/resources/packaging/win/WIX.Texts.de-DE.wxl" "-loc" "C:/dev/MyApp/resources/packaging/win/WIX.Texts.en-US.wxl" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/directories.wixobj" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/files.wixobj" "F:/dev/AusweisApp2-build/_CPack_Packages/win32/WIX/features.wixobj" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/main.wixobj"
for the .MSI file, but no line for the .APPX package.
The documentation says that after adding a reference to FgAppxExtension.wixext
... the build process will attempt to create AppX packages.
but this does not happen.
Note that adding a wrong extension in the cmake file will result in a build error.
Changing the .wxs source code without adding the extension will also result in an error:
The Product element contains an unhandled extension element 'fga:Appx'.
So I think the FgAppxExtension.wixext extension is loaded correctly, yet no .APPX package is built.
Do you have any hints?
Loading the FgAppxExtension.wixext extension isn't enough to build the .appx package while building the .msi package. FgAppxExtension does that using MSBuild, which isn't in play when using CMake.
When you're not using MSBuild, you can invoke the FireGiant.Appx.exe tool after Light.exe has produced the .msi and .wixpdb files.
I am trying to Publish a .sqlproj from command line with MSBuild with the command:
msbuild /t:Publish [MySqlProjPath] but i get the following error:
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
What i find weird is that from Visual Studio 2012 i can Publish the same project successfully. Does Visual Studio set any magical msbuild property before publishing to get the .targets file from another directory?
You should pass the following argument to MSBuild:
/p:VisualStudioVersion=11.0 /t:Rebuild;Publish
This tells msbuild to use VS2012 targets.
Passing VisualStudioVersion is required hence VS2010 and Vs2012 can share the same project file: i.e. project file does not store target VS version inside itself
I know that I can pass MSBuild a VS solution file (.sln) and it will build the solution but somewhere in the back of my mind, I remember using a MSBuild command line switch that would take a solution file (and it's referenced project files) and generate a single MSBuild project file from them. However, I now can't find this switch!
Was this all a dream?
I see the /preprocess switch (short form /pp) but I don't think that this was it as this will include all of the imported files (including Microsoft.*.targets) and besides I can't seem to get this switch to work. I when I try the following command line, MSbuild generates the *.out file but its empty!
msbuild /target:rebuild /generate MSBuildCopyTargets.sln
The easiest way to do this is to run MSBuild from the command line, with an environment variable set:
Set MSBuildEmitSolution=1
The output will be in the format SolutionName.metaproj
If this is a repeat question, please direct me to the existing solution. I wasn't able to find a matching query.
We currently use InstallShield. I'm attempting to covert a project with 407 files to a WiX3 installation package. I tried using heat.exe to do some of the automation but I get the following warning for almost every file:
c:> heat dir "c:\projectDir\projectA" -gg -ke -template:Product -out "c:\install\projectA\heatOutput"
heat.exe: warning HEAT5150 : Could not harvest data from a file that was expected to be a SelfReg DLL: c:\projectDir\projectA\plugin1.dll. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpful to diagnose the failure: Unable to load file: c:\projectDir\projectA\plugin1.dll, error: 126.
Q: Is it normal for this warning to be reported for every file?
If there's a current "How To create/convert to your first WiX install project with many files" tutorial, please point me to it. The key requirement is "with many files".
PS. I know that WiX is designed for incremental install project creation but it would be nice to know if there's an automated way to convert existing install projects.
If there's a current "How To
create/convert to your first WiX
install project with many files"
tutorial, please point me to it. The
key requirement is "with many files"
You can take the msi file generated with installshield, and then decompile it with the dark.exe tool which comes with wix. As you can see in this diagram, dark.exe generates wxs files from a msi file.
You can use it like this:
dark installer.msi decompiled.wxs
See dark /? for more information.
edit: I don't use Votive, but AFAIK it should be able to handle the wxs files generated by dark. Did Votive show you an error?
edit2: wixproj files are just for visual studio and msbuild integration. The core tools don't know or use this format. Simply create a blank wixproj and add the wxs file to it from visual studio.
edit3: You should not compare the size of the wxs file to the msi file size. Like an installshield project file, a wxs does not contain the files to install. It only references them. Your installshield project file is not 70MB large either. If you want to extract the binary files from the MSI, then you should use dark.exe with the -x <path> switch.
Are you trying to extract data from x64 DLL's? That doesn't really work...