ODP.NET deployment without installation - deployment

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.

Related

What to deploy for Firebird 4 clients?

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

Deploy files on a network share from a client machine using an installation package?

We have a large application that has been developed over 15 years and in installed in 200+ client locations. The application currently consists of an Access database and a bunch of executable and report files located on a network share. A Setup.EXE file is run on each client machine (dlls are installed on the client) and then the client machines run the executables directly from the network share. During our upgrade procedure the new executable and report files are copied to the network share and that way each client gets the update immediately.
Our current installation program is very old and, among other things, it doesn't handle x64 so we are in the process of moving to a new deployment tool. At the same time we are migrating client Access databases to SQL Server. I am having difficulty finding a deployment tool to do what we require. Specifically we need the install/upgrade file to do the following:
It must be able to be run from a client machine on a network and copy the new executable and report files to the network share. That share could be a Linux box or a dumb storage device.
Accept a password before running the installation
Allow the user to select the network share as the location to copy the executables
It must NOT add anything to the client machine from where the package is run (Add/Remove Programs, registry, etc.)
Connect to a SQL Server database and run a script
The install/upgrade must be contained in a single, standalone .msi or .exe file. (no dependencies on dlls or frameworks other than those that come with Windows XP)
The file must be able to be run in one simple step. It is the end user that runs the upgrade without our support and without involvement from IT.
It looks like the closest thing to what I need is WiX but the problem there is that whenever the .msi file is run from a client, the client machine thinks that a program is being installed so it allows the client machine to uninstall the product, which is not acceptable.
If the product were written today it would certainly be architected differently but it currently is what it is and we can’t change that. Any help here would be greatly appreciated!
WiX is just a toolset built on top of Windows Installer technology. It makes many things easier and simpler as well as hides lots of Windows Installer weird features... But, it is still limited by Windows Installer, its underlying technology.
Your list of requirements made me think that Windows Installer is not the right technology to choose. I would assume that you'll spend more time on workarounds, than on functional code... But I have no experience with other installation technologies, so I'll leave those recommendations to others.

how do you build your appliances?

virtual machines hold great promise as a way to distribute hard to configure applications. i have been using jeos vmbuilder (and some bash scripts) to generate my appliances, but i'm looking for something more elegant.
in my case, i'm looking for a solution that will build a linux-based vm with configured versions of tomcat and mysql as a base. each future release would be a new war file and a sql update script. it'd be really nice if already deployed vms could self-update and test builds could be pushed to ec2.
in my brief search, i've found rpath rbuilder, turnkey linux,
vagrant up, suse studio, jeos vmbuilder, and vmware studio. rather than try all of these, i figure i'd ask what this community uses to build and distribute appliances...
I use pungi myself.

Are there any USB stick runnable, no-install, cross platform software frameworks (with GUI)?

