[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349634#comment-17349634
]
Lars Bruun-Hansen commented on NETBEANS-2523:
---------------------------------------------
The bug still exists in the [Release Candidate for NetBeans IDE 12.4 Installer
for
Windows|https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.4-installers/windows/Apache-NetBeans-12.4-bin-windows-x64.exe].
For reference here's the Quick-and-Dirty method for how to "release" the fix:
# Build new binary for Windows from the jnilib project (repo path:
{{nbi/engine/native/jnilib}})
# Based on the [current binary package
used|https://netbeans.osuosl.org/binaries/2B892D9E648A792EDB0F705378E06F84C322E208-nbi.engine-external-binaries-11.zip]
you would create a new zip package which includes the updated binary (meaning
newly build version of (ZIP path) {{native/jnilib/dist/windows*.dll}} from step
1).
# Name the new zip package something like
{{nbi.engine-external-binaries-12.zip}} (i.e. bump its version) and upload it
to OSUOSL.
# The binary is used in project (repo path) {{harness/libs.nbi.engine}} which
would need to have its pointers to the binary on OSUOSL changed.
The reason why the method is called "quick-and-dirty" is that the audit trail
is lost. By using such method we cannot be sure from which git ref the binaries
at OSUOSL are build. In fact, we cannot even guarantee that what is at OSUOSL
is based on on source code committed and pushed to the Netbeans Git repo. Lot's
of discussions on this on the NetBeans dev mailing list.
As a parallel example, the build process for native binaries for Profiler Lib
project has been streamlined in
[PR2853|https://github.com/apache/netbeans/pull/2853]. Those binaries are now
build on a CI pipeline whenever the source code changes and a ZIP package with
git ref pointers is build as a result (which can then subsequently be put into
OSUOSL). Ideally something similar would need to be done for jnilib project. Or
use the quick-and-dirty method if in a hurry ... however such method is
unsustainable for the community in the long run.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
> ----------------------------------------------------------------------------
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
> Reporter: Joseph Szabo
> Assignee: Lars Bruun-Hansen
> Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png, 2021-01-03
> 08_22_56-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
