I recently upgraded my Inno Setup from version 5.4.3(u) to version 5.5.5(a), and now I'm getting an error for a script which used to compile fine with the previous version.
This is Inno Setup's output:
[ISPP] Preprocessing.
[ISPP] Preprocessed.
Error on line 1 in c:\Workspace\MyProject\MyInstaller.iss: Text is not inside a section.
The line in question is:
#if MYLANG == MYLANG_ENGLISH
So the processor is running, but somehow this line is not preprocessed. Why does this happen and how do I fix this?
It turned out that the problem was that I had upgraded from a Unicode version to an ASCII version. After re-installing, this time with 5.5.5 (u), I don't get any errors anymore.
Related
I'm trying to solve the issue where InnoSetup doesn't delete no-longer-used files on upgrade. That is, you install version v1.0 of your application which installs a file that is not used v1.1. During the upgrade to v1.1, the unused files is left behind. Meanwhile, the uninstaller for version v1.0 will remove all of 1.0s files and the uninstaller for 1.1 removes all of 1.1s files. A suggested fix is to programmatically launch the uninstaller for v1.0 during the upgrade.
There's a couple of ways of doing this. One is to use a procedure named CurStepChanged(CurStep: TSetupStep). In the procedure you can watch for the ssInstall step and start the uninstaller there during upgrades. I was having some problems with this, and instead tried using the the BeforeInstall parameter to launch the uninstaller if an upgrade is detected.
Unfortunately, whenever I try this, the installer fails at the very end with a generic
Setup cannot find the specified file
Anyone experienced this and know the cause or have suggestions for further troubleshooting?
You are correct that IS does not automatically delete files no longer needed by a previous version when upgrading and that you must do so yourself, and as you noted, one way to handle this issue is to automatically uninstall the previous version before upgrading.
If you are certain you really want to uninstall before upgrading (and/or downgrading), you can use a DLL I wrote for this purpose (requires IS 6.0 or newer):
https://github.com/Bill-Stewart/UninsIS
The Sample Inno Setup Usage section in the documentation on that page explains how to use the DLL in an Inno Setup project. You can decide whether you want to uninstall the existing installed version when either upgrading or downgrading.
On a Windows machine I've been using Groovy in Gradle projects in Eclipse for some time now. Now I'm trying to configure for a Linux machine. (Linux Mint MATE). uname -a gives this:
Linux mike-Latitude-E6410 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2
15:58:04 UTC 2016 i686 i686 i686 GNU/Linux
Eclipse Oxygen. Installed Groovy (2.4.15) using this link: http://dist.springsource.org/snapshot/GRECLIPSE/e4.7/
Installed Gradle (4.7) using Buildship Gradle Integration 2.0.
Then I put this line in build.gradle:
compile group: 'org.codehaus.groovy', name: 'groovy-all', version: '2.4.15'
I make a new "source directory" under the project: src/test/groovy.
I make a new file under that: "Test.groovy".
I put one line in that: println "hello world".
Without changing the "source sets" in build.gradle yet I now see one of those dreaded "red exclamation marks" next to the one line of the file. The message is:
Multiple markers at this line
- The type groovy.lang.GroovyObject cannot be resolved. It is indirectly referenced from required .class files
- The type groovy.lang.MetaClass cannot be resolved. It is indirectly referenced from required .class files
- implements groovy.lang.Script.run
There are surprisingly few reports (particularly recent ones) of this problem in SO or more generally when I search.
One suggests adding the Groovy Runtime Libraries to the build path configuration ... did that: not solved.
NB I have also tried repeatedly 1) rebuilding the project 2) refreshing Gradle 3) running the "build" task 4) closing Eclipse and starting up again.
NB2 I have not yet installed Groovy or Gradle in the general system: only for Eclipse. Could this be anything to do with it? Seems unlikely.
Seems like this was a "schoolboy error".
I just had to include this line in build.gradle (I haven't currently got access to my other machine so wasn't able to make the comparison).
apply plugin: 'groovy'
Will leave the question, unless there is massive objection, because it might help others who get puzzled...
For me problem was: I had put my XXXSpec.groovy file under src/test/java instead of src/test/groovy
I'm trying to compile boost 1.66.0 on my Windows machine. I've got Visual Studio 2017 (Community) installed as my IDE and the 14.1 compiler definitely works. However, if I try to invoke this inside any of the VC2017 native command prompts
.\bootstrap
.\b2 variant=debug,release link=shared,static threading=single,multi address-model=64 toolset=msvc-14.1
I get plenty of the following errors:
'cl' is not recognized as an internal or external command, operable
program or batch file
If I change the toolset to msvc-14.0 everything works fine. I've also compiled boost 1.65.1 with msvc-14.1 sucessfully. However, there have been a number of Visual Studio updates since then.
Edit: I've tried compiling boost 1.65.1 again with the most recent compiler version (19.12.25834) and I get the same issue now. Calling "cl" manually inside the "x64 Native Tools Command Prompt for VS 2017" works fine though.
My solution was to:
Delete "C:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd"
Build again
My assumtion of reason: Boost makes a temporary "cmd" file which might be from an old build that did not support "msvc-14.1". The file is not rebuilt/deleted.
Background:
I had the same issue with one of my two development machines, both very similar (Windows 7) and updated with VC2017.3. The one working complained about the "Unknown version" (_MSC_VER=1911), but completed the building. The failing one had the "cl is not recognized" error. When looking at the point of failure it explicitly said that it was calling "C:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd".
I did a compare at both machines and found that the failing one did not include setting __VSCMD_PREINIT_VCToolsVersion=14.12.25827. There might have been other differences but this one was for sure.
I assumed that I was missing some SW packages or environment settings, but found it strange that the file was not deleted when doing a "b2.exe --toolset=msvc-14.1 --clean-all".
My solution was to delete the temporary cmd file - allowing it to be rebuilt.
After manually deleting "c:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd", the building worked fine (except for the 1.65.1 complains about the version _MSC_VER=1911).
I am trying to install node-v7.10.0-x64.msi on my windows 64 bit system, it will automatically rolling back at the end. I'm getting same error for other versions as well.
I have added my log file also here with. Log file
Appreciate any solutions.
Try to set "performance counter" to "Install when required" during installation
This should let you complete the installation.
I try to uninstall Java ME SDK from Windows 7 x64, but it doesn't work for me.
If I choose Uninstall I get a progress bar, then it goes away, but the Software is still there.
On the first few times I did this, I got the same error message as in I need help UNINSTALLING Java ME SDK:
... show message dialog
title: Critical Error
message: Cannot load native library from path: native/jmesdk/windows/windows-x86.dll
Exception:
java.lang.UnsatisfiedLinkError:
C:\Users\Jonas\AppData\Local\Temp\nbi-8367277139934329064.tmp: Can't load IA 32-bit .dll on a AMD 64-bit platform
In ref to getting the uninstaller to use the 32-bit JRE, the config I attempted that failed to work:
a) Set the PATH environmental variable to point to the 32-bit JRE
b) Windows registry edits in HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.6 to point to the 32-bit JRE.
In a last ditch effort I renamed \Program Files\Java to Java2, and the uninstaller must have searched to find \Program Files (x86)\Java, the 32-bit JRE, and the uninstall worked.
Seriously, Sun/Oracle. Test your products.
I had the exact same problem and I figured it out. :)
It's because you have the 64-bit JRE installed. Either uninstall it or somehow redirect the J2ME uninstaller to use the 32-bit JRE on your system, so that the 32-bit uninstaller can run instead of the 64-bit uninstaller.
I had the same problem and figured the solution out. As mentioned above you need to make sure J2ME unnistaller only recognizes Java x86. The simplest way I found, instead of unnistalling Java x64, you only have to temporarily rename your Java x64 installation folder to anything you want. That is, rename the folder C:\Program Files\Java to, e.g, C:\Program Files\JavaTEMP.
Now run unnistaller. When finished rename the folder back it's previous name.
That's all.
Hope I helped.
Just perform the following steps and you will be done:
1) Click on the link below and click on any of the ...i586.exe link according to your system
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
2)Install the software without changing default settings.
3)Run cmd command and type the following:
C:\Java_ME_platform_SDK_3.0\uninstall.exe --javahome "C:\Program Files (x86)\Java\jre8"
4)[optional] uninstall java 8 from control panel which you downloaded to uninstall the above software.
Congratulations.. You just did it!!
Thank you for reading.. Any suggestions or aprreciation is welcomed..
Turns out I had exactly the same problem, uninstall java (TM) 7 64bit and locate the 32-bit java installer bone this download uninstall it and try to install the Sun Java Wireless Toolkit and uninstalled correctly.
Just run this command:
C:\Java_ME_platform_SDK_3.0\uninstall.exe --javahome "32-bit jre location"
Rather than temporarily moving the x64 JRE out of the way, just tell the J2ME SDK uninstaller to use the 32bit JRE:
C:\Java_ME_platform_SDK_3.0\uninstall.exe --javahome "C:\Program Files (x86)\Java\jre7"
Note that this provides the path to a JRE within the "Program Files (x86)" directory, which is the 32bit variant. I only had a Java 7 JRE, but this ought to work with a Java 6 JRE, also.