Does anyone know of a good software development framework or similar that has the following properties?
Cross platform: it should be runnable on XP, Vista, OSX and common versions of Linux (such as Ubuntu and Kubuntu).
No installation: Be able to run the software from a USB stick without having to copy anything to the host machine.
Have good GUI support (this is why this question doesn't give a suitable answer, as far as I can tell).
Permissive licensing such as LGPL or BSD or such.
Among the softer requirements are having a set of abstractions for the most common backend functionality, such as sockets, file IO, and so on (There is usually some platform specific adaptations necessary), and supporting a good language such as Python or C++, though it is usually fun to learn a new one (i.e. not perl).
I think possible candidates are Qt 4.5 or above (but IFAIK Qt software will not run on Vista without any installation(?)), some wxWidgets or maybe wxPython solution, perhaps gtkmm. The examples I have found have failed on one or another of the requirements. This does not mean that no such examples exist, it just means that I have not found any. So I was wondering if anyone out there know of any existing solutions to this?
Some clarifications;
By "framework" I mean something like Qt or gtkmm or python with a widget package.
This is about being able to run the finished product on multiple platforms, from a stick, without installation, it is not about having a portable development environment.
It is not a boot stick.
It is ok to have to build the software specifically for the different targets, if necessary.
The use case I am seeing is that you have some software that you rely on (such as project planning, administration of information, analysis tools or similar) that:
does not rely on having an internet connection being available.
is run on different host machines where it is not really ok to install anything.
is moved by a user via a physical medium (such as a USB stick).
is run on different operating systems, such as Windows, Vista, Ubuntu, OSX.
works on the same data on these different hosts (the data can be stored on the host or on the stick).
is not really restricted in how big the bundled framework is (unless it is several gigabytes, which is not really realistic).
It is also ok to have parallel installations on the stick as long as the software behaves the same and can work on the same data when run on the different targets.
A different view on the use case would be that I have five newly installed machines with Vista, XP, OSX, Ubuntu and Kubuntu respectively in front of me. I would like to, without having to install anything new on the machines, be able to run the same software from a single USB stick (meeting the above GUI requirements and so on) on each of these five machines (though, if necessary from different bundles on the stick).
Is this possible?
Edit:
I have experimented a little with a Qt app that uses some widgets and a sqlite database. It was easy to get it to work on an ubuntu dist and on osx. For windows xp and vista I had to copy QtCored4.dll, QtGuid4.dll, QtSqld4.dll and mingwm10.dll to distribution directory (this was debug code) and I copied the qsqlited4.dll to a folder named "sqldrivers" in the distribution directory.
You mention wxWidgets but dismiss it as failing at least one of the requirements.
I don't know what your requirements are and in what way wxWidgets wouldn't work for you, but IMO it does fulfill them:
Cross platform: it should be runnable on XP, Vista, OSX and common versions of Linux.
It does run on those platforms, but "common versions of Linux" isn't good enough, as you can never be sure that the necessary GUI libraries for wxGTK (which should not be linked to statically) will be installed. This is however a problem for other solutions as well, unless you plan to put everything onto the stick.
No installation: Be able to run the software from a USB stick without having to copy anything to the host machine.
See the previous point, you would need to specify which libraries are needed on Linux. Also you could specify at build time not to use some of the system-provided libraries (for example for graphics, compression, regexes) but to use the wxWidgets-internal libraries instead.
Have good GUI support
Check.
Permissive licensing such as LGPL or BSD or such.
Check. You can statically link wxWidgets into your application too.
supporting a good language such as Python or C++
Supports both, and there are bindings to other languages as well.
having a set of abstractions for the most common backend functionality, such as sockets, file IO, and so on
It does have some abstractions like that, but you can link to other cross-platform libraries as well.
We use wxWidgets for FlameRobin, a graphical administration program for the Firebird SQL server. It has active ports to Windows, Linux and Mac OS X, and has been compiled for at least some BSD variant and Solaris as well. It definitely runs from a stick on Windows, I haven't tried with Linux or Mac OS X, but I don't see why it shouldn't there too.
Java.
It has GUI support.
It provides your network/file/etc. abstractions.
It is cross-platform. Most platforms you can think of have a JRE available.
No need to install a JRE. Most users probably already have one, and if not, you can run the appropriate JRE right off the stick.
You can provide several startup scripts for various platforms to run the app under the appropriate JRE.
Something else to consider is HTML+Javascript. :D
You can look at Mono it cross platform, has GUI (GTK+, or Winforms 2.0) and I can execute code without installing.
This might not be crossplatform, but is maybe even better, it dont even use the platform : linux on a stick :-)
The subtitle is
Take your Java workspaces wherever you go on a USB key
Here with java and eclipse, but nothing stops you there of course.
http://knol.google.com/k/inderjeet-singh/installing-a-ubuntu-hardy-heron-java/1j9pj7d01g86i/2#
Well, it depends on what you mean by 'package'. Kylix came close to being such a thing. It was QT based, and it allowed you to write once and compile for Windows + Linux. However, it was not an open source solution.
I asked a similar question in this link
http://www.24hsoftware.com/DevelopersForum/CrossPlatform-C-Library.html
and the best asnswer seems to be QT.
I have started using QT, but it is not as easy as I expected mainly due to deployment problems due to the DLL hell, Winsxs hell and manifest hell.
Tclkit is a single-file, self-contained Tcl/Tk system. The mac version I have is about 3.8 megs. You can get a version for just about any modern OS. I carry around a thumb drive that has mac, windows and linux binaries so I can run my scripts on any platform. No install is required, just copy one file wherever you want.
The most recent versions of tcklit use native, themed widgets (though, on *nix there really isn't a single "native" set of widgets...)

Creating installers for complex cross-platform programs

I'm sketching an application deployment process for a bunch of relatively complex desktop applications. We have both native and Java apps, so the deployment must be able to check for existence of the JRE and install it if needed. Some of the apps depend on special hardware, so the deployment must also be able to launch the necessary driver installers. Some of the apps are multiplatform, and preferably the same mechanism should be able to create Windows, Linux and Mac OS X installers. That is:
The installer must be able to install, in addition to the application itself:
Java Runtime Environment.
Drivers (hardware) - that is, launch other installers.
The installer builder must be operable from the command line so that it can be integrated with an automatic build mechanism that generates installer packages for each platform as nightly builds.
In addition, I need to create "update from the web" mechanisms for the applications. It could be included in the installer, or it could also be a separate custom mechanism built into the application.
Now, this is getting a bit complex, and I suspect that there might be no single installer that could do this all. Therefore I'm thinking between two fundamentally different approaches:
Platform-specific mechanisms: NSIS would create .exe or .msi for Windows, XXX would create .deb for Ubuntu, and YYY would create .dmg for OS X.
Cross-platform installer that would handle all the requirements above: ZZZ?
Any recommendations? Some options that I've looked include:
NSIS - Excellent, but Windows only.
IzPack - Good, but requires JVM to run.
Is there an universal tool for this, or should I just pick an appropriate tool separately for each platform? In the latter case, what would be "NSIS equivalents" for Ubuntu and Mac OS X?
I have some recommendations as follows.
Use WIX (Windows Installer XML) for creating MSI installers for Windows
Use Package Maker (part of XCode tools) on MAC OS X, preferably the command line version
Write wrapper scripts (in Python or so) to drive the over-all installer creation process.
to aggregate all the components you need to install (may be from ur version control system)
generate necessary files for Wix and Package Maker as much as possible
to run the packaging tool and generate the package
Make sure that the overall installer creation process is a simple one command operation overall (with options to create different versions of your package based on criteria like release branch etc.)
Overall, developing this workflow requires some initial effort and quite a lot of thinking. But the end result is quite worth the effort.
I haven't done this on the Linux side, but I guess would use RPM/DEB on that front in this workflow.
BitRock InstallBuilder meets all the requirements, including being multiplatform and providing an autoupdate mechanism
You should take a look at InstallJammer. It will definitely handle the cross-platform elements that you want and can even add entries to the DEB and RPM databases on the target system during installation. OS X support is still experimental, but it mostly works.