I am trying to build installer using InstallShield's commandline tool IsCmdBld.exe. It builds something, but when I try to open it, it returns following error.
I have used
"C:\Program Files (x86)\InstallShield\2015\System\IsCmdBld.exe" -p "D:\Installation_Builds\MyInstallations\MyInstaller.ism" -r "Compressed EN Build" -c COMP -a "CompEN"
as a command. Seems very straight forward. In fact if I do not insert -c COMP and generate uncompressed installer, it has no problem. However, the size of installer over all becomes 23GB so it is not acceptable.
I do see ISDEV : fatal error 0: followed by nothing else. I googled a bit and found http://flexerasoftware.force.com/ka1G0000000TljoIAC but I cannot seem to understand why this is occuring when I can perfectly build it without the use of commandline tool.
Any inputs would be appreciated. Thank you.
EDIT : after adding -v to the building command, little bit more detailed error showed up.
1627: Error saving the changes to [XX.msi]
I do not know why it is erroring on saving the change.
make sure your .msi is not readonly.
the best way we found for using the isCmdBld is with this cmdline :
ISCmdBld.exe -p "%ProjectName%" -a "%Configuration%" -r "%ReleaseName%" -x -o "%MergeModulePath%" -prqpath "%PRQPath%"
you'll have to make sure the %Configuration% and %ReleaseName% are the exact same as those in the ism (case Sensitive) (Media|release).
Related
Im working on minix 3.2.1 . I just put a :
printf("hi");
command in do_mkdir -> open.c ,in many lines , so when i use mkdir 'name' command in shell it prints hi.
I put this printf inside :
mined /usr/src/servers/vfs/open.c in do_mkdir function
and i compile it with :
cd /usr/src/
make hdboot
and then i reboot. But it just make file, it wont print hi.
I tried compile with make install too.. but nothing.
I think its problem with compiling. Any idea?
Keep in mind that make hdboot is a command that you can use when you're in the usr/src/realeasetools directory. Therefore it's possible that your mistake is simply this. If however that's not the case, then there's a possibility that you're missing some tools. Apart from make install try to update your minix. ( I think the command is make update, not sure though)
I am new to vxworks and getting the problem after loading the VxWorks image from host machine to target machine. After loading the image at target machine(including build in symbol table), I am getting issue in commands cd, ls etc. cd command is getting success but while executing ls command after the cd it shows error as value = -1 = 0xffffffff(print error code as 0x3d0004). I am not able to resolve the issue after a lot of tried in building the VxWorks images. Request anyone to please help in this regard. I am also not sure whether the cd command is executed successfully or not since I am not able to see any FTP message on the network while executing the CD or LS command.
Thanks
Vaibhav
Propably the initial directory is not set. Try changing to one of the drives of your machine (e.g. cd "/tffs0") before using ls or commands like that.
To obtain a list of all available devices type devs.
I'm trying to generate a c++ project using cmake on Windows 7. Before it actually makes the project though it looks cmake does a quick test of your toolchain (I'm using MinGW) and that's where my problem. Cmake triggers a make build which ultimately fails with the response "The system cannot find the path specified."
I ran the particular makefile that was failing in dry run mode (-n) and manually executed all the commands:
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
echo Building C object CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj
C:\PROGRA~2\CODEBL~1\MinGW\bin\gcc.exe -o CMakeFiles\cmTryCompileExec306416588.dir\testCCompiler.c.obj -c C:\SFML\CMakeFiles\ CMakeTmp\testCCompiler.c
echo Linking C executable cmTryCompileExec306416588.exe
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\cmTryCompileExec306416588.dir\link.txt --verbose=1
And they all executed without error leaving me with a functional .exe file as expected. However when run through make I return the error:
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
The system cannot find the path specified.
mingw32-make.exe: *** [CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj] Error 1
I then experimented with replacing all of the commands with something simple like "dir" and noticed that when run through make is returned "The system cannort find the path specified" again before printing out the dir information and exiting with an error.
My next step, and about as far as I've gotten, is to run make with the -d flag; the interesting bit being:
Creating temporary batch file C:\Users\CJ\AppData\Local\Temp\make8664-1.bat
Batch file contents:
#echo off
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
CreateProcess(C:\Users\CJ\AppData\Local\Temp\make8664 1.bat,C:\Users\CJ\AppData\Local\Temp\make8664-1.bat,...)
Putting child 00490378 (CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj) PID 4730176 on the chain.
Live child 00490378 (CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj) PID 4730176
Main thread handle = 00000074
The system cannot find the path specified.
Reaping losing child 00490378 PID 4730176
Cleaning up temp batch file C:\Users\CJ\AppData\Local\Temp\make8664-1.bat
mingw32-make.exe: *** [CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj] Error 1
I don't really know too much about the inner workings of make but from what I can tell from this output it looks like it has something to do with the temporary batch file that make is making. I looked at this stackoverflow post What causes GNU Make to shell out and it looks like what triggers a temporary file to be made is pretty vague. I was able to find a command that executed without the creation of a temporary batch file ("ls" from the windows Git bin) and sure enough it executed via make without returning the "The system cannot find the path specified" response like the "dir" command did ("dir" caused make to generate that temp file).
I feel like I've kind of hit a wall with my debugging abilities and am turning to you guys to see if you can offer any advice. Does it seem like I'm making the right assumptions? Do you have any insights into what may be manifesting the problem?
It looks like I was able to figure out the problem on my own so sorry for bothering with the post. It turns out that the problem wasn't with Make but instead with cmd itself (which would explain the error whenever make tried to run a batch file). It looks like somehow (possibly through some kind of malware that snuck onto my system or maybe some kind of misguided windows update) the Command Processor's registry key was set to something like "C:\Users\CJ\AppData\Roaming\Microsoft\Windows\IEUpdate\RMActivate_ssp.exe" which I recall specifically wiping from my computer not too long ago, hence the "The system cannot find the path specified." message whenever a cmd process was spawned by make (I guess I just totally missed it when I opened up the root cmd process). In any case, this was a simple fix following the instructions at https://superuser.com/questions/727316/error-in-command-line-the-system-cannot-find-the-path-specified, after which I was able to run the make, and subsequently cmake, build without any problems.
The keys in question are
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun and/or HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
Also this error can occur if you picked MSYS toolset in Cmake, but running it under a normal shell. In this case make tries to compile something like /c/source/build/stuff.cpp and normal Windows ABI rejects this path.
A great diagnostic method for this issue is --debug-trycompile flag for Cmake. If something has gone bad, you can re-run the failed command manually or peek into generated files to find the cause.
We are launching our installer build using IsCmdBld.exe and would like to define at buildtime the name of the Setup File Name .exe
I have tried doing this by passing a command similar to this:
IsCmdBld.exe -p c:\project_path\installer_project.ism -c "My Custom Configuration" -z "SetupFileName=My App 1.0"
Unfortunately, it seems SetupFileName is ignored.
Anybody got ideas?
This may not be the exact answer you are looking for, but if you want to change the name within the project for each build, go to the Media / Releases menu. Click on the project name under "Releases", and in the General information is the Setup File Name. Enter your desired name here without the '.exe' extension.
Using Installshield for VS 2015 this is the updated answer:
Typically you would want your setup.exe to stay the same name every time you build. Especially the MSI filename. The version of the file can be set on the command line.
So for our setup, we specify the desired name of the setup.exe and msi filename in the product/release configuration of the ISM. Then on the command line, we always call the ISM with the same command line, which gives us repeatability/reliability.
"C:\Program Files (x86)\InstallShield\2012Spring SAB\System\IsCmdBld.exe" -p "E:\Path\to\the.ism" -y 3.6.356.2 -a "PRODUCT_CONFIGURATION" -o "E:\local\mergemodules"
-y sets the version (ProductVersion) which also sets the resulting EXE version
-a specifies the product configuration
-o specifies a folder for merge modules (we limit the merge modules we consume)
In my Xcode project, I've created a symbolic link script in the target that allows me to edit my scripts and see the updates live. Unfortunately, a side-effect of this is that if I don't clean before building again, I get the following error message:
ln: /Users/atg/Desktop/Projects/Xcode Projects/Debug/Xsera.app/Contents/Resources/: Directory not empty
for the following line in my script:
ln -F -s -f "$PWD/../Resources/" "$BUILD_ROOT/Debug/$UNLOCALIZED_RESOURCES_FOLDER_PATH"
I know that this is the correct line because it works when I build after cleaning, but doesn't work if I build without cleaning.
What I would like to do, therefore, is to figure out how to allow builds without cleaning. I think the easiest way to do this would be to force a clean before I build, but if anybody knows any other way of removing the error, that would be great as well.
Thanks!
After a little sleuthing over twitter, we came up with the following solution:
if [ ! -d "$BUILD_ROOT/Debug/$UNLOCALIZED_RESOURCES_FOLDER_PATH" ];
then ln -F -s -f "$PWD/../Resources/" "$BUILD_ROOT/Debug/$UNLOCALIZED_RESOURCES_FOLDER_PATH";
fi;
That way, if the directory exists, it doesn't bother with the linking, since it's already established.