Skip to content

WindowsRegistry is not supported on this operating system. #274

Open
@ncimino

Description

@ncimino

I'm hitting an exception, and I presume it is because of my companies anti-virus/malware software is blocking Gradle from reading the registry key \\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir. First thing to note is, I am working with my IT department to resolve this...

However, it doesn't seem like Gradle should stop the flow here. It could consult with the PATH environment variable to locate vswhere.exe as a workaround or even skip this step entirely and look for the tool-chains in PATH. Any of these would be infinitely better then just throwing an exception and stopping the flow with no way to disable or bypass it.

Here is the exception:

Caused by: org.gradle.internal.nativeintegration.NativeIntegrationUnavailableException: WindowsRegistry is not supported on this operating system.
	at org.gradle.internal.nativeintegration.services.NativeServices$BrokenService.invoke(NativeServices.java:345)
	at com.sun.proxy.$Proxy112.getStringValue(Unknown Source)
	at org.gradle.nativeplatform.toolchain.internal.msvcpp.version.DefaultVswhereVersionLocator.getVswhereInstall(DefaultVswhereVersionLocator.java:48)
	at org.gradle.nativeplatform.toolchain.internal.msvcpp.version.CommandLineToolVersionLocator.locateInstalls(CommandLineToolVersionLocator.java:56)
	at org.gradle.nativeplatform.toolchain.internal.msvcpp.version.AbstractVisualStudioVersionLocator.getVisualStudioInstalls(AbstractVisualStudioVersionLocator.java:32)
	at org.gradle.nativeplatform.toolchain.internal.msvcpp.DefaultVisualStudioLocator.locateInstallsWith(DefaultVisualStudioLocator.java:108)
	at org.gradle.nativeplatform.toolchain.internal.msvcpp.DefaultVisualStudioLocator.initializeVisualStudioInstalls(DefaultVisualStudioLocator.java:97)
	at org.gradle.nativeplatform.toolchain.internal.msvcpp.DefaultVisualStudioLocator.locateComponent(DefaultVisualStudioLocator.java:86)
	at org.gradle.nativeplatform.toolchain.internal.msvcpp.VisualCppToolChain.checkAvailable(VisualCppToolChain.java:175)

To locate the Visual Studios tools DefaultVswhereVersionLocator asks the registry for the Program Files or Program Files (x86) location and then appends Microsoft Visual Studio/Installer along with vswhere.exe. This action happens here:

    public File getVswhereInstall() {
        for (String programFilesKey : PROGRAM_FILES_KEYS) {
            File programFilesDir;
            try {
                programFilesDir = new File(windowsRegistry.getStringValue(WindowsRegistry.Key.HKEY_LOCAL_MACHINE, REGISTRY_PATH_WINDOWS, programFilesKey));
            } catch (MissingRegistryEntryException e) {
                // We'll get this when we try to look up "ProgramFilesDir (x86)" on a 32-bit OS
                continue;
            }

            File candidate = new File(programFilesDir, VISUAL_STUDIO_INSTALLER + "/" + VSWHERE_EXE);
            if (candidate.exists() && candidate.isFile()) {
                return candidate;
            }
        }

        return os.findInPath(VSWHERE_EXE);
    }

The exception is thrown at:

                programFilesDir = new File(windowsRegistry.getStringValue(WindowsRegistry.Key.HKEY_LOCAL_MACHINE, REGISTRY_PATH_WINDOWS, programFilesKey));

This windowsRegistry object is an instance of: net.rubygrapefruit.platform.WindowsRegistry

Perhaps one alternative would be to catch NativeIntegrationUnavailableException here.

The reason this is so problematic is it is one of the first things that happens in native tool-chain resolution. It is just initializing all of the tool-chains/install locations we haven't even got to where we select the tools yet. From the aforementioned stack-trace you can see this method ( in DefaultVisualStudioLocator):

    private void initializeVisualStudioInstalls() {
        if (!initialised) {
            locateInstallsWith(commandLineLocator);   // <--- We are here when this throws
            locateInstallsWith(windowsRegistryLocator);
            if (foundInstalls.isEmpty()) {
                locateInstallsWith(systemPathLocator);
            }

            initialised = true;
        }
    }

We are still in commandLineLocator as it is trying to use vswhere.exe to locate the tools. Even if that fails and windowsRegistryLocator I think it would make sense to continue on to systemPathLocator, but we cannot even get to where it would locate tools using the PATH which would at least let me workaround this issue.

If you have any ideas I'd love to hear them because I'm not able to run C++ builds on Windows right now.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions