Как исправить ошибку this application requires one of the following

Что делать? Устанавливать или нет?

При запуске приложения Snaz вместо приложения, выскакивает табличка:

This application requires one of the following versions of the .NET
Framework:
.NETFramework,Version=v.4.5.2

Do you want to install this .NET Framework version now?

При нажатии ДА, перекидывает на сайт и скачивается программа NDP462-KB3151802-Web.exe

Что делать если эта ошибка? Предупреждения:

Программа установки может не работать надлежащим образом, поскольку на этом компьютере недоступна служба Центра обновления Windows.

Что делать если эта ошибка? Предупреждения:

Программа установки может не работать надлежащим образом, поскольку на этом компьютере недоступна служба Центра обновления Windows.

Что делать если эта ошибка? Предупреждения:

Программа установки может не работать надлежащим образом, поскольку на этом компьютере недоступна служба Центра обновления Windows.

Что делать если эта ошибка? Предупреждения:

Программа установки может не работать надлежащим образом, поскольку на этом компьютере недоступна служба Центра обновления Windows.

ТОЛЬКО СЕГОДНЯ И ТОЛЬКО ДЛЯ ТЕБЯ ПЕРЕВОЖУ ТЕКСТ В ОНЛАЙН ПЕРЕВОДЧИКЕ БЕСПЛАТНО.

This application requires one of the following versions of the .NET
Framework:
.NETFramework,Version=v.4.5.2
Do you want to install this .NET Framework version now?

Для этого приложения требуется одна из следующих версий .NET
Фреймворк:
.NetFramework, Version = v.4.5.2
Вы хотите установить эту версию .NET Framework сейчас?

Источник

this application requires a java runtime environment (different POV) #238

TL;DR: How to handle registry magic when using zip distribution? (for example after installing via scoop installer)

I do not know where to address my question (am aware this repo is for the installer), please be kind if you think this is the wrong place. i am open to recreating this issue somewhere else seen better fitting. but as i found the personally most fitting issue in this repo that is handling technicalities concerning the openjdk windows registry stuff i thought i post this issue here.

With issue #64 you created a way to use the installer to handle the registry magic . which is great! only i do not use the manual installer but use scoop to install java. scoop does not use the msi installer but extracts the zipped distribution . is there a way to reproduce the things the installer does concerning creation of the the required registry entries?

If there currently is no way . could the functionality be transformed to a utility that could be distributed inside the zipped distribution?

The text was updated successfully, but these errors were encountered:

JAVA_HOME is an environment variable an can be set using the GUI. Enter «environment variable» into the search field of Windows and the right option should pop up. The registry entries can be created manually using regedit. See https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-47C269A3-5220-412F-9E31-4B8C37A82BFB for the entries common Java software expects.

I assume setting JAVA_HOME is not the part that was asked here. If I understand @dhamann correctly he wants to add the JAR mimetype to be executed by Java for example. Is that right?

hi both of you, @aahlenst you are thinking in the right direction, @hendrikebbers you too!

. actually i would like to be able to do the stuff the installer does to the registry by running a utility that sets the values for the version that is distributed with the zip file.

running a jar via doubleclick is one use case, another would be running an executable file generated by launch4j

@aahlenst i probably would need to do the stuff you pointed me to . for every installed java version and for every next coming update again? how do other people using the zipped distribution handle this? (please point me to a better target for my question if the openjdk-installer repo is a not fitting place for this, i just do not know where to ask)

Is scoop like home-brew for windows? The project has 11k stars on GitHub. Maybe we should think about providing a script for scoop?

Looks like this is already available: https://github.com/ScoopInstaller/Java
Maybe the scripts just do not everything that the installer does. Looks like it sets the JAVA_HOME env but does no windows registry mutations: https://github.com/ScoopInstaller/Java/blob/master/bucket/adopt11-hotspot.json

ScoopInstaller/Scoop#3412 Scoop does not provide registry support at the moment.

hmm . i just tried it with the current installer . and it is like i want everything except the root node 🙂

