[
https://issues.apache.org/jira/browse/NPANDAY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727460#comment-13727460
]
Brett Porter edited comment on NPANDAY-505 at 7/8/14 3:06 AM:
--------------------------------------------------------------
Looking closer at the code for this, it seems that the SDK locators are too
broad in the first place, and there is some confusion between .NET SDK and
Windows SDK references. We would be better specifying the expected path of the
specific commands needed:
* csc, etc. in the framework tools path
* xsd, gacutil in the framework NETFX path
That way it should just be one path rather than a search.
I note that there are the following to help now, which reference the specific
Windows SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0@MSBuildToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5@MSBuildToolsPath}}
and from 4.0 also:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@FrameworkSDKRoot}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK35ToolsPath}}
(points to the Windows SDK suitable for 3.5 tools)
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows@CurrentInstallFolder}} (points to the Windows SDK suitable for 3.5
tools also, if {{bin}} subdirectory is referenced)
For 4.5 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0@SDK40ToolsPath}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\11.0@SDK40ToolsPath}}
(if MSBuild 12.0 has been installed)
For 4.5.1 SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\12.0@SDK40ToolsPath}}
was (Author: brettporter):
Looking closer at the code for this, it seems that the SDK locators are too
broad in the first place, and there is some confusion between .NET SDK and
Windows SDK references. We would be better specifying the expected path of the
specific commands needed:
* csc, etc. in the framework tools path
* xsd, gacutil in the framework NETFX path
That way it should just be one path rather than a search.
I note that there are the following to help now, which reference the specific
Windows SDK:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0@MSBuildToolsPath}}
and from 4.0 also:
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@FrameworkSDKRoot}}
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0@SDK40ToolsPath}}
> Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)
> -------------------------------------------------------------------------
>
> Key: NPANDAY-505
> URL: https://issues.apache.org/jira/browse/NPANDAY-505
> Project: NPanday
> Issue Type: Improvement
> Components: Development Setup, Maven Plugins
> Affects Versions: 1.4-incubating
> Reporter: Lars Corneliussen
> Assignee: Brett Porter
> Fix For: 1.5.0-incubating
>
>
> Currently NPanday "sometimes" generates a {{npanday-settings.xml}}-file;
> preferably in {{~/.m2}}. Currently this is done by
> NPanday.Plugin.Settings:generate-settings. The problem is, that the file is
> needed to compile the plugin that generates it. That makes it hard to
> bootstrap without a path.
> h2. New Approach
> We create a master "superset" configuration {{npanday-settings.xml}} (or
> better {{supported-vendors.xml}}?? that contains all frameworks and vendors
> NPanday supports. Then based on various rules, NPanday checks which
> combinations of vendor, vendorVersion and frameworkVersion(s) are available
> on the current platform (registry and path lookup, as currently done in
> generate-settings).
> h2. Example
> Currently this code:
> {code:title=plugins\netplugins\NPanday.Plugin.Settings\src\main\csharp\DotnetSdkLocator.cs}
> ..
> RegistryKey Microsoft_NETFramework =
> Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\.NETFramework");
> RegistryKey Microsoft_SDKs_NETFramework =
> Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\SDKs\.NETFramework");
> ..
> return PathUtil.FirstExisting(
> registryFind(Microsoft_NETFramework, "sdkInstallRootv2.0"),
> registryFind(Microsoft_SDKs_NETFramework, "v2.0",
> "InstallationFolder"),
> ProgramFilesX86(@"Microsoft.NET\SDK\v2.0"),
> ProgramFilesX86(@"Microsoft.NET\SDK\v2.0 64bit"),
> ProgramFilesX86(@"Microsoft SDKs\Windows\v6.0A\bin"),
> ProgramFiles(@"Microsoft SDKs\Windows\v6.0A\bin")
> );
> {code}
> Generates this:
> {code:title=~\.m2\npanday-settings.xml}
> ...
> <vendor>
> <vendorName>MICROSOFT</vendorName>
> <vendorVersion>3.0</vendorVersion>
> <frameworks>
> <framework>
> <frameworkVersion>3.0</frameworkVersion>
> <installRoot>C:\Windows\Microsoft.NET\Framework64\v3.0</installRoot>
> <sdkInstallRoot>C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\</sdkInstallRoot>
> <executablePaths>
>
> <executablePath>C:\Windows\Microsoft.NET\Framework64\v2.0.50727</executablePath>
> <executablePath>C:\Program Files\Microsoft.NET\SDK\v2.0
> 64bit\bin</executablePath>
> </executablePaths>
> </framework>
> </frameworks>
> </vendor>
> ...
> {code}
> {code:title=components\dotnet-core\src\main\resources\META-INF\npanday\npanday-settings.xml}
> ...
> <vendors>
> ...
> <vendor>
> <vendorName>MICROSOFT</vendorName>
> <vendorVersion>3.0</vendorVersion>
> <frameworks>
> <framework>
> <!-- new !! -->
> <frameworkArchitecture>AMD64</frameworkArchitecture>
> <frameworkVersion>3.0</frameworkVersion>
>
> <!-- registry (Software\Microsoft\.NETFrameworkd@InstallPath)
> allways finds Framework64 on 64bit windows; hence path is better -->
>
> <installRoot>${env.WINDIR}\Microsoft.NET\Framework64\v3.0</installRoot>
>
> <!-- first one wins -->
> <sdkInstallRootProbingPaths>
>
> <sdkInstallRootProbingPath>${HKLM\Software\Microsoft\.NETFramework@sdkInstallRootv2.0"}</sdkInstallRootProbingPath>
> <sdkInstallRootProbingPath>${HKLM\SOFTWARE\Microsoft\Microsoft
> SDKs\.NETFramework\v2.0@InstallationFolder}</sdkInstallRootProbingPath>
>
> <sdkInstallRootProbingPath>${env.ProgramFiles}\Microsoft.NET\SDK\v2.0</sdkInstallRootProbingPath>
> <sdkInstallRootProbingPath>${env.ProgramFiles}\Microsoft
> SDKs\Windows\v6.0A\bin</sdkInstallRootProbingPath>
> <sdkInstallRootProbingPath>${env.ProgramFilesX86}(@"Microsoft
> SDKs\Windows\v6.0A\bin"}</sdkInstallRootProbingPath>
> </sdkInstallRootProbingPaths>
> <executableProbingPaths>
> <!-- 3.0 doesn't come with new tools -->
>
> <executableProbingPath>${env.WINDIR}\Microsoft.NET\Framework64\v2.0.50727</executablePath>
>
> <!-- we could by default add installRoot and sdkInstallRoot(+bin)
> -->
> <!-- executableProbingPath>C:\Program
> Files\Microsoft.NET\SDK\v2.0 64bit\bin</executablePath -->
> </executableProbingPaths>
> </framework>
> </frameworks>
> </vendor>
> ...
> </vendors>
> ...
> {code}
> Both registry access with ${HKLM*}, ${HKCU*}, ${HKEY_LOCAL_MACHINE*},
> ${HKEY_CURRENT_USER*} and ${env.*} should work. I'd suggest to let
> ${env.ProgramFilesX86} fall back to ${env.ProgramFiles} for non-64-bit - (add
> an item to the properties in {{ContextAwareModelInterpolator}})
--
This message was sent by Atlassian JIRA
(v6.2#6252)
