Autogenerate WXI file in WiX Build process - msbuild

I have a batch file that creates a WXI file that is included in the final build process of a MSI.
If I use the "Pre-build Event" in the project setting of VS-2019 this command is always executed even if there is no need to compile the WiX project.
I tried to add
<Target Name="UpdateVersionNumber" Inputs="$(ProjectDir)..\..\..\Bin\Infile.dll" Outputs="$(ProjectDir)output.wxi">
<Exec Command=""%COMSPEC%" /c UpdateVersion.bat "$(ProjectDir)..\..\..\Bin\Infile.dll" "$(ProjectDir)$output.wxi"" />
</Target>
The batch file creates the output.wxi file depending on the DLL. The output.wxi is also part of the project.
But it is never executed. If I add BeforeTargets="Compile" it is again always executed.
I only want this batch file executed if any build is required.
In C# projects the "Pre-Build Events" are only executed when there is need for a build an any file is out of date. This isn't the case for WiX projects in VS-2019.
How to achieve that this batch file is only executed when the Infile.dll is newer than the output.wxi
Edit: The infile.dll is not created by this build process. The build process for the infile.dll is completely a separate project.

First, I think that there is some problems with your Infile.dll and your needs about this issue.
How to achieve that this batch file is only executed when the
Infile.dll is newer than the output.wxi
To answer this question, actually, what you did(use input and output) meets this.
If the files from the inputs node are newer than the files from outputs node, the target will be executed. See this official document.
So in your side, the Infile.dll is always built rather than up to date, and it is always newer than output.wxi which depends on it. And the batch file will generate the output.wxi based on Infile.dll. All of these cause that behavior and the target will always be executed.
BeforeTargets="Compile" just specify this target into the build process.
In C# projects the "Pre-Build Events" are only executed when there is
need for a build an any file is out of date. This isn't the case for
WiX projects in VS-2019.
There won't be any problems with this method on the surface. The real problem is that why the Infile.dll is always newer than output.wxi.
<Target Name="UpdateVersionNumber" Inputs="$(ProjectDir)..\..\..\Bin\Infile.dll" Outputs="$(ProjectDir)output.wxi" BeforeTargets="Compile">
<Exec Command=""%COMSPEC%" /c UpdateVersion.bat "$(ProjectDir)..\..\..\Bin\Infile.dll" "$(ProjectDir)$output.wxi"" />
</Target>
==============================
First, if the Infile.dll is one of the output file of the wix project, then it can be explained clearly. Since wix project does not have incremental build feature and always
The execute order
UpdateVersionNumber(compare Infile.dll and output.wxi )--->Compare-->Build(generate the new output file Infile.dll)
For the first build time, the target will be executed and then generated the output.wxi file based on Infile.dll as expected. Then it executes the build process, it will update
Infile.dll.
However when you execute it second time, the Infile.dll is newer than output.wxi. And the target will always be executed and stuck in a loop.
In this situation, you have nothing to do.
=============================
If Infile.dll is an content from somewhere else, you should check why the Infile.dll is always new(perhaps the wix project has a dependency relationship with the other project) rather than up-to-date.Or it could be always be updated by something else.
If Infile.dll is the output file from another type of the project, you can enter that project to check its detailed output build output log to find where the issue is.
In addition, you should check the other project very carefully and pay attention to your requirements.

Related

MSBuild wildcard matching of files for deployment

I am hoping to be able to use MSBuild to capture a subtree of files produced during the build of a project using Microsoft.NET.Sdk.Web and include them in deployment. So far, I have found that if I simply create the files inside the project folder before deployment, then it works but only for certain filetypes. DLLs, for instance, are excluded, presumably assumed to be non-content items. I have been poking around how the deployment stuff works, and have found the <ResolvedFileToPublish> element that I can put into <ItemGroup>, but I haven't figured out how it might be possible to employ this with wildcards. Specifically, I have a post-build step that places files into a folder deployment within the project, and I want all files in that subtree to be included in the package that is produced by /p:DeployOnBuild=true. How can I tack my files onto the deployment stage so that they're included in the ZIP even if they don't look like content items?
I have found a solution, in the form of adding a new <Task> set to run immediately after the internal tasks which collect files for publishing. This is not suitable for a long-term solution, since it ties to internal state, but this is a temporary fix and as such I think it's alright.
By adding this to the .csproj:
<Target Name="__CopyDeploymentToPublish" AfterTargets="_CopyResolvedFilesToPublishAlways">
<Exec Command="PowerShell.exe -Version 3.0 -ExecutionPolicy Unrestricted $(SolutionDir)deploy_webapp.ps1 -Source $(SolutionDir)src\IQ.Auth.OAuth2.Web -Target $(PublishDir)" />
</Target>
...my PowerShell script runs right after the standard deployment logic aggregates the files it intends to package up. I can at that point do whatever I want to the files and the way they're left is what'll end up in the ZIP file.

Wix Build Order - msbuild & Heat

