I just re-compiled my script after making a change to the exe.
I wanted to make sure the new exe got picked up, with the changes.
I assume that it did, but need to confirm before shipping.
Also, can I just add another file to the script? I already have a few, and I would use the same format, (put them in the same folder) Can I just add the line to the script and recompile it? If not, I can include it separatel (the manual)
Last edited by dglienna; Jun 11th, 2005 at 09:10 PM.
Yes, just add the new line and recompile. If you are using ********** just use the Add Files button to update your project with this new file. If you recompiled your exe, all you need to do is recompile the Inno Setup Script and the new exe will be picked up, if you put it in the same location the script is looking for.
Thanks. I though that was the case. I had trouble with a different app, but used P&D which worked. I edited the unsafe files list, and really messed things up. Instead of 6 files, I then had 15! I compiled in Unsafe mode with Script, but Inno didn't like it.
Yesterday, I updated Inno for the first time, and haven't tried it since. That's why I was hesitant to redo it. I know I had trouble with Norton's the first time, and didn't want to have to go through that again.
Also, downloaded the update to VB yesterday, and didn't know if that would affect things.
Why would you want to remove files rom the unsafe file list? They are there for a reason. If you recreated the script in unsafe mode you could just add a parameter to Inno Setup to compile in unsafe mode.
Otherwise you could have just copied the files marked as unsafe to a different folder and put that folder in the search path area. Inno Setup would not complain about that.
As a convenience to new users who are unfamiliar with which files they should and should not distribute, the Inno Setup compiler will display an error message if one attempts to install certain "unsafe" files using the [Files] section. These files are listed below. (Note: It is possible to disable the error message by using a certain flag on the [Files] section entry, but this is NOT recommended.)
Any DLL file from own Windows System directory
You should not deploy any DLLs out of your own Windows System directory because most of them are tailored for your own specific version of Windows, and will not work when installed on other versions. Often times a user's system will be rendered unbootable if you install a DLL from a different version of Windows. Another reason why it's a bad idea is that when you install programs on your computer, the DLLs may be replaced with different/incompatible versions, and were you not to notice this and take action, it could also lead to problems on users' systems when you build new installations.
Instead of deploying the DLLs from your Windows System directory, you should find versions that are specifically deemed "redistributable". Redistributable DLLs typically work on more than one version of Windows. To find redistributable versions of the Visual Basic and Visual C++ run-time DLLs, see the Inno Setup FAQ.
If you have a DLL residing in the Windows System directory that you are absolutely sure is redistributable, copy it to your script's source directory and deploy it from there instead.
ADVAPI32.DLL, COMDLG32.DLL, GDI32.DLL, KERNEL32.DLL, RICHED32.DLL, SHELL32.DLL, USER32.DLL
These are all core components of Windows and must never be deployed with an installation. Users may only get new versions of these DLLs by installing a new version of Windows or a service pack or hotfix for Windows.
(Special case) COMCAT.DLL, MSVBVM50.DLL, MSVBVM60.DLL, OLEAUT32.DLL, OLEPRO32.DLL, STDOLE2.TLB
If DestDir is set to a location other than {sys} and the regserver or regtypelib flag is used, then the above files will be considered "unsafe". These files must never be deployed to and registered in a directory other than {sys} because doing so can potentially cause all programs on the system to use them in favor of the files in {sys}. Problems would result if your copies of the files are older than the ones in {sys}. Also, if your copies of the files were removed, other applications would break.
COMCAT.DLL version 5.0
Version 5.0 of COMCAT.DLL must not be redistributed because it does not work on Windows 95 or NT 4.0. If you need to install COMCAT.DLL, use version 4.71 instead.
Reference: http://support.microsoft.com/support.../Q201/3/64.ASP
COMCTL32.DLL
Microsoft does not allow separate redistribution of COMCTL32.DLL (and for good reason - the file differs between platforms), so you should never place COMCTL32.DLL in a script's [Files] section. You can however direct your users to download the COMCTL32 update from Microsoft, or distribute the COMCTL32 update along with your program.
Reference: http://www.microsoft.com/permission/...p-soft.htm#COM
Reference: http://www.microsoft.com/downloads/d...DisplayLang=en
CTL3D32.DLL, Windows NT-specific version
Previously, on the "Installing Visual Basic 5.0 & 6.0 Applications" How-To page there was a version of CTL3D32.DLL included in the zip files. At the time I included it, I was not aware that it only was compatible with Windows NT. Now if you try to install that particular version of CTL3D32.DLL you must use a MinVersion setting that limits it to Windows NT platforms only. (You shouldn't need to install CTL3D32.DLL on Windows 95/98/Me anyway, since all versions have a 3D look already.)
SHDOCVW.DLL, SHLWAPI.DLL, URLMON.DLL, WININET.DLL
These are core components of Internet Explorer and are also used by Windows Explorer. Replacing them may prevent Explorer from starting. If your application depends on these DLLs, or a recent version of them, then your users will need to install a recent version of Internet Explorer to get them.
Description:
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
allowunsafefiles
Disables the compiler's automatic checking for unsafe files. It is strongly recommended that you DO NOT use this flag, unless you are absolutely sure you know what you're doing.
You can just download the unsafe file from the website and put it in the ********** folder. you can re-install also but you should back up the **********.ini file first.
The site appears to be down now, the file won't transfer. I'll leave it for a few minutes while i'm in another tab, and then try it later. OK. Got it. I was looking at the latest log, and it seems to say that Winsock was removed. This was a simple receipt printer, that did not use winsock, urlmon, or mapi.
Hope I have better luck next time.
Where should I place the three ocx files? dbgrid32.ocx, msadodc.ocx, and richtx32.ocx ? I had them loaded individually as files that i added, but they didn't get picked up for some reason. It also picked up msbind.dll from my added files from a previous app that I compiled.
Should I add a folder for the common vb files?
I've also not added anything to my system path, which makes for a long wait to create the script. How to rectify that so I don't have problems in the future?
You can copy those files to another folder then put the folder name in the Search Path Area. ********** will find them there.
Each time you use the ********** project it will add to the Search Path Area all the locations it finds files so that it will not take long on each additional run.
Recompile Question about INNO [Resolved]
Reply With Quote