would it be possible to put all the sub-entries of the root node in a second node that just sets the configuration? It could use the path supplied like shown in the screenshot below (i just painted that as a suggestive idea, the current dialog is also shown BELOW for reference)
Idea for different Dialog (two root nodes):

Current Dialog (one root node):

JAVA_HOME is an environment variable an can be set using the GUI. Enter «environment variable» into the search field of Windows and the right option should pop up. The registry entries can be created manually using regedit. See https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-47C269A3-5220-412F-9E31-4B8C37A82BFB for the entries common Java software expects.

hi @aahlenst the supplied info in the deep link is probably just the tip of the iceberg, i suppose? would i not also need some kind of reg entry for the directory that this keys point to? orcl url sadly does not mention anything like that there

dear @douph1 please excuse my «pulling you in» by mentioning . i read your very informative comments (for example: #64 (comment)) . currently the installer executes logic to manipulate registry values directly, right? (via wix-tooling?)

Could the installer maybe also create windows cmd / batch files that make it possible to re-execute that same registry-setting commands for the specific version? (although I just peeked into douph1@c79c7e8 and that seems rather complicated 🙂 ) Thank you for putting your time into this solution there, btw. Seems really challenging to find «the right» solution!

I’m not yet sure what the exact problem is. Therefore it is hard to recommend something and even more so to take action.

What do you want to achieve? Beyond applying «registry magic» to the ZIP files? Do you need multiple Java versions and an easy way to switch between them? Why is using an MSI not an option?

To write «Oracle Java Key» you must write to
HKLM only ( be root required )
The key path is based on :

• Major version (1.8 or later)
• JRE vs JDK
• know if you use Wow > Wow6432Node

But a key must not be overridden with an older key ( always pointed to the latest/newest Java )

As it depends of the version intended to be installed and already installed, just write reg key without the binary is useless and or/copy/paste reg key from one host to another is a bad idea.

.jar and .jnlp apply to HKMU (switches between hklm and hkcu depending on machine or user installation)

.jnlp apply only to Java 8

Adding/splitting the installer features in two groups will break actual feature level compatibility. So no

You can probably use a tool to monitor wich reg key is written by the installer
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
and then extract this key as registry patch
or create a list of command with https://docs.microsoft.com/fr-fr/windows-server/administration/windows-commands/reg-add

I’m not yet sure what the exact problem is. [. ]

Reproducing the windows registry settings that get set by the installer after having extracted (either by hand or by using a tool like scoop) the zip-distribution.

What do you want to achieve? [. ] Do you need multiple Java versions and an easy way to switch between them?

Why is using an MSI not an option?

it is an option. i can do it via the installer. i thought there might already exist a way to have every needed jdk installed and switch the windows registry settings separately.

To write «Oracle Java Key» you must write to
[. ]
[. ]
.jnlp apply only to Java 8

@douph1 thank you for all the input!

Adding/splitting the installer features in two groups will break actual feature level compatibility. So no

snap, i liked the idea 🙂

yes, that is what i tried yesternight . i tried to use a tool called regshot, which produced a bit too much noise (many background regchanges also in delta result) . hmm .

would you maybe be able to suggest relevant reg-branches i should monitor for changes, @douph1 ? I currently built the following reg-file . and am trying now to switch the current version. But i probably have not grasped the picture well enough.

but what about [HKLMSOFTWAREWOW6432NodeJavaSoft]? Do i need both? (Win10 Pro x64)

I am starting to fear this rabbit hole.

A batch file supplied with the zip distro that sets the right entries is probably also too complicated?

//last edit: please excuse the edit-storm. it has ended now.

i re-read the commandline parameter section of https://adoptopenjdk.net/installation.html#windows-msi and tried a different angle (and already thought bad of me not having thought of that before)

I tried to omit the FeatureMain option when calling the msi-installer . so for example:

could maybe have done everything except installing files to target dir. But that did not produce the envisioned result.

uh this is hard.

but what about [HKLMSOFTWAREWOW6432NodeJavaSoft]? Do i need both? (Win10 Pro x64)

no. it is intended for Java 32 on Win 64

Your title «this application requires a java runtime environment» seems linked to «launch4j»
and as mentionned in #64 launch4j can but don’t rely on JAVA_HOME by default.

By default it look only onto JavaSoft
so you must look/create (depending of the java version)
«CurrentVersion» on

• HKEY_LOCAL_MACHINESoftwareJavaSoft JRE
  or/and
• HKEY_LOCAL_MACHINESoftwareJavaSoft Java Runtime Environment (for 1.8)
  and/or
• HKEY_LOCAL_MACHINESOFTWAREJavaSoft JDK
  and/or
• HKEY_LOCAL_MACHINESOFTWAREJavaSoft Java Development Kit (for 1.8)

into a subkey corresponding to this «CurrentVersion»
create a key «JavaHome» with the JAVA_HOME ( = INSTALLDIR (without bin ) )
and eventually (but I don’t know if launch4j required it ) «RuntimeLib» if it is a JRE with the DllPath as here https://github.com/douph1/openjdk-installer/blob/master/wix/Includes/OpenJDK.Variables.wxi

and for file association with exe you must certainly look at microsoft documentation if you intended to rewrite all the magic as Wix-installer does
Just to name a «magic» thing ..
https://stackoverflow.com/questions/51715292/best-way-to-get-file-type-association-in-windows-10-from-command-line

on systems running Windows 8 or later
..a new registry key was introduced and Windows now writes the user choice to
«UserChoice»

HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER

Both the «App Paths» and «Applications» registry subkeys are used to register and control the behavior of the system on behalf of applications. The App Paths subkey is the preferred location.

I’m even not sure if WIX/our usage of WIX installer use the new «App Paths» reg key
as I have already seen that .jar file association don’t work always.

After some weeks of inactivity i just re-read the whole thread and with this issue still being open i feel a bit of «something to do left» . so i would like to mention the rather hidden question of «my opening post» and leave the action of closing or further working on/with something to you. (You could also ask me to close it if that is the way to go)

If you think that this (something executable that would be included in the zip distribution) would be something that might be creatable . should i create a new issue asking for relating to just that (and relating to this issue as documentation of the thought process)?

In my first post i asked

«. is there a way to reproduce the things the installer does concerning creation of the the required registry entries?»

and in hindsight i might have clarified that i was not thinking of crafting the reproduction myself but that something like an executable script (or something similar) already might exist that would be included in each zip distribution.

@douph1 thank you especially for the last three thorough replies! Via your input i now have a better understanding of the windows client side peculiarities of the jre/jdk installation. Or the challenges applications have to find out about the configured java binaries to run with.

Thanks, too, to everyone who took the time to inspect this Issue. 🙂

If you really want to, you can create a PowerShell or batch script that does the registry alterations. But why? If you want that kind of automation, the MSI has you covered and even provides multiple safeguards you had to re-implement in the script. With something like scoop in the mix, it gets really hairy because you need to remove/update those entries. This is something that has to be solved by the application that manages you JDK installations.

For the record: I don’t think it makes sense for scoop or a similar tool to use the MSIs. VS Code does it and judging by the bug reports we get here, this wasn’t the right choice. If your tool does version management of JDKs, let your tool handle the registry stuff.

I just do some reverse engineering to a 32 bit executable produced by java. In fact, it just iterate over a hardcoded list of Registry path and iterate the subkeys inside it. and any one of them exists, it will work. The CurrentVersion key is in fact not check at all. The executable check the subkey name as version string, that ANY version above 1.8.0_45 will work so I randomly choose 1.11

So, All I need is put the following content inside a javahome.reg file, and double click it. and all exes requiring java works smoothly from now on.

You may tweak it a bit to suit your scenario. My openJDK version is jre-15.0.2.7-hotspot . besides, 64 bit or 32 bit doesn’t matter at all, so don’t care about WOW6432Node

Part of the list that any java executable will checked through:

Источник