Tagged: longchamp lm platine
- This topic has 10 replies, 4 voices, and was last updated 7 years, 1 month ago by Anonymous.
February 22, 2014 at 7:00 am #9747AnonymousInactive
Just wanted to verify that the uninstallall switch actually does anything. When I use it the only thing it does is open the application, shouldn’t it immediately open the java uninstaller? Right now it does nothing different than if I just open the .exe on its own. I am using version 2.5. I am not using the /silent switch either since it says it wont work with it. Using the purge and clean switches works great, the only thing it doesnt do is actually remove the application from the program and features section of windows 7 which is causing an issue for its intended purpose. After the purge is the application still supposed to be listed or is that not working for me correctly as well? Any help would be great.
Thank youFebruary 22, 2014 at 10:23 am #9748
The uninstallall switch will call each uninstaller in a row. Of course, this can only happen in JavaRa is actually able to detect an uninstaller. Can you confirm whether they’re detected when you open the executable normally?
The /purge switch will leave the ‘Add or Remove Programs’ entry in tact. It’s only supposed to remove the files and registry keys missed by the uninstaller.February 28, 2014 at 7:46 pm #9752AnonymousInactive
Got the same problem here and I’m getting the following information in the JavaRa logs:
Exception encountered in module [JavaRa]
Message: Object reference not set to an instance of an object
Trying to remove Java 7 Update 11 from a W7x86 client.
It works when I run it through the GUI but that wouldn’t be possible to use when uninstalling through a SCCM-deployment 🙁March 5, 2014 at 5:18 pm #9769
What operating system are you running? And is it x86 or x64?March 5, 2014 at 5:26 pm #9770AnonymousInactive
As I wrote in my earlier post I’m running Windows 7 Enterprise x86 but I get the same result/error when running it on a Windows 7 Enterprise x64 client.March 7, 2014 at 1:12 am #9772AnonymousInactive
I’m having the same issue as raexx and vferg.
I would like to use JavaRA in an SCCM deployment to remove all discovered versions of Java from clients. JavaRa is an exceptionally effective tool during manual use, but I have no ability to deploy it to machines and run an uninstall silently. I get the same error as raexx described.
Is there currently any resolution/workaround/expected timeline for a fix?
Thanks for the great product. I hope this issue is resolved soon. JavaRa is going to be a lifesaver for us.March 7, 2014 at 8:59 am #9775
There’s still no ETA for a bug fix.
Just to give you a bit of background information; the issue is being caused by differences in Windows x86 and x64. Each stores the list of installed programs (and the MSI uninstall string) in a different location in the registry. The Windows registry is pretty cruel; automatically redirecting JavaRa’s registry access to the WOW6486Node (on x64) and throwing the “object reference not found” error when it realises the redirect was an idiot move.
The workaround is pretty simple. Setting the compiler flag to “x86” prevents the redirect from occurring, but makes the x64 registry hives invisible to JavaRa. Compiling against “Any CPU” has the inverse affect.
The logical answer would be to compile two different versions of JavaRa; but obviously this isn’t practical if being run across a network, as many different OS setups could be in use.
We’re currently investigating a workaround method that involves invoking native code, thus circumventing Windows’ annoying registry reparse “feature.”March 7, 2014 at 4:50 pm #9777AnonymousInactive
Wouldn’t it be possible to add a check before running the Java-uninstall that checks if it’s running in a 32 or 64-bit environment?
After the check there could be 2 functions (x86 and x64) that executes depending on the environment detected.March 8, 2014 at 2:16 am #9778AnonymousInactive
raexx, I may be wrong, but if I understand the situation I don’t believe this would work.
Rather, could you provide an x86 compiled version of JavaRa for use on 32-bit windows to remove 32-bit Java, as well as on 64-bit windows to remove 32-bit Java (this being my use case, all 64-bit windows with 32-bit versions of Java installed), and provide a seperate, x64 compiled version, for use on 64-bit machines with 64-bit Java.
It would then be up to the end user to appreciate the intended application of each version and use it accordingly. If I ever happen to have 32 and 64-bit Java on a particular machine, I will simply deploy both versions of JavaRa.
From my perspective this isn’t even remotely an issue, as I, and others who deploy software day in and day out, are familiar with and frankly, accustomed to, deploying 32 and 64-bit versions of the same software.
Does this seem like a reasonable solution?March 9, 2014 at 6:49 pm #9779
We could always take the Piriform approach and include JavaRa.exe and JavaRa64.exe in the downloaded archive.
Most people will automatically run JavaRa.exe, even if they’re on a x64 system; so the x32 binary would need to detect the OS and call the x64 binary when necessary. This call could be disabled if the user specifies a commandline argument, as it would be assumed such a user would be aware of the implications of calling the wrong binary.