The PropertyGroup MSBUILD Task on WIX lets you set the LinkerBaseInputPaths property, its essentially the -b parameter for light.exe.
The property is named plural for multiple paths (which light.exe supports by multiple -b arguments), however how do we specify multiple paths on the property?
I have tried separating the paths with ";" and ",", both do not work.
Any suggestions?
How does it not work? MSBuild turns a semi-colon-separated string into an array for the task. For example, the WiX setup project uses this:
<BaseInputPaths>$(OutputPath_x86);$(OutputPath_x64);$(OutputPath_ia64);$(MSBuildProjectDirectory);$(WIX_ROOT)src;$(WIX_ROOT)bin;$(WIX_ROOT)src\dutil\inc;$(BaseInputPaths)</BaseInputPaths>
Related
I am using cmake and cpack and wix to build and deploy my project. The installer has some properties that user can enter via GUI or MSI-command-line options.
I set default property values in my CMakeLists.txt using:
set(CPACK_WIX_PROPERTY_<PROPERTY> <value>)
The problem is that if I change these values, I should rerun cmake command before cpack command.
I am looking for a way to change default value of these properties without need for rerunning cmake.
I tried adding additional wxs files using CPACK_WIX_EXTRA_SOURCES or patching generated files with additional xml files using CPACK_WIX_PATCH_FILE, but couldn't find the right code to put in wxs or xml files to accomplish my goal.
I tried The SetProperty command and found out its behavior is not easy to control, I gave up when I saw the user provided values don't replace the initial values and suggested solution at https://web.archive.org/web/20180205001358/http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unable-to-override-SetProperty-value-with-Edit-Control-value-td7591569.html didn't work. I hope there is a simple way, but even a complex answer using SetProperty is allright.
I am looking for a way to change default value of these properties without need for rerunning cmake.
A script specified in CPACK_PROJECT_CONFIG_FILE variable is the one, which affects on CPack, but which changing doesn't require cmake to re-run. So you may place setting of CPACK_WIX_PROPERTY_<PROPERTY> here: Changing this setting would require only to re-run CPack without re-run cmake on the main project.
Also, when the script specified in CPACK_PROJECT_CONFIG_FILE variable is parsed, CPACK_GENERATOR variable contains the exact CPack generator which is currently processed. This opposites to behavior of the variable inside CMakeLists.txt, when it contains a list of generators.
MBuild can use response files to save and run commands. But why is it called response file? What is it responding to?
(Also in an MsBuild file the task elements are called Target. What is 'target' refering too?)
A target represents a collection of things you want to do. In an msbuild file, it is represented by an xml element that can have various child xml elements called tasks.
Conceptually it looks like this:
<Target Name="Foo">
<Task />
<AnotherTask />
</Target>
The target you want to execute can be passed in as a command line parameter to msbuild. There are other ways to execute the target of your choice, but you will need to read the docs for that:
https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild?view=vs-2019
In other build systems, a target can be called a goal.
Note:
Some build systems use a very rigid convention, where files have to be in certain places. MSBuild is not like that. It relies on configuration, where you can configure it any way you like. The only convention's really are the xml syntax and schema that you have to follow.
As for the response file name. Who knows and who cares anyways? It's just an extra place to put more command line parameters. I don't rely on it, and neither should you. If you know what you are doing you can stick all that stuff in a proper msbuild xml file and just invoke msbuild to kick off a build.
I'm installing a toolset and I use the $(Registry:Path#Value) syntax to read the path to the compiler executable and set a property containing this value. However, in order to properly set up the search paths that the executable needs, I need to read the file version of this executable. I've seen examples of using a Target to do this and putting a Task in the target that invokes GetAssemblyVersion, but I want something more like a property function, because I want to initialize this before a build has even been run. The user should be able to go into the Project Settings and see the value I've determined as part of their include path. So what I'd really like is something like this:
<Project>
<PropertyGroup>
<CompilerExe>$(Registry:Path#Value)</CompilerExe>
<CompilerVersion>$(GetFileVersion:$(CompilerExe))</CompilerVersion>
</PropertyGroup>
</Project>
Obviously the syntax above doesn't work, but is there any way I can do something like this?
I know this question was discussed hundreds of times, but I still cannot find solution. Maybe something was changed in msbuild and I am not aware. The problem is that I get the following warning
warning MSB8012: TargetPath(d:\src\output\Techd.dll) does not match the Linker's OutputFile
property value (d:\src\output\Debug32\bin\Techd.dll). This may cause your project to build
incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and
$(TargetExt) property values match the value specified in %(Link.OutputFile).
I change the outdir by property
msbuild.wxw /p:OutDir="my_out_dir"
I cannot change projects properties and I am not allowed to modify msbuild target files (Microsoft.CppBuild.targets). So don't have any idea hot to force msbuild to ignore this warning or to ignore the $OutDir variable's change.
You should be able to silence MSBuild warnings using a command line parameter:
msbuild.exe /nowarn:MSB8012
In an upcoming update to MSBuild/VS2017 (15.3), you can specify properties to control MSBuild warnings in project files as a property, so that it also affects builds in VS:
<MSBuildWarningsAsMessages>MSB8012</MSBuildWarningsAsMessages>
What reasons could there be for the following strange behaviour, and how might I track down the issues?
We use a combination of make files and msbuild.
I have a project which needs to be strongly named. I was previously setting the snk to use in the project file like this:
<AssemblyOriginatorKeyFile>$(EnvironmentVariable)TheKeyName.snk</AssemblyOriginatorKeyFile>
where EnvironmentVariable was defined in the batch file that launched the shell for the build like this:
set EnvironmentVariable='SomePath'
and this worked ok. Now I need the string name key to be able to be changed, so it can be different on the dev machine and the release build server. There is a variable which exists to hold the full path to the strong name key file, called StrongNameKeyFile. This is defined in the msbuild environment, and if I put some text output in the targets or properties files that are included as part of the msbuild task which build the project then I can see that this StrongNameKeyFile points to the correct location. So I changed the csproj to have this instead:
<AssemblyOriginatorKeyFile>$(StrongNameKeyFile)</AssemblyOriginatorKeyFile>
but when I try and compile this is evaluating to empty and no /keyfile is specified during the build.
We also have variable defined in the make files and these can be accessed in the csproj as well. These are used to point to the locations of referenced dlls, so that they can be different on dev and build machines. I know that these are set as the references come out correctly and everything compiles, but if I try and use one of these variables in the AssemblyOriginatorKeyFile element then it evaluates to empty in that element, but works in the reference element.
Why might this be? Is AssemblyOriginatorKeyFile treated specially somehow? How can I go about tracking the cause of this down?
There's no good reason why this should happen - as you know it normally Just Works; it's likely to be something in the chain dropping it on the floor.
One thing to try is explicitly passing it via /p:StrongNameKeyFile=XX - that would eliminate environment variables and the correct propagation thereof from your inquiries.
Another potential thing is that something is clobbering the variable as the name is used vy something else?
Run with /v:diag and you'll get dumps of all the inputs and/or variables as they change.
Or if on V4, use the MSBuild Debugger
And buy the Hashimi et al MSBuild book