Build Automation

[rguggisberg]

A while back I implemented path variable overrides for my InstallScript MSI projects.
I added this to my isproj files:



PATH_TO__SOURCE_ROOT



I have been building from a bat file by passing the property MSBuildRoot="D:\cn10_2013q4" to MSBuild.exe and that has been working fine.

Now we are implementing Build Automation with VS 2013 and InstallShield 2013 SP1 SAB.
In my build definition for '5. Advanced - MSBuild Arguments' I specified /Property:MSBuildRoot=$(MSBuildThisFileDirectory)
I am getting this error:

C:\Program Files (x86)\MSBuild\InstallShield\2013\InstallShield.targets (77): PathVariable "PATH_TO__SOURCE_ROOT" path "$(MSBuildThisFileDirectory)" does not exist.

I have tried several properties similar to $(MSBuildThisFileDirectory) and get the same result.
How do I resolve?
Thanks.

Update: I changed MSBuild Arguments to:
/Property:MSBuildRoot=$(TF_BUILD_BUILDDIRECTORY)
and that seems to be a bit closer. I believe the property is being resolved because the number after \Builds\ (below) does change. But now the error is:

C:\Program Files (x86)\MSBuild\InstallShield\2013\InstallShield.targets (77): -6271: File C:\Builds\2\MyFolder\MySubFolder\AnotherFolderName\bin\SolutionConfiguration\MyFileName.ext not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
I don't want the SolutionConfiguration name in the path, but don't know what to use for an argument to accomplish that.

[MichaelU]

I'm not 100% sure, but I don't think that MSBuild is resolving the value you're passing on the command line. So while you think of it as a variable reference, it's probably being treated as a literal dollar sign, parenthesis, and name.

[rguggisberg]

Thanks Michael.
I could be wrong, but think the value is being resolved because the number after \Builds\ (see update in my post) does change.
Do you know of any documentation that would be useful?
Thanks Again

[MichaelU]

Hmm. I'm not up to date on good references for MSBuild; you've already been through the reference on MSDN? I'd probably suggest adding tasks to see what values of things are actually being used, but that doesn't bring you closer to solving your actual problem. On my earlier read I missed that this was being invoked from Visual Studio, and that may be resolving the value passed on the command line. However if that's the case and your path can include spaces, take care to put quotes around it. (I don't think the symptom matches that potential problem, though.)

If you're trying to use values from within the MSBuild file, perhaps you could approach it by providing defaults for when the property isn't specified on the command line. We do something similar in our targets file:

	
		...
	

You could follow this approach by using the properties you want and replacing ... with your property reference.

[rguggisberg]

Michael,
Thanks for the reply. I am a bit closer. Had some permissions problems.
Now I think I need to modify the .targets file. It is working fine if I build from the dev machine, but it does not work from the SAB machine. The InstallShield log shows that it is looking in the wrong place for files. So I am getting errors like this:
ISDEV : error -6103: Could not find file "C:\Builds\1\GoodFolderName\AnotherGoodFolderName\AnExtraFolderNameHere\bin\Release\GoodFilename.exe"

Where "AnExtraFolderNameHere\" above should not be there.

Is that customary to require a different .targets file; or a condition in the .targets file for SAB?
Thanks

Looking further, my problem stems from the fact that the source files on the InstallShield Dev machine are laid out with a folder structure to mimic the Source control folders, while the SAB build source files are all in one bin folder. Can I accommodate this disparity in the .targets file?

[MichaelU]

It's really hard for me to answer in the abstract, but I've not heard of it being common to edit the .targets file. (If that does appear to be the solution, and there's some tweak we could make to the standard issue .targets file to make future edits possible in the .isproj file alone, let me know.) In a more general sense, it's completely possible to modify paths or values, but I'm not sure what to recommend here.

If you're using project outputs, I know there has also been some disparity between "obj" paths and "bin" paths; building in Visual Studio provides one for project outputs, and building in MSBuild provides another, at least in some versions of Visual Studio and/or MSBuild. If you're using static paths, you may be able to tweak path variables through the overrides exposed (either in IsCmdBld or to MSBuild), but I'm not sure how to condition that without, say, a separate build step.

[rguggisberg]

Thanks Michael. You have given me some ideas and got me moving forward. I also came to the conclusion that it probably won’t be necessary to modify the .targets file. Yes, we are using project outputs. I think I will be able to get there by doing 2 things:
1. PreBuild script to copy files to bin folder that are in source control but we do not build.
2. Clean up my duplicate and unused paths in IS ‘Path Variables’ view and then pass the overrides as MSBuild arguments in my build definition.
Thanks Again
Back to work 🙂