I am building a plugin for NSIS with VS 2010 and I would love to set up the project so that a test setup is automatically built from a simple NSI file.
All seems fine except I can't figure out how to make NSIS look for my plugin in my project's output folder instead of C:\Program Files (x86)\NSIS\Plugins\*.dll only.
Are there any commands I can put in my NSI script to make NSIS look for my freshly built plugin outside of "standard plugins folder"? It seems rather odd to have to copy my DLL each time I wanted to test it.
Any help is appreciated.
You can use !addplugindir directive, see nsis compile-time commands.
Use !addplugindir directive with defined symbol (/D on command line).
Symbol is "the path to your location of .dll file"
For VS 2010 is the best option to use Visual & Installer - free VS addin for developing NSIS installers directly in Visual Studio.
Set your symbol in Project properties:
Download here: www.unsigned-softworks.sk/visual-installer/
As others have mentioned, the !addplugindir directive in your NSI script file will do the trick, and you can define a variable to pass to that directive on the command line using /D.
As for the code to add to your NSI file, you need something like this:
!ifdef EXTRANSISPLUGINSFOLDER
!addplugindir "${EXTRANSISPLUGINSFOLDER}"
!endif
Then on the command line, you can call your NSI script like this:
makensis.exe /DEXTRANSISPLUGINSFOLDER=C:\somefolder\moreplugins\ YourInstallerScript.nsi
When defining the extra folder, you might find that having any spaces in the folder path causes problems, and using quotes around the path doesn't help. To work around this, try using the dir /x command in the Windows terminal to list the 8.3 DOS names for the folders with spaces in their name. This will help you build up a folder path that doesn't contain spaces. (eg C:\Program Files\ often becomes C:\PROGRA~1 when listed with dir /x from the root of C:)
May have missed the point here but could you not have used an XCOPY post build event to copy the output to the NSIS plugins directory?
Related
I am creating a NSIS installer which installs multiple .exe's as well. Now these other .exe's makes the installer bigger than 2GB which is the set limit. I used WinImage PlugIn which is supposed to remove the limit. I replaced the files in my NSIS folder with these of the PlugIn's but i still receive the same error. Any help will be greatly appreciated.
If you are still hitting the compiler limitation then something in your install script is still including large file(s) directly into your .exe.
To use the WinImage plug-in you first must compile a installer that just builds the .wim file locally on your machine. Then you must remove the File/File /r commands from your installer and replace them with calls to the WinImage plug-in.
I'm following this link for installing GLPK which I intend to use to conduct some optimization. When I've downloaded GLPK, and added
C:\Windows\System32 and C:\Windows\SysWOW64
to PATH for environment variables and try to execute one of the example files (even by opening the cmd window in the file where the test file is located) by doing
glpsol --model assign.mod
It says that
glpsol is not a internal command, external command, program or command file.
When I open the command in the win64 folder (a subfolder of glpk) then I can do:
glpsol.exe --help
and get information. I can also see the glpsol programfile in the folder. However when I try to open a model somewhere on my computer it does'nt recognize glpsol. Isn't that why you add System32 into your PATH?
In the guide it says that
...Therefore it is suggested to copy the DLLs to %SystemRoot%nsystem32.
Is this something that you must do? Which are these DLLs? Can you do this using a command in the cmd file? I thinking that including System32 into the path does this?
I've added SysWOW64 into the path due to me using 64 Bit Windows 7. Not sure if it is the way to go though.
Hope someone can shed some light into this!
Regards,
To use glpsol outside of the dedicated folder you have to put the relevant files somewhere, where your System can recognize them (somewhere in the defined Path Environment)
The "DLLs" are just the glpk_X_XX.dll, for 64bit systems use the dll in the w64 folder and put it in the SysWOW64. Now your System will find the dll - but still not glpsol. Just copy the glpsol.exe in system32 for that, and voilà your done.
Adding the GLPK Directory to the Environment Path should also work.
I have a installshiled project which generates setup.exe file. I'd like to enable silent install by generating proper setup.iss file. I ran the following command:
Setup.exe /r
which lunched the installer, but it never created the setup.iss file. I looked in C:\Windows as the documentation suggested, as well as some other locations (local directory, program files etc.)
Why isn't it created and how to fix?
Thanks,
Ok I found the problem, and a workaround:
The problem was that my msi project was a Basic MSI Project, as opposed to InstallScript and InstallScript MSI projects. This kind of project does not support reading a response file (aka setup.iss). However, there is a way to perform silent installation for the .msi / setup.exe file:
Setup.exe /s /v"/qn"
will do the trick.
All of this information can be found here
Another option is to explicitly state where you want the setup file generated, using the /f1 option:
Setup.exe /r /f1"C:\your\path\here\setup.iss"
Documentation on this can be found here, but here is a summary from that link:
Using the /f1 option enables you to specify where the response file is (or where it should be created) and what its name is, as in Setup.exe /s /f1"C:\Temp\Setup.iss". Specify an absolute path; using a relative path gives unpredictable results. The /f1 option is available both when creating a response file (with the /r option) and when using a response file (with the /s option)
I'm trying to install the extension for Visual Studio 2012 that allows emacs key-bindings.
I'm following through the steps here:
Emacs Keybindings in Visual Studio 2012 or 2013
I'm up to step 5:
Run the vsik file as administrator. This is required so the extension
can write Emacs.vsk into the program files folder. I wasn't sure the
best way to do this so I ran a command prompt as admin and then
executed start emacsemulations.vsik from the prompt.
So, running emacsemulations.vsix from an administrator command prompt,
I get the following error "This VSIX package is invalid because it does not contain the file extension.vsixmanifest at the root."
I'm not changing any of the file names inside the package.
I'm thinking this may have something to do with how windows zips up the file -- I'm able to recreate the problem simply by unzipping and rezipping the EmacsEmulation.vsix file without changing the contents of the vsix package.
If anyone has any suggestions on how to fix, or even better, the actual updated vsix file itself, I'd be very grateful!
The issue you have relies on the way you are zipping your file, what you should do is zip all files inside the folder you created (in this case, "EmacsEmulations") when you unzipped it.
Step into the EmacsEmulations folder.
Select all files.
Add to .zip
Rename the .zip output to EmacsEmulations.vsix
I'm trying to get this extension to work too, so good luck!
I'm creating a windows installer with CPack and NSIS. During the install process the user should be asked if he wants to associate my program with a file extension. At least if you do "open with..." on a file with the extension windows should be told that you can open it with my program. Does anybody know how to do this?
Go to your nsis installation folder on you system and have a look at makensis.nsi from the examples directory. It associates .nsi to makensisw.exe.
Good luck ;)
To create file associations using NSIS I would recommend using NSIS plugins mentioned by Andrei T: File Association and FileAssoc. To integrate them into CPack you need to include the script, call macro during install step, call other macro during uninstall step.
For example this is how I use "File Association" plugin:
# Including
set(CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS
"!include \\\"${path_to_plugins}\\\\fileassoc.nsh\\\"")
# Create association
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS
"\\\${RegisterExtension} '$INSTDIR\\\\myprogram.exe' '.myext' 'my_program_key'")
# my_program_key can be any string that gives some hint what this file type is about. And should not contain strings
# Remove association
set(CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS
"\\\${UnRegisterExtension} '.myext' 'my_program_key'")
In this implementation it is not an optional step.
Please note the double escape. It is required because CPack creates intermediate file with those strings and if you escape only once there will be a syntax error.
Also note that all CMake paths should use back slashes. I convert them with:
get_filename_component(path_to_plugins"${path_to_plugins}" ABSOLUTE)
file(TO_NATIVE_PATH "${path_to_plugins}" path_to_plugins)
string(REPLACE "\\" "\\\\" path_to_plugins"${path_to_plugins}")