I want to be able to display the release notes to the end user before the installation has started (e.g. if there are any code changes they should be aware of before upgrading to a newer version).
I've read the documentation regarding the Pascal code BeforeInstall and AfterInstall Parameters, but my problem is how can I make a reference to my release notes file as it is packed inside the setup executable? I realise the simplest answer would be to simply package the installer with a copy of the text file sitting alongside it so it could reference it in this way, but then if the user only copies the executable for example, this would presumably cause a reference error.
What is the best way to go about implementing this?
You are looking for the InfoBeforeFile directive:
[Setup]
InfoBeforeFile=infobefore.txt
Related
I have seen this was asked in the bask back in 2008 and can't find anything newer on the subject so I am bring it up again.
Is there a way to prevent a user from extracting the files from the installer and reading the nsi file.
I read something the opcode needs to be changed in the exe of nsis. Has NSIS come up with a plugin or something so users do not have to modify the exe?
If there an easy way or is it still messing with the exe. and if so can you point me in the right direction on how to do this or if someone has already posted a version
Thank!
NSIS is open source so it is not unsurprising that people are able to write decompilers.
There is no easy way to prevent it and the recommended method is still the same; change the order of the opcodes in \Source\exehead\fileform.h and compile NSIS.
To prevent most people from getting access to your files you can use one of the zip/7z/rar plug-ins from the NSIS Wiki that accepts a password and include a password protected archive in your installer. Keep in mind that a sophisticated user can run the installer in a debugger and find your password when you call the plug-in to extract the files.
I would if we can add some files(text or executable) to a NSIS installer with a tool(or not) after the package is done.
Thank you for your help
You cannot really append extra files after the compiler has finished. You can however append a small text string if you need to embed some sort of id/hash/serial number. This data can be read with the ReadCustomerData function from the NSIS wiki.
You can compile installers on Windows and POSIX based systems so you can build installers anywhere if you absolutely need to add a file that does not exist on your system...
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
InnoSetup has the ignoreversion flag for items in the [Files] section to specify that the file should be copied regardless of its version information. This is kind of the default that I would expect from a setup most of the time, yet it is not the default behaviour if it is not set. So I see this flag set in most setups for every file item, executables and non-executables alike.
I'm wondering what the file types are for which this flag makes any difference? Obviously .exe and .dll are affected, and .txt is not. Is there some definitive guide on this? I'd like to get rid of these extra flags on my file items if they serve no purpose.
The general recommendation I always give is to absolutely always use ignoreversion on every file in {app}.
It causes no harm on files without resources (and potentially improves performance in that Inno doesn't have to waste time discovering that they lack resources), and is almost always what you want for app files (otherwise you can end up in some weird frankenstate with a mixture of files).
However for files installed outside of {app} (typically either {sys} or {cf}) you usually should not use ignoreversion and should instead only permit upgrades. But YMMV.
(Note that special care may need to be taken for ensuring upgrades of common files outside of {app}, as only EXE and DLL files typically have version information, and even some of those may lack it or it may not be updated consistently, depending on the source of the file. Other considerations also apply to common files, such as using sharedfile.)
(Promoted comment to answer.)
For which file types is the "ignoreversion" flag meaningful ?
For those that can have Windows resources. Version information reading in Inno Setup falls deep down to Windows API so it's actually the system which determines from which files the version information can be read. Currently, the About Version Information topic specifies the files, that can have version information briefly as:
You can add version information to any files that can have Windows
resources, such as DLLs, executable files, or .fon font files.
Which narrows the list of possible files to the list of files that may contain resources. Unfortunately, there is no (and cannot be) a list of extensions of files, that might contain resources, because you can have a file with version information having some exotic file extension (I've asked for it a long time ago).
So, there is no credible advice, for which files you should keep or remove this flag.
Is the "ignoreversion" flag really intended ? When should I use it ?
More it makes me wonder, why to include the ignoreversion flag. I would say it should be used rarely and carefully only there, where you are sure a possible downgrade of a certain file won't hurt. Without it, the Inno Setup compares version of the installed file with an existing one and replaces it when it's older, which is in my view the most wanted behavior.
The version flags refer to the version of your application installer package and not to the DLL version of a file shipped with the installer. Because of this .txt files also have a version and the 'ignoreversion' flag makes sense for any file within the installer package. It's up to the developer to trace and adjust the file updates between application versions using any of the InnoSetup provided flags.
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.