Using Firebird 2, we had to deploy 3 files with our applications to be able to connect to remote firebird servers:
fbclient.dll
msvcr80.dll
Microsoft.VC80.CRT.manifest
The first file was retrieved from the "normal" Firebird installer, the other 2 files from the "embedded" installer.
Firebird 4 doesn't provide an embedded installer, and I don't find proper information what to deploy for clients.
Reading this: https://ib-aid.com/download/docs/fb4migrationguide.html#_installing_client looks like Firebird 3 has lower demands. Is that the case? I just need communication-encryption and longer passwords, so FB3 would also be fine. (BTW, following the guide didn't bring success, otherwise I would not ask).
The minimum necessary files are listed in the document you link:
If we speak about installing Firebird client only, you need to have
fbclient.dll file. Firebird 4.0 client requires Microsoft Runtime C++
2017 with the same bitness as fbclient.dll. If Microsoft Runtime is
not installed, you may just copy it’s two files, msvcp140.dll and
vcruntime140.dll that are included in ZIP for Windows.
So the absolute minimum you need is fbclient.dll, and in some cases you may also need msvcp140.dll and vcruntime140.dll when those are not already installed on your system.
In addition, it is advisable to include firebird.msg for error messages, and for some use cases, adding the ICU files is advisable (if you use the functions of fbclient to render/parse WITH TIME ZONE types).
If you want wire compression, you'll also need zlib1.dll, and if you want to use Chacha wire encryption instead of the less secure ARC4, then you also need plugins/chacha.dll (the chacha.dll needs to be in a plugins folder relative to fbclient.dll).
All these libraries must be the same bitness as your application. As discussed in the comments, the problem seems to have been that you tried the 64-bit DLLs from a 64-bit Firebird installation, while your application was 32-bit.
If your application is 32-bit, then obtain the files from a 32-bit installation or zip kit, or look in the WOW64(*) folder of a 64-bit installation (from the installer, the 64-bit zip kit doesn't contain this directory). This WOW64 folder contains the 32-bit files fbclient.dll, msvcp140.dll and vcruntime140.dll (for the additional DLLs you need to use a 32-bit installer or zip kit).
* This follows the awkward Windows naming of 64-bit Windows having 64-bit files in %WINDIR%\System32, and 32-bit files in %WINDIR%\SysWOW64
Related
I'm working to install the Crystal Reports Runtime (SP31) on a Windows Server 2016 machine, and I just wanted to know - is there anything special I need to know about the installation process? Any special steps that are needed that are different from installing on a local user machine? Any known issues?
Just remember that the choice of 32-bit vs 64-bit is NOT based on the platform. Even if the machine is 64-bit, you should still install the 32-bit version if your app was compiled for 32-bit.
Similarly, data connectivity (e.g. ODBC) should be 32-bit if the app was compiled for 32-bit.
Also, be aware that if the machine has another application that uses the Crystal runtime, but from another service pack, you might run into conflicts.
I have created an application in C# that relies on a specific driver (a custom virtual hid driver based on VMulti).
Currently, I have everything working and I want to combine both the application and driver into one installation package. As of right now, my application part has a .exe file and a .dll file. My driver has an .inf and .sys file, hidkmdf.sys, and WdfCoInstaller01009.dll (this dll is from the WDK). I am not able to install the driver through the traditional method of right-clicking the inf and clicking install. Instead, I use devcon to install it (command is "install inffile.inf hardwareid")
I tried using InstallShield LE, but I am only able to install the application, not the driver. After doing some searching, I found people using DIFxAPP to create the installation framework for drivers, however, I am not sure if this can be integrated into InstallShield so that the driver is installed during the application installation process.
So my main question is: What is the best and simplest method for combining application and driver installation into one package (meaning the setup.exe will install both the driver and the application)?
I am very new to driver development and application deployment, so any suggestions are welcome.
Thank You
EDIT: It is preferred that the solution does not require any paid tools.
Acctually, exists a many ways to implement this which depends on your Windows Installers skills.
You didn't specify target OSes for your application, that's why can I give you some ways:
PnpUtil.exe internal Windows 7 utility (only for Windows 7)
DPInst.exe included to WDK
DifXAPI merge module.
You can install drivers with help of all these utils via Custom Actions.
NOTE: That your driver SHOULD BE signed, otherwise you will receive error during silent installation.
I want to deploy a client application that uses Oracle's ODP.net but I don't want to install ODP.net on every machine. Rather I'd like to copy the managed dll oracle.dataaccess.dll on every machine and have the native dlls on which it depends available, on a shared disk.
By decompiling the oracle.dataaccess.dll code I have seen that it calls a method that gets the location of the native dlls from the registry. So, in addition to copying the oracle.dataaccess.dll on every machine I would have to add the registry keys that would point to the native dlls on the shared disk.
My question: does one foresee any problem arising from that technique of odp.net deployment?
The only files you need from the latest client are:
Oracle.DataAccess.dll
oci.dll
oraociicus11.dll
OraOps11w.dll
Just make sure they get copied to the output directory and everything will work. Nothing needs to be registered anywhere. You will however need to make separate x86 and x64 builds with the respective architecture's DLLs since an Any CPU .NET application will run in 32-bit mode on a 32-bit OS and in 64-bit mode on a 64-bit OS.
1) ODP.NET is currently a mixture of managed and unmanaged DLL's. It also relies on lower level unmanaged DLLs from the Oracle client - eg for networking, etc.
2) You will need all these required ODP.NET and client DLLs on each machine you deploy to.
3) One potential solution to make this easier on you is to look into the "XCOPY" deployment package. See the ODP.NET download page. This is a smaller install and allows you to write your own custom installer. You can include these XCOPY files as part of your own install.
4) Oracle will be doing a beta of a fully managed provider in 2012 which will make this situation much better (and the total size will be a couple megabytes only).
Christian Shay
Oracle
Since they're unmanaged I'd assume that they'd be ok on a network path, though that should be easy enough to test. However I'd suggest that rather than changing the registry setting, you might be better off changing the DllPath config setting as described here.
I'm trying to access the TargetPlatform property value (which you can set in a Deployment project) from the condition within a "Launch Condition".
Basically I'm trying to tell the application not to install itself as a 32bit app if a 64bit version of Office is installed on that computer. Therefore I need to somehow get the application's bitness and put it in a launch condition.
I can get the bitness of Office from the registry, but I don't know how to access the TargetPlatform from the installer.
Thanks!
Here are two link:
Deploy1
Deploy2
From the above link you can deduce that you can't target both platforms from a MSI installer. You will need to have two installers. Depending on how the installer is built, x86 or x64, will depend the way the installer interprets some constants that tell where to isntall the files - Program Files, or Program Files (x86).
You can't change the TargetPlatform of the installer at runtime.
What you can do maybe is to have two installers packed into a third one and based on the Office version installed that you say you can obtain run either sub-installer x86 or sub-installer x64, that will actually install the application files.
If MSI installer is not the outmost requirement I would go for NSIS. If not at least package the to MSI installers into an NSIS one. It is incredibly easy. NSIS is way cooler than MSI, talking from experience.
I've read this question a few times now and I'm not 100% certain I understand what you are trying to do. Do you have a 32bit application and you only want to install if they have 32bit Office (2010 I assume) installed? Do you also have a 64bit version that you want to install if 64bit office is installed?
I'm not sure why you need to care about the TargetPlatform property because if you know that 64bit Office is installed you must by definition be a 64bit OS. If 32bit Office is installed you could possibly be a 64bit OS but does it really matter? You said you cared about the bitness of Office not Windows.
I would think, from what I've read, that if you have an AppSearch that pulls the bitness into a property that you could just use a LaunchCondition that uses that property along with "or Installed" ( to handle being able to uninstall your application if Office was uninstalled first ) and be just fine.
Add a custom action before the installation starts to perform the check. Use an Installer class to perform the custom action. You could use the OnBeforeInstall event to read the registry key and check the bitness as appropriate. Throwing an exception will cause the installation to abort, but there may be a cleaner way to do this.
I am having Oracle 10g installed on my laptop and have downloaded ojdbc14.jar driver for the same. The problem is, my operating system is Windows 7, and I'm not having option to create a Data Source for Oracle since I m not having oracles driver installed. I m having option to create a Data Source for SQL server 6, but I want to get connected to Oracle. Please Help.
By 'Data Sources', I'm guessing that you mean Data Sources (ODBC), under Control Panel > Administrative Tools. Is this correct?
I've set up ODBC Data Sources that connect to Oracle databases before, but to do that I've needed the Oracle client to be installed. However, if you're having the full database installed on your laptop (as your question suggests), you won't need the client - that's only used to connect to databases running on other machines. I believe the full database contains everything in the client, so you should be able to set up an ODBC Data Source pointing to the database on your laptop once the database has been installed.
The ojdbc14.jar just contains the JDBC classes to talk to an Oracle database, and only programs written in Java (and other languages that run on the JVM such as Scala, Groovy or Clojure) can use it. This jar on its own not enough to be able to set up an ODBC data source.
Oracle currently has 1 version that is certified for windows 7. That version is 11.2. They have indicated that they plan to certify 10.2.0.5 if this happens there will likely be a patch that will be needed.
This is probably why the Data Source does not work, either ODBC or OLEDB.
Another possibility is that you have installed the 32bit version of Oracle and your OS is 64bit then you would need to use the 32bit Data Source administrative tools.
I have figured out the solution for my problem. All that I needed to do is put ojdbc14.jar file in my class path and then I was able to use it. Though by doing so, I needed to make some change in the code. I was no more able to use Class.forName("sun.jdbc.odbc.JdbcOdbcDriver") instead I needed to use Class.forName("oracle.jdbc.OracleDriver") also instead of using my data source as "jdbc:odbc:somename" I needed to use jdbc:oracle:thin:#localhost:1521:xe.