2

For a custom licensing scheme we inject licensing code into the user projects (msbuild), leveraging the LC.exe tool via its msbuild task. We want to support all VS versions from 2010 upwards (as of today: ..2015).

The LC task exposes individual parameter sets in each version. So the "TargetFrameworkVersion" parameter seems to be obligatory in 2015 (tools version 14.0) but does not exist in earlier versions. Hence, we need to implement individual calls to the LC target. Currently, we distinguish that way: 

<LC Condition="'$(MSBuildToolsVersion)'=='14.0'" ...

However, this seems not to work. One example:

A project which has the ToolsVersion="14.0" attribute in its msbuild definition is build in the, let's say VS2012 command prompt. The $(MSBuildToolsVersion) resolves to 14 but still the LC.exe is used from the following path (read from msbuild log): 

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\LC.exe

... which corresponds to the version of the command prompt, I suppose. so it appears that the $(MSBuildToolsVersion) parameter cannot be used in order to distinguish from the versions of the SDK tools actually used?

How can the SDK version used for building the project be detected?

Update: I have also considered this answer but it basically only gives a path - not a version.

Community
  • 1
  • 1
Haymo Kutschbach
  • 3,322
  • 1
  • 17
  • 25
  • Check my comment on [this question](http://stackoverflow.com/q/26442450/17034). – Hans Passant Nov 26 '15 at 11:30
  • Yes, I thought about that suggestion. The problem is that it needs to run at the users computer. My current 'solution' is to use [`GetFrameworkSDKPath`](https://msdn.microsoft.com/en-us/library/ms164298.aspx) and do some serious [RegExp-ing](http://blogs.msdn.com/b/visualstudio/archive/2010/04/02/msbuild-property-functions.aspx) to parse the version from the path. I know, it is ... – Haymo Kutschbach Nov 26 '15 at 12:01

0 Answers0