I am trying to extend our existing Wix Project with Heat to include all files from the output directory of another project in the installer. Somehow I`m missing something that should be very easy since I guess this is a very common task.
Here is what the solution looks like:
SomeDependencyA.csproj
SomeDependencyB.csproj (Depends on SomeDependencyA)
WindowsService.csproj (Depends on SomeDependencyB)
Installer.wixproj(Depends on WindowsService.csproj)
Wix should basically grep anything from WindowsService Output folder and build the msi package from it. The process should be:
Build all Dependencies
Build WindowsService project
Generate a Fragement using Heat
Build the Installer
And here is my question: Where/how do I have to include the call to Heat? Pre-Build Step and BeforeBuild Target does not work, since at this time the WindowsService and the Dependencies are not Build yet. AfterBuild wouldn´t help, since at that point the generated Fragment would not be cosidered anymore. I was looking for some build target that is calles AFTER all dependencies have been build but BEFORE the Installer Project itself has been build. Should be easy, but I couldn´t figure it out yet.
The BeforeBuild target will happen potentially before a dependant project has completed its build.
A solution I've used for this type of build ordering in the past is to add a DependsOnTargets for the BeforeBuild target;
For csproj:
<Target Name="BeforeBuild" DependsOnTargets="ResolveReferences">
For vcxproj:
<Target Name="BeforeBuild" BeforeTargets="PrepareForBuild">
This will force the project to wait until the dependant projects are completed before running the BeforeBuild target.

WiX Heat: Pre-build event fires too early on build server

I'm harvesting a directory for my Visual Studio solution.
It works on my local system so far probably because the project build order is being respected.
When I run the installer on a build server it finds the right directory but it has not been created at the time of building the setup file. It throws a HEAT5052 error saying The directory 'a:\b\c' could not be found.
Is there any way to "wait" until or to execute the heat command after all project references are built?
OK so I've spent hours to figure out how to fire Heat AFTER all references are resloved. I only found solutions for the <PreBuildEvent> and <PostBuildEvent> using the Heat command line and the BeforeBuild and AfterBuild targets.
So I found all kind of targets inside the wix2010.targets file located in my
Program files (x86)\MSBuild\Microsoft\Wix\ folder. It contains a target called AfterResolveReferences and it does exactly that. So here's my code I ended up with (in case someone is interested):
<Target Name="AfterResolveReferences">
<HeatDirectory
ToolPath="$(WixToolPath)"
OutputFile="Product.Binaries.wxs"
SuppressFragments="$(HarvestDirectorySuppressFragments)"
Transforms="Filter.xslt"
Directory="$(HarvestFolder)"
DirectoryRefId="MY_FOLDER"
ComponentGroupName="Binaries"
GenerateGuidsNow="true"
SuppressRootDirectory="true"
SuppressRegistry="true"
PreprocessorVariable="var.App.TargetDir">
</HeatDirectory>
</Target>
I had the same problem and it was solved by combining the accepted answer and this answer to ensure that my post build event, which was copying files, always runs:
<RunPostBuildEvent>Always</RunPostBuildEvent>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
Also, my build server was using the MSBuild command line, and I used this answer to locate my local MSBuild.exe so I could test my changes locally without having to push to the build server.

How can I run the current version of a NuGet package executable from the MSBuild project file?

I have added the xunit.runners package to a solution. The current version is 1.9.1, so I have hard-coded the path to the executable in an MSBuild project file:
<StartAction>Program</StartAction>
<StartProgram>$(MSBuildProjectDirectory)\..\..\Packages\xunit.runners.1.9.1\tools\xunit.gui.clr4.exe</StartProgram>
<StartArguments>"$(MSBuildProjectDirectory)\$(OutPutPath)$(AssemblyName).dll"</StartArguments>
(Off-topic: with this configuration, F5 starts the xUnit GUI runner and I can debug specific unit tests.)
I know that everytime I update the Nuget package, I will forget to change the path. Changing the path is a minor nuisance, since I have to unload the project, edit the file, then reload the project.
How can I start the executable, regardless of the actual version of the package? Can I find the executable in the folder named xunit.runners.* using a wildcard in MSBuild, then use that as a property in the <StartProgram> element?
Edit:
Something like:
<ItemGroup>
<Runners Include="$(MSBuildProjectDirectory)\..\..\Packages\xunit.runners.*\tools\xunit.gui.clr4.exe" />
</ItemGroup>
Will give me all runners in #(Runners), sorted by version. How can I get one of them, preferably the last one?
For filtering you can build a custom task. It can even be inline http://msdn.microsoft.com/en-us/library/dd722601.aspx, were you can write the c# code you need to loop over the items and pick the right one. Then you can expose the chosen path in an output property that you then use to set the value of the StartProgram property.
This question shows a custom inline task that gets an item array and does stuff with it. You can probably start from there.
You'll need to use this task in a target that runs before the target that initiates the debugging.
With fsimonazzi's comment I ended up with this:
<PropertyGroup>
<Package>$([System.IO.Directory]::GetDirectories("$(MSBuildProjectDirectory)\\..\\..\\Packages\\", "xunit.runners.*").GetValue(0))</Package>
<StartAction>Program</StartAction>
<StartProgram>$(Package)\tools\xunit.gui.clr4.exe</StartProgram>
<StartArguments>"$(MSBuildProjectDirectory)\$(OutPutPath)$(AssemblyName).dll"</StartArguments>
</PropertyGroup>
Apparently, NuGet will guarantee there's only one version of the package.

MSBUILD - block until a file exists on an ftp server?

As part of a build process .. I would like to block the build until a file gets created (exists) remotely at an ftp location, after which I would continue the build. (Preferably with somekind of time out limit).
Suggestions?
Is this even possible using only the standard msbuild task and/or extensionPack/communitytask?
Your best bet is to build a small custom exe (you can even compile it as a build step) that polls for the file you are looking for. Then you use the PreBuild target, or a custom target in a pre-build step to verify that the file exists.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="WaitOnFTP">
<Exec Command="MyFTPWaiter.exe"/>
</Target>
</Project>
Other more MSBuild oriented suggestions are to remake that exe as a custom task, or even an inline task in MSBuild 4.0.
FWIW, I've encountered a similar solution done by a peer who didn't want large binaries used by integration tests in version control and he required the use of a custom downloader in the build to get the files from a SMB share. It worked well enough.
Custom Tasks
Inline Tasks