I'm using Inno setup to build an application installer.
During the installation I am adding a registry key which provides a PATH where I will store common files (dlls etc.) which might be used by multiple different applications (or multiple versions of the same application!).
I am using the method suggested in this article: http://www.codeguru.com/cpp/w-p/dll/article.php/c99/Application-Specific-Paths-for-DLL-Loading.htm
The problem I have is that when the installation is complete, the user can auto-run the application. In this instance, the application cannot find the dlls in the PATH location. If I close the application and relaunch it from the explorer it works just fine.
I don't want to place the files in standard shared dll locations, they aren't all dlls, and I want better control of what dll versions my applications are using. Also, putting the files in the application installation .exe directory isn't an option either. I also don't want to add the PATH to the system environment path (even if I did, I suspect I would probably have the same problem anyway!)
Any ideas?
Some background and my 'current' solution. Key I'm trying to add is:
[Registry]
Root: HKLM; Subkey: "SOFTWARE\Microsoft\..\App Paths\{#ExeName}.exe"; ValueType: string; ValueData: "{app}"; Flags: uninsdeletekey
Root: HKLM; Subkey: "SOFTWARE\Microsoft\..\App Paths\{#ExeName}.exe"; ValueType: string; ValueName: "Path"; ValueData: "{#CommonPath}"; Flags: uninsdeletekey
In my [run] section I had:
Filename: {app}\{#ExeName}.exe; Description: {cm:LaunchProgram,{#AppName}}; Flags: nowait postinstall skipifsilent
I changed the flags to:
postinstall shellexec skipifsilent
As per Inno Setup Help using the shellexec command:
The file will be opened...the same way it would be if the user double-clicked the file in Explorer.
Along the lines of Martin's answer above, I believe it works because shellexec spawns a new process which picks up the environment changes, unlike if I launch the application as a child of the installer's process.
Related
The legacy app i'm working on is downloading classes on windows to the users AppData:
${installer:sys.userHome}/AppData/Local/TheOrg/${installer:productName}/Lib
'productName' is a installer variable that is configurable as a step in the installer
This is given as an argument to the main class by the installer and at that point
${installer:sys.userHome} and ${installer:productName} resolves correctly
However when I use the same location (${installer:sys.userHome}/AppData/Local/TheOrg/${installer:productName}/Lib) as a Class Path as value of an 'Scan Directory" entry something seems off. If I hard code this to
C:/Users/MyUser/AppData/Local/TheOrg/MyApp/Lib everything works fine.
What is the difference between 'Directory' and 'Scan Directory', and are there any reasons why the Classpath isn't picked up correcly when I'm using variables?
You cannot use installer variables in the class path entries of a launcher. You can see that in the variable selector which does not offer installer variables.
The technical reason is that the class path is constructed by the native launcher which does not have access to installer variables because they are read and instantiated by the Java part of the installer.
On Windows, you can use the environment variable ${LOCALAPPDATA} in class path entries to refer to the local app data directory.
Btw, use ${installer:sys.localAppdataDir} instead of ${installer:sys.userHome}/AppData/Local, the location of that directory might not be in the user home directory.
I want to import silently server configuration (such as Applications servers -> Process Definition -> Java Virtual Machine -> Generic JVM arguments etc.).
I've tried wsadmin tool, but it requires WSA to be running - and this is bad for me, because I need to write script that copies these settings without any interaction.
wsadmin -lang jython -c "AdminTask.importWasprofile('[-archive d:\profil2.car]')"
Another way was the "Import server configuration from server..." option in Eclipse context menu (Servers tab), but it still needs interaction from user.
Is there any way to copy those settings? Should I copy some files or something?
I'm installing Rational Application Developer 7.0.0.7. I have also generated .car file with exported settings.
Ok, I've managed to import all those settings silently.
First, you have to export profile using f.e. wsadmin script.
Command
wsadmin -lang jython -c "AdminTask.exportWasprofile(['-archive', 'd:\sampleProfileName.car'])
Will export default profile to .car file (which is, in fact, .zip file with other extension). It is nice to add here, that my version of WAS wouldn't export SIB settings.
Importing those settings is as easy, as exporting, you just have to run command
wsadmin -lang jython -conntype none -c "AdminTask.importWasprofile('[-archive d:\sampleProfileName.car]')"
Note using -conntype option, as #bkail mentioned
Sadly, WAS 6.x and earlier does not support exporting/importing SIB settings (as mentioned HERE). In order to copy them, you have to add manually to .car file buses directory (as mentioned HERE). The problem is - adding them by admin console didn't create this directory for me.
I had to use another wsadmin script that creates SIB - I've found it HERE. It simply uses AdminTask object to create bus manually - and thanks to it, it created the buses directory.
Hope this helps somebody who has the same problem as I had - and it will save him MANY hours.
Greetings.
I've written an Inno Setup script that copies a few existing files to a backup folder, appending the date of the current installation to the backed-up filename, like this:
Source: "{app}\vDosDisk\WP51\VDOSPCL.PRS"; DestDir: "{app}\51Config\Backup51"; DestName: "VDOSPCL.PRS.{code:GetTodaysName}"; Flags: external skipifsourcedoesntexist; Components: InstallForWP51
(The GetTodaysName code is someone else's code for building a string from the current date and time.)
Here is my question: Is it possible to write some code that will ONLY create a backup file if the file that is currently on disk is different from the file that my installer is going to install (and thus overwrite the existing file)?
As far as I can tell, none of the built-in flags can accomplish this.
Thanks for any help.
I'm using virtualenv, virtualenvwrapper and PyCharm.
I have a postactivate script that runs an "export" command to apply the environment variables needed for each project, so when I run "workon X", the variables are ready for me.
However, when working with PyCharm I can't seem to get it to use those variables by running the postactivate file (in the "before launch" setting). I have to manually enter each environment variable in the Run/Debug configuration window.
Is there any way to automatically set environment variables within PyCharm? Or do I have to do this manually for every new project and variable change?
I was looking for a way to do this today and stumbled across another variation of the same question (linked below) and left my solution there although it seems to be useful for this question as well. They're handling loading the environment variables in the code itself.
Given that this is mainly a problem while in development, I prefer this approach:
Open a terminal
Assuming virtualenvwrapper is being used, activate the virtualenv of the project which will cause the hooks to run and set the environment variables (assuming you're setting them in, say, the postactivate hook)
Launch PyCharm from this command line.
Pycharm will then have access to the environment variables. Likely because of something having to do with the PyCharm process being a child of the shell.
https://stackoverflow.com/a/30374246/4924748
I have same problem.
Trying to maintain environment variables through UI is a tedious job.
It seems pycharm only load env variables through bash_profile once when it startup.
After that, any export or trying to run a before job to change bash_profile is useless
wondering when will pycharm team improve this
In my case, my workaround for remote interpreter works better than local,
since I can modify /etc/environment and reboot the vm
for local interpreter, the best solution I can do are these:
1. Create a template Run/Debug config template and clone it
If your env variables are stable, this is a simple solution for creating diff config with same env variables without re-typing them.
create the template config, enter the env variables you need.
clone them
see picture
2. Change your script
Maybe add some code by using os.environ[] = value at your main script
but I don't want to do this, it change my product code and might be accidentally committed
Hope someone could give better answer, I've been spent too much time on this issue...
Another hack solution, but a straightforward one that, for my purposes, suffices. Note that while this is particular to Ubuntu (and presumably Mint) linux, there might be something of use for Mac as well.
What I do is add a line to the launch script (pycharm.sh) that sources the needed environment variables (in my case I was running into problems w/ cx_Oracle in Pycharm that weren't otherwise affecting scripts run at command line). If you keep environment variables in a file called, for example, .env_local that's in your home directory, you can add the following line to pycharm.sh:
. $HOME/.env_local
Two important things to note here with respect to why I specifically use '.' (rather than 'source') and why I use '$HOME' rather than '~', which in bash are effectively interchangeable. 1) I noticed that pycharm.sh uses the #!/bin/sh, and I realized that in Ubuntu, sh now points to dash (rather than bash). 2) dash, as it turns out, doesn't have the source "builtin", nor will ~ resolve to your home dir.
I also realize that every time I upgrade PyCharm, I'll have to modify the pycharm.sh file, so this isn't ideal. Still beats having to manage the run configurations! Hope it helps.
OK, I found better workaround!
1.install fabric in your virtualenv
go to terminal and
1. workon your virtualenv name
2. pip install fabric
2. add fabric.py
add a python file and named it "fabric.py" under your project root, past the code below,and change the path variables to your own
from fabric.api import *
import os
path_to_your_export_script = '/Users/freddyTan/workspace/test.sh'
# here is where you put your virtualenvwrapper environment export script
# could be .bash_profile or .bashrc depend on how you setup your vertualenvwrapper
path_to_your_bash_file = '/Users/freddyTan/.bash_profile'
def run_python(py_path, virtualenv_path):
# get virtualenv folder, parent of bin
virtualenv_path = os.path.dirname(virtualenv_path)
# get virtualenv name
virtualenv_name = os.path.basename(virtualenv_path)
with hide('running'), settings(warn_only=True):
with prefix('source %s' % path_to_your_export_script):
with prefix('source %s' % path_to_your_bash_file):
with prefix('workon %s' % virtualenv_name):
local('python %s' % py_path)
3. add a external tool
go to
preference-> External tools -> click add button
and fill in following info
Name: whatever
Group: whatever
Program: "path to your virtualenv, should be under '$HOME/.virtualenvs' by default"/bin/fab
Parameter: run_python:py_path=$FilePath$,virtualenv_path=$PyInterpreterDirectory$
Working directory: $ProjectFileDir$
screenshot
wolla, run it
go to your main.py, right click, find the external name (ex. "whatever"), and click it
you could also add shortcut for this external tool
screenshot
drawbacks
this only work on python 2.x, because fabric don't support python 3
I try to install/run emacs on a Win7 64-bit machine after using it for years on a WinXP 32-bit machine and run into a problem I do not find any help for in the documentation or on the web.
Symptom:
when starting runemacs.exe for the first time it creates the file
*C:\Users\USER\My Documents.emacs.d*
as one would expect (for my administrator as well as for my user account)
and comes up operational
from the second start of runemacs.exe it breaks in the startup phase,
displaying the scratch buffer, ringing the warning bell and displaying in
bottom line the error:
File exists: c:/Users/USER/My Documents/.emacs.d/
buffer messages specifies:
make-directory: File exists: c:/Users/USER/My Documents/.emacs.d/
if runemacs was called with a file to open, i.e. because the file type was
associated with it and the file was opened to edit, the file is not open
and ready to be edited, but a file can be opened via the menu File->Open File...
but my configurations in the file
C:\Users\USER\My Documents.emacs
are not loaded
My goal:
I want to regain the way I used emacs on the old WinXP 32-bit system:
click a file associated with emacs, get it opened and ready for editing, get my configurations in .emacs loaded automatically, i.e. work with emacs seamlessly.
Checks done and failed attempts to fix this:
I tried the following newly downloded versions of emacs
emacs-23.4-bin-i386.zip
emacs-23.2-bin-i386.zip (the one I used on the WinXP)
I had the emacs directory containing the directory stucture (bin, etc, ...)
located at:
C:\Program Files (x86)\emacs-23.4\ (my preferred location)
C:\Emacs\emacs-23.4\
in the download directory, where I originally extracted it
My HOME variable points to:
C:\Users\USER\My Documents (default)
C:\Users\USER\My Documents\ (tried)
My PATH variable contains:
C:\Program Files (x86)\emacs-23.4\bin (default)
or the corresponding other locations which I tried
The ownership and permissions of my C:\Users\USER\My Documents.emacs.d
look OK:
owner is the USER (administrator or standard_user)
permissions grant Full Control
Having originally installed emacs to *C:\Program Files (x86)\emacs-23.4*
using the administrator account, I also tried to use user account installation
instead (to check for some non- obvious parameter/access permission not set
right if the admin account is uses for setup)
For the runemacs.exe executable I manually set the compatibility settings to
Windows XP (Service Pack 3)
default setting after unpacking: no compatibility setting enabled
I removed the private configuration file C:\Users\USER\My Documents.emacs
(inherited from my XP installation) to check whether it produces a screw-up
All that did not change a bit of the described symptom, i.e. either I screwed up
in testing the above and missed a particular setting which should work, or I am looking into the wrong direction...
It is still unclear to me whether this has anything to do with:
W7 64-bit vs. XP 32-bit
environmental parameter screw-up
emacs configuration (.emacs, .emacs.d) screw-up
general stupidity (of me ;-)
... and why is it has emacs a problem with it in the first place, that the .emacs.d directory already exists... That should be the standard case...
Any help and wisdom much appreciated.
First of all, nice question. The details and listing of what you've already tried is helpful.
Some points:
Don't have spaces in key paths (Emacs, and %HOME%). Generally, things work
fine. But when things break it's often hard to debug and trace back to the
fact that some package author didn't take spaces properly into account.
Set a HOME environment variable to your %USER_PROFILE%. Make it
%USER_PROFILE%/home if you must, but I use the former.
Start by running emacs without any customization.
runemacs -Q
When that works, add your customizations one at a time.
n.b. This answer is not relevant to the original question (which was about Windows), but may be useful to Unix users searching for this error message
You will get this error also if emacs does not have the correct permissions on the .emacs.d directory.
Check it
ls -ld $HOME/.emacs.d
And make sure the user you are running under has rwx permissions!
I got similar problems when I installed the new version of emacs on a new installation of the ubuntu 12.10. I get the problem fixed by chmod 777 .emacs.d, that is, as the previous post pointed out, the emacs does not have the access right to .emacs.d directory. Hope this help.