A similar question was asked a few years ago, but I'm wondering if anything has changed in the interim or if folks have new ideas how to do this.
I've imported MSBuildTasks (MSBuild Community Tasks) as a Nuget package into a project within my solution. I can define a property for the path to the .targets file as follows:
<PropertyGroup>
<MSBuildTasks>$(SolutionDir)Packages\MSBuildTasks.1.5.0.235\tools\MSBuild.Community.Tasks.Targets</MSBuildTasks>
</PropertyGroup>
... and then import it using:
<Import Project="$(MSBuildTasks)"/>
Of course, I may choose to update the package at a later date in which case the folder name changes, so I'd prefer to avoid hard-coding the version number. One way I thought of to avoid this was to have a powershell script look for the latest version:
function Find-PackagePath
{
[CmdletBinding()]
param(
[Parameter(Position=0,Mandatory=1)]$packagesPath,
[Parameter(Position=1,Mandatory=1)]$packageName
)
return (Get-ChildItem ($packagesPath + "\" + $packageName + "*")).FullName | Sort-Object $_ | select -Last 1
}
... and inject that as a command-line property for MSBuild:
msbuild $solutionFile "/p:Configuration=$buildConfiguration;Platform=$buildPlatform;MSBuildTasks=$MSBuildTasks";
I can confirm with a message that the injected path is indeed transmitted to my target:
<Target Name="_ReportMSBuildTasksPath" BeforeTargets="_ComputeSemanticVersion">
<Message Text="MSBUILDTASKS = $(MSBuildTasks)"/>
</Target>
... but if I try to import using the same import statement above, I get the following error message:
The value "" of the "Project" attribute in element <Import> is invalid. Parameter "path" cannot have zero length.
This is where I run out of ideas. How can I avoid hard-coding the version number in the tools path?
