I'm hoping someone can help me translate the following into a correctly formatted InnoSetup [Registry] entry to use in my InnoSetup Installer? The goal here is to create a new custom URL protocol on the user's machine.
HKEY_CLASSES_ROOT
ctp
(Default) = "URL:Alert Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "myapp.exe"
shell
open
command
(Default) = "C:\Program Files\MyApp\myapp.exe"
I read through the InnoSetup Help doc but couldn't figure out how to translate the above into a proper InnoSetup Registry section:
[Registry]
Root: HKCR; Subkey: ".....etc.
The final result after the installer runs is that the user clicks on a link on a web site formatted as "ctp://myapp.exe" and that local app will launch on the user's machine. Am I approaching this correctly?
Thanks very much for any responses.
Try it this way:
[Registry]
Root: HKCR; Subkey: "ctp"; ValueType: "string"; ValueData: "URL:Custom Protocol"; Flags: uninsdeletekey
Root: HKCR; Subkey: "ctp"; ValueType: "string"; ValueName: "URL Protocol"; ValueData: ""
Root: HKCR; Subkey: "ctp\DefaultIcon"; ValueType: "string"; ValueData: "{app}\YourApp.exe,0"
Root: HKCR; Subkey: "ctp\shell\open\command"; ValueType: "string"; ValueData: """{app}\YourApp.exe"" ""%1"""
#TLama's answer is correct, but might not work for everybody.
HKCU is actually a merge between HKLM\Software\Classes and HKCU\Software\Classes and writting to HKCU directly may require administrative access on some systems, thus it's not compatible with InnoSetup's PrivilegesRequired=lowest. The official HKCU documentation explains:
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINE\Software\Classes. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USER\Software\Classes, the system will store
the information there instead of under
HKEY_LOCAL_MACHINE\Software\Classes.
The alternative is HKA (see [Registry] section) which resolves to HKLM in administrative installs and HKCU in non-administrative ones. The documentation also states that:
HKCU and HKA should only be used for settings which are compatible
with roaming profiles.
Using HKCR is not recommended, use HKA with the Subkey parameter set
to "Software\Classes" instead.
So, if you care about non-administrative installs, your [Registry] section should look like this:
[Registry]
Root: HKA; Subkey: "Software\Classes\ctp"; ValueType: "string"; ValueData: "URL:Custom Protocol"; Flags: uninsdeletekey
Root: HKA; Subkey: "Software\Classes\ctp"; ValueType: "string"; ValueName: "URL Protocol"; ValueData: ""
Root: HKA; Subkey: "Software\Classes\ctp\DefaultIcon"; ValueType: "string"; ValueData: "{app}\myapp.exe,0"
Root: HKA; Subkey: "Software\Classes\ctp\shell\open\command"; ValueType: "string"; ValueData: """{app}\myapp.exe"" ""%1"""
For more info see the links above, and also the following ones:
InnoSetup - Creating File Associations
InnoSetup - Non Administrative Install Mode
Microsoft - Registering an Application to a URI Scheme
Related
I was able to create Azure key value successfully but I am unable import the PFX file successfully. Here is the command I used:
$securepfxpwd = ConvertTo-SecureString –String '123' –AsPlainText –Force
$key1 = Add-AzureKeyVaultKey -VaultName 'MyKeyVault' -Name 'MyKey' -KeyFilePath 'C:\mycert.io.pfx' -KeyFilePassword $securepfxpwd
Here is the error I am getting:
Add-AzureKeyVaultKey : **Operation "import" is not allowed**
At line:1 char:9
+ $key1 = Add-AzureKeyVaultKey -VaultName 'MyKeyVault' -Name 'MyKey ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Add-AzureKeyVaultKey], KeyVaultClientException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.KeyVault.AddAzureKeyVaultKey*
When I used command: Get-AzureRmKeyVault, I got following information for access keys:
*SKU : Standard
Enabled For Deployment? : False
Enabled For Template Deployment? : False
Enabled For Disk Encryption? : False
**Access Policies :**
Tags :*
Here are my questions:
Should I be giving myself permissions to import using Set-AzureRmKeyVaultAccessPolicy?
If so, what would be the parameters for this command to give myself permissions to import the cert?
Just had this issue today.
https://blogs.technet.microsoft.com/kv/2016/09/26/get-started-with-azure-key-vault-certificates/
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName -UserPrincipalName $upn -PermissionsToCertificates all
Valid values are get, list, delete, create, import, update, managecontacts, getissuers, listissuers, setissuers, deleteissuers, all
https://learn.microsoft.com/en-us/powershell/resourcemanager/azurerm.keyvault/v2.5.0/set-azurermkeyvaultaccesspolicy
How do I set a global environment variable in Inno Setup?
Background: I am using the Inno install utility and need to set a global environment variable before I do the actual install.
Try this:
[Registry]
Root: HKCU; Subkey: "Environment"; ValueType:string; ValueName: "VARIABLE_NAME"; \
ValueData: "new_value"; Flags: preservestringtype
You might need to add this:
[Setup]
; Tell Windows Explorer to reload the environment
ChangesEnvironment=yes
Alternatively try:
[Run]
Filename: "{app}\MyProg.exe"; BeforeInstall: SetEnvPath
[Code]
#ifdef UNICODE
#define AW "W"
#else
#define AW "A"
#endif
function SetEnvironmentVariable(lpName: string; lpValue: string): BOOL;
external 'SetEnvironmentVariable{#AW}#kernel32.dll stdcall';
procedure SetEnvPath;
begin
if not SetEnvironmentVariable('VARIABLE_NAME', 'new_value') then
MsgBox(SysErrorMessage(DLLGetLastError), mbError, MB_OK);
end;
Reference: Inno Setup Frequently Asked Questions - Setting Environment Variables
If the variable change is not propagated (see Environment variable not recognized [not available] for [Run] programs in Inno Setup)
[Run]
...; AfterInstall: RefreshEnvironment
[Code]
const
SMTO_ABORTIFHUNG = 2;
WM_WININICHANGE = $001A;
WM_SETTINGCHANGE = WM_WININICHANGE;
type
WPARAM = UINT_PTR;
LPARAM = INT_PTR;
LRESULT = INT_PTR;
function SendTextMessageTimeout(hWnd: HWND; Msg: UINT;
wParam: WPARAM; lParam: PAnsiChar; fuFlags: UINT;
uTimeout: UINT; out lpdwResult: DWORD): LRESULT;
external 'SendMessageTimeoutA#user32.dll stdcall';
procedure RefreshEnvironment;
var
S: AnsiString;
MsgResult: DWORD;
begin
S := 'Environment';
SendTextMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0,
PAnsiChar(S), SMTO_ABORTIFHUNG, 5000, MsgResult);
end;
More details:
Inno Setup: Setting a System Environment Variable
Under more modern (in other words, proper) operating systems, such as
Windows 2000, XP, and Windows 2003 Server, environment variables are
stored in the Registry under the following key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\
Environment
Variables are added by creating a new value under this key or by
modifying a value if it already exists. To delete a variable, you
simply delete its Registry value, unless you are removing part of an
expanded value, such as PATH, in which case you only remove the part
you want.
At this point, Windows will not be aware of your changes unless you
log off or reboot. To get around this, SetEnv will broadcast a
WM_SETTINGCHANGE to all of the windows in the system. This allows
other running applications—for example, Explorer.exe—to be notified of
your change. If you run SetEnv from a command prompt, this will not
update the environment variable for the current DOS window. This is
mainly due to the fact that a process (SetEnv) cannot change the
environment of its parent (The Command Prompt). However, any new
DOS/Command Prompts that you open will show the new variable/value.
The solutions in #Adrian's answer (actually copied from #TLama's answer to similar question) are correct for many situations.
But it won't work for [Run] tasks with runasoriginaluser flag (what is implied by postinstall flag). I.e. the variable won't be propagated to an application run with common "Run My Program" check box on the "Finished" page.
The reason is that the tasks with runasoriginaluser are executed by a un-elevated hidden parent process of the Inno Setup installer. The SetEnvironmentVariable will change environment for the installer, but not for its parent process. Unfortunately, the parent process of the installer cannot be controlled (imo).
As a workaround, to set the variable for the runasoriginaluser tasks, you have to inject an intermediate process between the installer parent process and the task, and have the intermediate process set the variable.
Such an intermediate process can easily be the cmd.exe with its set command:
[Run]
Filename: "{cmd}"; Parameters: "/C set MYVAR=MyValue & ""{app}\MyProg.exe"""; \
Description: "Run My Program"; Flags: postinstall runhidden
The runhidden flag hides the cmd.exe console window, not the application (assuming it's a GUI application). If it's a console application, use start to start it in its own (visible) console window.
What would be wrong with running two setup.exe with the first one doing the setting of the environment variables, and the second doing the things needed for the true setup. The first one would be run with setup.exe /VERYSILENT
I am doing to add an system wide environment variable:
[Setup]
; Tell Windows Explorer to reload the environment
ChangesEnvironment=True
[Registry]
Root: "HKLM"; Subkey: "SYSTEM\CurrentControlSet\Control\Session Manager\Environment"; ValueType: string; ValueName: "EGPL_GeoLibrarian_Drive"; ValueData: "L"; Flags: createvalueifdoesntexist preservestringtype
Delphi 2010
Windows 7 - 64 bit.
I have an app which is reasonably trivial. It is a database app. It starts, finds it's current directory, looks for a database file IN THAT DIRECTORY, opens it, and displays some data. It works fine on my dev computer. I take it to another computer, also Windows 7, 64 bit, and I get an error. (Specifically from the database library - Component Ace - saying that a column doesn't exist). I have to believe this is a generic access error. When I right click on the desktop icon, and choose RUN AS ADMINISTRATOR, it runs fine. I have not explicitly locked anything down. I am on the computer as the Admin user. It is Admin that has installed the app. I am trying to distribute this app to multiple people. The install routine I am using is InnoSetup. What type of permission problem as I running into?
For completeness sake, I am including the INNO SETUP.iss file.
Thanks
GS
; Script generated by the Inno Setup Script Wizard.
; SEE THE DOCUMENTATION FOR DETAILS ON CREATING INNO SETUP SCRIPT FILES!
#define MyAppName "DocAssist"
#define MyAppVerName "DocAssist 3.2"
#define MyAppPublisher "GS"
#define MyAppExeName "DocAssist.exe"
[Setup]
; NOTE: The value of AppId uniquely identifies this application.
; Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{6F34D198-14A0-4398-8E82-34232956CC5B}
AppName={#MyAppName}
AppVerName={#MyAppVerName}
AppPublisher={#MyAppPublisher}
DefaultDirName={pf}\{#MyAppName}
DefaultGroupName={#MyAppName}
AllowNoIcons=yes
OutputDir=D:\Projects\DocAssist\DISTR
OutputBaseFilename=DocAssistV3Setup
Compression=lzma
SolidCompression=yes
AppCopyright=GS
VersionInfoVersion=3.2
[Languages]
Name: english; MessagesFile: compiler:Default.isl
[Tasks]
; Name: desktopicon; Description: {cm:CreateDesktopIcon}; GroupDescription: {cm:AdditionalIcons}; Flags: unchecked
Name: desktopicon; Description: {cm:CreateDesktopIcon}; GroupDescription: {cm:AdditionalIcons};
[Files]
Source: D:\Projects\DocAssist\DISTR\DocAssist.exe; DestDir: {app}; Flags: ignoreversion
Source: D:\Projects\DocAssist\DISTR\DocAssist.ABS; DestDir: {app}; Flags: ignoreversion
Source: D:\Projects\DocAssist\DISTR\StopWords.txt; DestDir: {app}; Flags: ignoreversion
; NOTE: Don't use "Flags: ignoreversion" on any shared system files
Source: DocAssist Version 3_2.pdf; DestDir: {app}; Flags: isreadme
; Add-in dll
Source: D:\Projects\DocAssist\DISTR\DocAssistCom.dll; DestDir: {app}; Flags: regserver
Source: D:\Projects\DocAssist\DISTR\gdiplus.dll; DestDir: {app}; Flags: ignoreversion
[Icons]
Name: {group}\{#MyAppName}; Filename: {app}\{#MyAppExeName}
Name: {group}\{cm:UninstallProgram,{#MyAppName}}; Filename: {uninstallexe}
Name: {commondesktop}\{#MyAppName}; Filename: {app}\{#MyAppExeName}; Tasks: desktopicon
[Run]
Filename: {app}\{#MyAppExeName}; Description: {cm:LaunchProgram,{#MyAppName}}; Flags: nowait postinstall skipifsilent
[Registry]
Root: HKLM; Subkey: SOFTWARE\DocAssist; ValueType: none; Permissions: admins-full; Flags: uninsdeletekey createvalueifdoesntexist;
Root: HKLM; Subkey: SOFTWARE\DocAssist; ValueType: string; ValueName: InstallDir; ValueData: {app}; Permissions: admins-full; Flags: uninsdeletekey createvalueifdoesntexist
You should not write to files in your program files directory. This has been deprecated since Windows 95, but starting with Windows Vista it has become more strict and writing there is not allowed by default, unless you are an administrator.
There are many other places you can write to, and App Data is a commonly used folder, as is My Documents. You can use the SHGetSpecialFolderLocation api to find the exact location of these special folders (because it ma differ per installation).
B.t.w. if you have to use the application directory, resort to Application.ExeName or ParamStr(0) rather than on the current directory.
I read and re-read the docs and tutorials, but my understanding of how to create Erlang Applications, and Rebar for that matter, still has enough holes to resemble Swiss cheese. Very simple stuff throws me.
I'm working toward an Erlang Release that will eventually include several applications of my own plus Webmachine and maybe a nosql db of one flavor or another. Using Rebar I've successfully compiled and tested my applications: ZZZ and ZZZ_Lib. my directory structure is shown below. I'm not confident that it's optimal, but it works.
I've installed Webmachine under the ...learn1/apps directory.
My next step has been to integrate Webmachine with the very simple webmachine_demo_resource shown below under the name test_resource:erl.
http://webmachine.basho.com/example_resources.html
But when I try to compile, I get this error message:
src/test_resource.erl:3: can't find include lib "webmachine/include/webmachine.hrl"
Here's the offending line in test_resource.erl:
-include_lib("webmachine/include/webmachine.hrl").
I've tried to set both ERL_LIBS (which I don't fully understand) and PATH with no success. So, clearly, I don't understand how to set the proper path or how best to integrate Webmachine.
Any and all guidance would be gratefully welcomed.
LRP
* Directory structure
learn1$ ls
apps rebar rebar.config
learn1/apps$ ls
webmachine zzz zzz_lib
learn1/apps/zzz_lib/src$ ls
yada yada test_resource.erl yada yada
* rebar.config
{sub_dirs,
["apps/zzz",
"apps/zzz/src",
"apps/zzz_lib",
"apps/zzz_lib/src"
]
}.
* zzz_lib.app.src
{application, zzz_lib,
[
{description, ""},
{vsn, "1"},
{modules, [
yada yada
]},
{applications, [
kernel,
stdlib,
webmachine
]},
{mod, { zzz_lib_app, []}},
{env, []}
]}.
You most likely will end up happier including it as a dependency, not as a contained app. See for example how Riak Core does it: https://github.com/basho/riak_core/blob/master/rebar.config
For more insight, you might find asking the mailing lists to be worthwhile:
http://lists.therestfulway.com/mailman/listinfo/webmachine_lists.therestfulway.com
http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com
Using ERL_LIBS in your case, you'd need to set it to /.../learn1/apps.
When compiling, you may also add a {i, Dir} option.
According to the documentation however, it only mentions -include and -include_dir, not -include_lib.
{i,Dir} Add Dir to the list of directories to be searched when
including a file. When encountering an -include or -include_dir
directive, the compiler searches for header files in the following
directories:
".", the current working directory of the file server;
the base name of the compiled file;
the directories specified using the i option. The directory specified
last is searched first.
I'm trying to understand ISAPI as run under Apache 2.x. I've created a simple DLL using Delphi XE to test with based on a tutorial I found.
I've added these lines to my Apache httpd.conf file.
ScriptAlias /Delphi/ "C:/Delphi/bin/"
<Directory "C:/Delphi/bin/">
AddHandler isapi-handler .dll
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
The isapi_module is loaded.
I've placed the DLL in C:\Delphi\bin.
When I call it with the following URL (case is correct);
http://127.0.0.1/Delphi/ISAPI_Test1.dll
I get a 403 error and the Apache Error Log has this line.
... [error] [client 127.0.0.1] attempt to invoke directory as script: C:/Delphi/bin/
I expect the dll to simply use the default handler:
procedure TWebModule1.WebModule1DefaultHandlerAction(Sender: TObject;
Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
begin
Response.SendRedirect (Request.Referer);
end;
Question 1: What is my specific issue here?
Question 2: Can anybody point me to a step by step tutorial or book for getting a basic skelton working? I've got too many holes in my understanding at this point.
Thank you.
For this subject, look at serverfault.com, for example, this question: apache attempt to invoke directory as script