I'm working with an enterprise product that installs and uses the SAP Java Connector. Is there a way I can tell (e.g. from the installed JAR and DLLs?) what version of JCo it's using?
The JCo JAR contains a main method which can be called to display some information like version of JCo JAR itself and of the native library.
You can start it with the following command from the command line, provided both the JAR and the corresponding native lib are in the current directory:
java -jar sapjco3.jar
This will open a window (on a graphical frontend) or a generate console output (on headless systems) with the information. To force console output you can add -stdout to the command (maybe only works on Unix systems).
This is also a good way to check if the JCo JAR fits to the native lib and that you are using the right distribution for your system architecture.
i'm not sure is you can modify the code or not, thus a general method first.
The class JCo contains a set of methods that returns library wide informations, such a the version :
com.sap.conn.jco.JCo.getVersion()
you can use if eiter to add a debug info in the application, or to create a small program that link to the used JCo.jar, and display the information.
Otherwise if you simply need to check the marjor version (2 ou 3), JCO version 3 is called "sapjco3.jar" while version 2 is simply "sapjco.jar"
[just right click the jar file and do Run as administrator it will give information about jco version grapically]
Related
I'm writing an auto-updater for my audio plugin which is working fine on Windows, and I feel I'm close on MAC but need some help understanding how to programmatically launch the installer on mac. The algorithm is pretty simple:
Plugin checks in S3 to see if there's a newer version
If YES then plugin downloads the installer for the new version
Once downloaded the plugin should launch the installer and prompt the user to close the DAW (audio workstation)
This is working fine, I can download the installer on both platforms, and on windows launch it by using CreateProcess, but I can't find the right way to do it on mac. The closest equivalent I can find is "posix_spawn" in order to launch a process and then run "/user/sbin/installer -pkg /path/to/pkg /target", and although this is returning 0 indicating success I don't see any installer popping up on the screen. Ideally the user would see the UI of the installer as there are some options included.
How can I accomplish the goal of opening a PKG file visually for the user on mac using C++? OR, is there an alternative solution to accomplish the algorithm described above? Many thanks!
I created the MSI build package for our application. After this installation, we triggered another dependent driver software in the separate process in a committed event of Installer class like below,
Process.Start (" Path of driver software ")
We are facing an issue, installed directory ( It's empty ) folder is not removing while un-installing the same. Actually like installation, we triggered the un-installation of dependent driver software in the separate process by overriding the Uninstall method of installer class.
Anyone, please help me to overcome this issue? How could I remove the installed directory?
I can't change the installation procedure, since we are aware that we can't process another installation/un-installation when another one is going.
You are running a non-MSI driver install EXE from within your MSI? Correct? Or maybe it is an MSI wrapped in an EXE?
Do you have Installshield Premier? Could you use a suite project and install the EXE via the bootstrapper before (or after) the MSI install? I have honestly never used this feature, but running setups in sequence is what it is for. Embedded custom actions in MSI files kicking off EXE files are notoriously unreliable. This is - in my opinion - especially true if you are running with managed code as well (which I think you are).
In the long run managed code may yield safer custom action code (security-wise based on CAS), but for now it seems to cause unwanted runtime dependencies - especially for very large-scale distribution (global distribution) targeting diverse Windows versions (Vista, 7, 8, 10).
I am told it takes a while to get used to Installshield's suite feature, but maybe it is better for you? You can run EXE files, MSI files, patches and zips in sequence. Some fiddling to define uninstall and upgrade behavior I guess and lots of testing. I am pretty sure corporate application packagers would be happy to see a suite rather than an MSI with lots of strange stuff embedded in it.
UPDATE: Once you have compiled a suite setup.exe file it can be extracted as described here: Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file
Alternatively you could try to extract the setup.exe files for the driver setup and install the drivers as regular MSI components and run DPinst.exe to install / uninstall the drivers (tool from DIFx). Also quite clunky - especially when you need to include uninstall.
Your driver setup likely uses DPInst.exe already. I would check if you can extract an MSI from the EXE and use it instead of the EXE to include in the suite project. Some hints for how to deal with setup.exe files (extraction, runtime paramenters etc...): Extract MSI from EXE.
WiX has the Driver element in one of its extensions to deal with driver installs. I have never had the chance to test it.
I'm porting some Qt Windows/VC++ code to Linux/GCC. The application can add it's own shortcut to the Windows Autostart folder so the application starts after login.
I want to do the same in Linux. I'm using Kubuntu 15.10 but the solution should work for virtually all (or at least most) Linux variants out there. And it should work without super user rights (or it should request the rights automatically).
I searched the web and found two solutions:
Add a desktop entry file to $HOME/.config/autostart
Add a symbolic link to /etc/init.d/
Will they both work in all Linux distributions? What are the differences? Which is to be preferred?
Also I would like to know if I should do that by programmatically running a shell command or if there is some native API I could use in C/C++ (including easy error detection).
I have put project in GitHub for managing auto-start feature in different OS. It's written in Qt.
Please check it and let me know if you have any problem using it:
https://github.com/b00f/qautostart
You can add application in various ways.
Via linux init system. For newest linux OS systemd is a standard. In this case your need to create systemd unit for your application
Via desktop manager, such as gnome, kde and possible others. In this case you need also create specification for autostarting your app.
Via bash files
I think, prefered way via systemd unit, because now this is standard way for starting process at boot time and for special user, if need.
I asked this question in a more general design context before. Now, I'd like to talk about the specifics.
Imagine that I have app.exe running. It downloads update.exe into the same folder. How would app.exe copy update.exe over the contents of app.exe? I am asking specifically in a C++ context. Do I need some kind of 3rd mediator app? Do I need to worry about file-locking? What is the most robust approach to a binary updating itself (barring obnoxious IT staff having extreme file permissions)? Ideally, I'd like to see portable solutions (Linux + OSX), but Windows is the primary target.
Move/Rename your running app.exe to app_old.exe
Move/Rename your downloaded update.exe to app.exe
With the next start of your application the update will be used
Renaming of a running i.e. locked dll/exe is not a problem under windows.
On Linux it is possible to remove the executable of a running program, hence:
download app.exe~
delete running app.exe
rename app.exe~ to app.exe
On Windows it is not possible to remove the executable of a running program, but possible to rename it:
download app.exe~
rename running app.exe to app.exe.old
rename app.exe~ to app.exe
when restarting remove app.exe.old
It's an operating system feature - not a C++ one.
What OS are you on?
In Windows see the MoveFileEx() function, on linux simply overwrite the running app ( Replacing a running executable in linux )
On Windows at least an application running is locking its own .exe file and all statically linked .dll files. This prevents an application from updating itself directly, at leads if it desires to prevent a re-boot (if re-boot is OK the app can pass in the MOVEFILE_DELAY_UNTIL_REBOOT flag to MoveFileEx and is free to 'overwrite' it's own .exe, as is delayed anyway). This is why typically applications don't check for updates on their own .exe, but they start up a shim that checks for updates and then launches the 'real' application. In fact the 'shim' can even be done by the OS itself, by virtue of a properly configured manifest file. Visual Studio built application get this as a prefab wizard packaged tool, see ClickOnce Deployment for Visual C++ Applications.
The typical Linux app doesn't update itself because of the many many many flavors of the OS. Most apps are distributed as source, run trough some version of auto-hell to self-configure and build themselves, and then install themselves via make install (all these can be automated behind a package). Even apps that are distributed as binaries for a specific flavor of Linux don't copy themselves over, but instead install the new version side-by-side and then they update a symbolic link to 'activate' the new version (again, a package management software may hide this).
OS X apps fall either into the Linux bucket if they are of the Posix flavor, or nowadays fall into the Mac AppStore app bucket which handles updates for you.
I would day that rolling your own self-update will never reach the sophistication of either of these technologies (ClickOnce, RPMs, AppStore) and offer the user the expected behavior vis-a-vis discovery, upgrade and uninstall. I would go with the flow and use these technologies in their respective platforms.
Just an idea to overcome the "restart" problem. How about making a program, that does not need to be updated. Just implement it in a plugin structure, so it is only an update host which itself loads a .dll file with all the functionality your program needs and calls the main function there. When it detects an update (possibly in a seperate thread), it tells the dll handle to close, replaces the file and loads the new one.
This way your application keeps running while it updates itself (only the dll file is reloaded but the application keeps running).
Use an updater 3rd executable like many other apps.
Download new version.
Schedule your updater to replace the app with the new version.
Close main app.
Updater runs and does the work.
Updater runs new version of your app.
Updater quits.
I am in the process of installing a ColdFusion application on Solaris 10 64-bit (Sparc) running with WebSphere 6.1. The cfcompile script that comes with CF makes a reference to jrun.jar however this library is not available when CF is installed as an ear file. An abstract of cfcompile.sh is the following:
su $cfuser -c "${_JAVACMD} -cp $CLASSES -Dcoldfusion.classPath=$CFUSION_HOME/lib/updates,$CFUSION_HOME/lib -Dcoldfusion.libPath=$CFUSION_HOME/lib coldfusion.tools.CommandLineInvoker Compiler -cfroot $CFUSION_HOME -webinf $WEBINF -webroot $webroot $dir"
Do you see ways to solve this problem (that is to precompile an application), besides installing CF as a standalone running on JRUN server?
Have you checked the contents of the EAR file? There should be a WAR file, in which you'll find WEB-INF/lib. It may be in there. If so, extract it and place it on the classpath.
EAR/WAR file are just zip compressed archives.
This is just a "best guess" on my part.
HTH
Can you install in stand-alone mode on some other temporary location (preferably the same OS & version), and copy jrun.jar to where you want it to be, on the permanent home of the application?
I created my own version of cfcompile.sh on-site to work on the client's infrastructure. The most important part is to have a correct reference to j2ee.jar (found in WAS distribution).