I've noticed that my installers no longer appear to be creating shortcuts - this is on Windows 10, 64-bit. Here's the log entry:
Output folder: C:\Users\xxx\Documents\Foo
Output folder: C:\Users\xxxx\AppData\Local\Bar\Foo\Cache
Output folder: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Bar
C:\Program Files\foo\bar\myApp.EXE
File Exists
Error creating shortcut: foo.lnk
Output folder: C:\Users\xxx\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch
Error creating shortcut: foo.lnk
Output folder: C:\Users\xxx\Desktop
Error creating shortcut: foo.lnk
Output folder: C:\Users\xxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\bar
Error creating shortcut: foo2.lnk
Output folder: C:\Users\xxx\Desktop
Error creating shortcut: foo2.lnk
That "File Exists" message validates that the executable I'm trying to create a shortcut to exists, yet I get a cryptic error. Running as Admin (although that shouldn't make a difference when I'm trying to write to my own desktop).
How can i determine what error is being triggered?
CreateShortcut broken? (Relative path to .LNK)
5 posts
Here's a sample NSI:
All shortcuts fail on Windows 10!
; General Compiler Flags
SetCompress auto
SetCompressor /SOLID /FINAL zlib
CRCCheck force
FileBufSize 4
XPStyle on
RequestExecutionLevel admin
ManifestSupportedOS Win10
ManifestDPIAware true
OutFile createShortcut.exe
; Display options
WindowIcon off
SetFont "Tahoma" 8
ShowInstDetails show
; 64-bit support
var IS64BIT
Section CreateShortcut CSCUT
MessageBox MB_OK "64bit = $IS64BIT"
StrCpy $0 "$PROGRAMFILES64\Internet Explorer\iexplore.EXE"
IfFileExists $0 0 +2
IntOp $1 0 + 1
MessageBox MB_OK "$0 exists = $1"
SetOutPath $DESKTOP
CreateShortcut test.lnk $0
CreateShortcut test2.lnk "$WINDIR\explorer.exe" "" "$WINDIR\explorer.exe" 0
CreateShortcut test3.lnk "$PROGRAMFILES32\nsis\nsis.chm" ""
CreateShortcut test4.lnk $EXEPATH
SectionEnd
Function .onInit
; Check for 64-bit Operating System
System::Call "kernel32::GetCurrentProcess() i .s"
System::Call "kernel32::IsWow64Process(i s, *i .r0)"
IntCmp $0 0 +2
IntOp $IS64BIT 1 & 1
; Enable registry fix
SectionGetFlags ${CSCUT} $0
IntOp $0 $0 | 1
SectionSetFlags ${CSCUT} $0
FunctionEnd
Your calls to CreateShortcut do not specify a full path!
Also, with "RequestExecutionLevel Admin" you really should use "SetShellVarContext All" to avoid writing to the wrong Start Menu folder.
The CreateShortcut code has not changed in a while.
Also, with "RequestExecutionLevel Admin" you really should use "SetShellVarContext All" to avoid writing to the wrong Start Menu folder.
The CreateShortcut code has not changed in a while.
That worked, but why should they specify a full path? Do they not assume $OUTDIR if one is not provided? My reading of the Documentation "$OUTDIR is used as the working directory" implies that, but I may have misunderstood.
Out of curiosity, is this Windows-specific? While you say the code hasn't change in a while, this is code of mine that hasn't changed in around a decade and worked on Windows 7.
Out of curiosity, is this Windows-specific? While you say the code hasn't change in a while, this is code of mine that hasn't changed in around a decade and worked on Windows 7.
$OUTDIR is the working directory of the thing invoked by the shortcut, it is a property inside the .LNK shortcut file. I will update the documentation to clarify this.
NSIS just uses the IShellLink interface in Windows to create shortcuts. I believe the implementation in Windows 8+ is stricter when it comes to the path of the .LNK (iPersistFile::Save https://msdn.microsoft.com/en-us/win...able-manifest#) if the application declares support for Windows 8 in its manifest.
One more thing I noticed, why are you using "ManifestSupportedOS Win10"? You should leave that property alone unless you understand what it does and actually want compatibility stuff applied on Windows 7, 8 and 8.1.
NSIS just uses the IShellLink interface in Windows to create shortcuts. I believe the implementation in Windows 8+ is stricter when it comes to the path of the .LNK (iPersistFile::Save https://msdn.microsoft.com/en-us/win...able-manifest#) if the application declares support for Windows 8 in its manifest.
One more thing I noticed, why are you using "ManifestSupportedOS Win10"? You should leave that property alone unless you understand what it does and actually want compatibility stuff applied on Windows 7, 8 and 8.1.