I have a ISAPI application written with Delphi. The application is compiled with runtime packages. Basically, all related bpls should deploy to an ISAPI enabled directory as well in order to get the ISAPI dll works. However, I always face errors when invoke ISAPI dll.
If my ISAPI dll doesn't compile with runtime packages, then it works fine.
The runtime packages should be the cause of the problems. The only solution so far I have is add the runtime packages path to system environment variable: %path% and restart the PC.
Is there any other solution available by not altering the environment variable?
I am using Windows 7 and IIS 7 and Delphi 2010.
For the case where the ISAPI DLL and the runtime bpl's are in the same directory, check the file permissions on your ISAPI DLL and the runtime .bpl files, and make sure that the Internet Guest account has read+execute access to them.
Have you tried placing .bpl files in directory where ISAPI dll is?
If this do not work then create installer for your ISAPI and this installer should copy all needed .bpl files to Windows system directory (you can get it using GetSystemDirectory() API function, usually this is <WindowsDir>\system32). For InnoSetup this is {sys} file destination.
The BPL files MUST be in the system path of the machine OR in the directory of the executable (which in this case I believe is svchost.exe?). Now, the fun part. As each application is launched it grabs a snapshot of the environment at that time. If you add to the path, you will have to reboot the machine for it to become active, OR restart the application (which in this case involves restarting the OS).
Related
I just wanted to know if there is or will be a standalone installer for fsi.exe to run on machines (Windows) that are not connected to the internet?
I have managed to get fsi working by downloading the nuget package, unzipping and then manually adding the "tools" folder to the PATH environment variable.
This seems to work because I can get into the repl, but I was wondering if there is a better way to do this.
This is a client server that we access over a tightly controlled VPN and it is not an option to do a full Visual Studio installation.
We have a D7 vcl app that uses dbexpress to connect to oracle (via the devart oracle driver for dbexpress). We converted this app to XE5. In D7 the dbxdrivers.ini and dbxconnections.ini files have been deployed in the same directory as the exe and the application read the them from this location without any intervention (i.e. dbexpress found automatically all the settings)
In XE5 deploying the dbxconnections.ini file doesn't work in the same way it worked in D7, in other words the application doesn't seem to use/find the two ini files when they are deployed in the same folder as the exe.
Based on my observations and reading the delphi code, I need to call the TSQLConnection.LoadParamsFromIni method and pass the dbxconnections.ini file name, otherwise the TSQLConnection object ends up reading the location from the registry: HKCU\Software\Embarcadero\BDS\12.0\DBExpress\Connection Registry File. dbexpress will read the dbxdrivers.ini from the exe directory, if it is there.
Any thoughts on this? Could you please confirm that this is how it's done?
Thanks
Update: After more testing here is the behavior that I am seeing:
If the HKEY_CURRENT_USER\Software\Embarcadero\BDS\12.0\DBExpress key is not present at all, and the dbx***.ini files are deployed only in the exe folder the XE5 app uses them without having to call LoadParamsFromIni.
If the HKEY_CURRENT_USER\Software\Embarcadero\BDS\12.0\DBExpress key is present with all the settings (Connection Registry File etc.) pointing to the ini files in the public folder, and the dbx***.ini files are deployed only in the exe folder, then the app doesn't read the ini files from the application folder and I need to explicitly call LoadParamsFromIni.
I think it is more reliable to call the LoadParamsFromIni than relying on the default behaviour of dbexpress.
I made an application with ADO Component and connect to Oracle with it, I don't have any problem when I run it in another machine.
But, when I use ODAC component and TOraSession and connect with it via Direct Connect and run it in another machine I faced to this error:
The Program Can't Start Because dbrtl70.bpl is missing from your Computer. Try to re installing the Program to fix it
As I investigate, dbrtl70.bpl is Delphi package file in System32 folder.
I want to know how can I solve this problem.
I'm going to take a wild guess and suggest that you have a 64 bit machine. You've copied the .bpl files into the 64 bit system folder (System32) where your 32 bit Delphi 7 program cannot see them. Put them in the 32 bit system folder (SysWOW64) instead and all should be well.
To learn more about the issue, read up on the File System Redirector.
If you don't want runtime packages, and all your dependencies support being built without using runtime packages, then simply uncheck the use runtime packages option.
My app was asking for a .bpl package when run on other machines.
Cancelling 'link with runtime packages' didn't solve it until I deleted the runtime packages listed in 'runtime packages'. Then it was OK.
Following MS' advice we have stripped most files from the DX installer contents for our D3D9 application, getting it down to 5Mb in total.
But now I;d like to package these files into a single installer, like the redistributable installers MS themselves provide... so it can be run as part of our application install process, with /silent switch, without manually having to unpackage the files and delete them.
Is there a simple, standard way to do this so that the packaged DXSetup.exe is run?
Or is all this too complex and we should just unpack the files, run DXSetup.exe and then delete the files after installation?
Its better to use the installers that MS provide, usually is what Apps do, if the problem is space you could always use web installer its 300kb but will require the user to have an internet connection.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en
On the other and if you're using DirectX SDK
there is a folder "redist"
and in it there are setup's of DX,
you can distribute them with your app,
and your Setup has to call the dxsetup.exe
I searched a lot, but all are guessed answers. Help me to find the exact answer.
An MSI is a Windows Installer database. Windows Installer (a service installed with Windows) uses this to install software on your system (i.e. copy files, set registry values, etc...).
A setup.exe may either be a bootstrapper or a non-msi installer. A non-msi installer will extract the installation resources from itself and manage their installation directly. A bootstrapper will contain an MSI instead of individual files. In this case, the setup.exe will call Windows Installer to install the MSI.
Some reasons you might want to use a setup.exe:
Windows Installer only allows one MSI to be installing at a time. This means that it is difficult to have an MSI install other MSIs (e.g. dependencies like the .NET framework or C++ runtime). Since a setup.exe is not an MSI, it can be used to install several MSIs in sequence.
You might want more precise control over how the installation is managed. An MSI has very specific rules about how it manages the installations, including installing, upgrading, and uninstalling. A setup.exe gives complete control over the software configuration process. This should only be done if you really need the extra control since it is a lot of work, and it can be tricky to get it right.
.msi files are windows installer files without the windows installer runtime, setup.exe can be any executable programm (probably one that installs stuff on your computer)
MSI is an installer file which installs your program on the executing system.
Setup.exe is an application (executable file) which has msi file(s) as its one of the resources.
Executing Setup.exe will in turn execute msi (the installer) which writes your application to the system.
Edit (as suggested in comment): Setup executable files don't necessarily have an MSI resource internally
MSI is basically an installer from Microsoft that is built into windows. It associates components with features and contains installation control information. It is not necessary that this file contains actual user required files i.e the application programs which user expects. MSI can contain another setup.exe inside it which the MSI wraps, which actually contains the user required files.
Hope this clears you doubt.