One of my users sent error report that the installer has crashed with following error:
Runtime error (at 34:1346): Type Mismatch
The installer uses Inno Setup. The investigation showed that the bug caused error has been contained in installer.iss.
Where can error be located if I know "34:1346" ?
That error location is in the compiled bytecode of your script and as such is pretty much impossible to track back to a line of code.
If they can reproduce it, they should launch your installer with /log=filename command line option and you can take a look into such file.
Related
I have an InnoSetup script I have been using for years, and suddenly it stopped working, specifically on this line in the [Setup] section:
WizardImageFile={src}\..\..\images\InstallBanner.bmp
The error reported is:
Compiler Error!
Line 47: Could not read "C:\projects\xxxx\installer\{src}\..\..\images\installbanner.bmp".
Error: The system cannot find the path specified.
Two potential problems I noticed, {src} is still in the file path reported, and the file name is all lowercase. Except for these two issues, the file name is correct, and the file exists.
Am I using the {src} constant incorrectly and this has previously worked by coincidence, or is this a bug that was introduced with an update?
Currently running 6.0.2. I know 6.0.4 is released, but cannot currently install it, and didn't notice an issue like this mentioned in the revision history.
You cannot use constants in WizardImageFile. It makes no sense. The constants are evaluated on runtime. While WizardImageFile is read on compile time. Also {src} refers to the path, from where an installation was started. How would it evaluate, when you are only building the installer?
If it ever worked, you must have subfolder with literal name {src} somewhere on the path, where you were compiling the installer.
As #MartinPrikryl said, {src} and other constants cannot be used as they are evaluated at runtime. Definitions may be used, and the {#SourcePath} definition works as a starting path relative to the script location
WizardImageFile={#SourcePath}\..\..\images\InstallBanner.bmp
I have the following test InstallScript InstallShield code, which executes correctly in the normal interactive mode, but crashes setup.exe /s (silent) mode on calls to ChangeDirectory that involve any sort of actual depth of directories.
//Note: "C:" ^ "temp" resolves to "C:\temp", but it never successfully
//executes when run silent mode. It works fine in interactive mode, however.
ChangeDirectory("C:" ^ "temp");
//No subsequent code gets executed at this point in silent mode
I'm running this on a Windows 2008 x64 Server in a command window with Administrator privileges. The c:\temp directory exists, and EVERYONE has been granted full control rights to it.
The exit code is -2147213312, which is 0x80042000 in the error guide corresponding to
The installation exited with the abort keyword because the end user
canceled the installation.
What could possibly be going on here? I've tried using the try/catch syntax to examine the error, but the catch block never executes in this case, seemingly asserting that there's no error but instead an abort called?
The Installscript Engine does a lot of stuff behind the scene. It keeps changing the working directory. Thus, it is not very reliable to use ChangeDirectory(). It is surely better to use FULL PATH to all executables and other files. LaunchAppAndWait() too has this trouble. So full path needs to be used without fail.
Further, the Installshield help for ChangeDirectory() clearly mentions the following:
When you are specifying a file in your script, always specify the full
path (using the appropriate InstallShield system variable, for
example, SRCDIR) rather than depend on the current folder having the
appropriate value. The script internally executes code that can change
the current folder, so its value may not be what you expect.
The thing is, results are not reliable. They may work or may not.
We get this errorcode when our recorded .iss file is missing an entry in the .iss response file.
See Creating the Response File for more Details.
Logging an installscript setup didn't give us much information, so we wrote some functions to write to a custom logfile which helped us a lot.
Error 2 error LNK1104: cannot open file 'OgreMain_d.lib' C:\Users\Owner\Documents\Code\C++\Test\ogrevcpp\ogrevcpp\LINK ogrevcpp
This is the error I get when trying to build an Ogre3D application (with steps followed from here).
I've followed everything to the T, yet I still get the error. It honestly shouldn't be happening. I've also followed everything from here.
Edit
What's happening is there are two different files, one is meant for release, the other is meant for debug. I need the one for debug mode to compile properly (which is OgreMain_d.lib).
Update
I figured out what the problem was - I was using the incorrect binaries; there was a few releases which were meant for Visual C++, and one which was meant for MinGW, along with a few other compilers. My apologies.
You need to check your library paths to make sure that the path where OgreMain_d.lib lives is part of the library path.
I guess the library for Debug mode is not present in the lib folder. Try putting two different libraries folder for each Assembly mode in Visual Studio. Go to ProjectProperties -> Configuration Properties -> Linker -> Additional Library Directories on Right hand. Make sure to check the Configuration Dropdown on the top.
I have built Basic MSI in InstallShield 2011. I have .NET Installer class in my project. When I install the .msi I am getting Error 1001 and rolls back. A temp file "TBD8BEA.tmp" is created in ProgramFiles folder. Temp file has binary content but has a sentence "This program cannot be run in DOS mode." What is the reason for this error and what is the solution. Pls Help me.
The text "This program cannot be run in DOS mode" is the string that is displayed when you try to run a Windows executable in, you guessed it, DOS mode. I would guess that your .tmp file is probably executable. The message is not an error message; rather, it's part of the executable program's data. You can verify this by opening various other executables in a hex editor; that's where I recognized it from.
Other than that, you should probably give some more information and/or examples of what you tried - the question is somewhat on the unspecific side for people to be able to help you.
When I try to compile my c++ dll I get this error
mt.exe : command line error c10100a9: Some operation on the input manifests must be specified (even if it is just to pipe the input to the output). Use the /? option for help on usage and samples.
I have disabled Manifest Tool from the properties menu, the only reason I did that was because it was giving me a hard time to compile.
Now I can build my DLL, but only once every three times, because of the above mentioned error.
Any help to get rid of this problem would be appreciated.
I found solution by (project properties ->Configuration properties ->Manifest Tool ->Input and Output) in Output Manifest File type:
$(IntDir)$(TargetName)$(TargetExt).embed.manifest
and press Ok.
I see this q is languishing. Is the problem you have now better or worse than what you had before disabling Manifest Tool? Perhaps it would be worth re-enabling it and trying to work through those problems.
I have never seen this error, though I know MT.EXE has had a few problems. Make sure you have the latest SP for your VS installation as well.