Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.4-incubating
-
None
Description
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.
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).
Example
Currently this code:
.. 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") );
Generates this:
... <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> ...
... <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> ...
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)