I have used Flexera's Installshield and it has seemed to work for the most part except the shortcuts it placed in the start menu and on the desktop.
The issue arises when the program starts and returns an error with opening the sqlite database file.
The issue is fixed by running the actual .exe from the program files folder, and if I create a manual shortcut.
I have noticed that the automatic shortcuts they have a target of what the manual shortcut has for a target location.
Any ideas?
I am not in a position to propose a direct solution for your specific problem. On the other hand, I have had some paths/relative-reference problems in the past when working with different Windows installer packages which I solved by running a program passing all the required information to the installer.
Example of what I mean:
A small program is executed right before starting the installation. It retrieves all the required information (e.g., desktop's path) and writes it to a temporary location (e.g., Windows Registry).
The main installation package is started, reads/deletes the
information from the temporary location and brings it into account
while performing the installation (e.g., path for the shortcuts).
Depending upon the available setup options, you might perform the aforementioned actions in different ways. The simplest alternative I see is: creating an .exe file (install.exe), only one to be executed by the user; it will be in charge of retrieving all the required information, writing it to the temporary location and calling the main package (\installation files\setup.msi). Right after being started, the installation package will read the information from the corresponding temporary locations, delete them and bring this information into account while performing the corresponding actions (setting up the shortcuts).
The main reason why I prefer to rely on this kind of configurations (preliminary .exe calling the main package or script/.exe being called by the installation package as the first action) is because it offers a high flexibility. It does not only accont for eventual problems/incompatibilities from the installation software, but also sets up a framework allowing me to perform more complex actions (e.g., security system) whose implemention is much easier by relying on the corresponding programming language (C# in this case).
Related
This is the situation I have:
I created an installer. It has python scripts, executable, and other file types. In the installer, I run a C# executable as a custom action, after registering the product. The C# executable moves the files into different locations (i.e. a text document will be moved to My Documents). I understand I can do this without the custom actions, but I was not aware of that when I created the installer.
Now, after I have distributed the software, users are running into small bugs. For instance, there is a bad if check in one of the python scripts.
Question Is there a way to fix the portion of the python script/executable/text document that is broken, and simply update those files (without having to redistribute the software to the users, and having them reinstall it)?
A patch probably won't help you. If the locations are fixed within the install, a minor upgrade could do the trick, if you make all the files that need to stay the same "never overwrite" (unless the custom action ignores this, then things might get difficult).
If the locations are determined during the execution of the custom action, or the locations are based on user input during the install, then you have a problem if you haven't saved the location paths (in the registry, for example). I don't think you want a custom action to scan all the drives of the computer just to find the files.
If the files are put in their new locations by the custom action, windows installer probably won't see them as key files and probably won't "repair" them in any scenario. If the fixes are few, you might be better of distributing the files separately with a clear instruction, in stead of spending many hours on a difficult new custom action.
Cheers, B.
I'm sorry, apparently I missed the trigger that you had placed a comment.
If this is this something you would like to know, look at this table. It shows when to use major, minor or small fix (patch).
Hope it helps.
Cheers!
http://helpnet.installshield.com/installshield17helplib/MajorMinorSmall.htm
Windows 7 uses an automatic mechanism to detect whether an application needs elevated administrator privileges. Or the application itself has a manifest.
Is there a way to find out programmatically whether a specified application needs elevated administrator privileges or not?
I don't want to start it to find it out.
Thank you ;).
There's really just one way to tell Windows that a program needs to be elevated and that's through the manifest file. Manifest files can either be embedded within an assembly (exe/dll) or can live in a separate file named <YOUR_APP>.exe.manifest. That's really the only way and probably the only way that you can safely check. Officially.
Windows also contains a giant database that's used for application compatibility. If Microsoft has tested an app and found that it breaks when an OS upgrade happens they sometimes creates an entry in the database to essentially hack the app. Sometimes they lie about the current OS version, sometimes they automatically run as administrator, sometimes they do a bunch of other things. You can view the database using the Application Compatibility Toolkit. I don't know if there's an official way to query the database via code. This blog post talks about a tool that the blogger made but apparently never release.
The last automatic elevation mechanism is algorithm that tries to determine if that app is an installer. According to MSDN these attributes are checked:
Filename includes keywords like "install," "setup," "update," etc.
Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename,
Internal Name, and Export Name.
Keywords in the side-by-side manifest embedded in the executable.
Keywords in specific StringTable entries linked in the executable.
Key attributes in the RC data linked in the executable.
Targeted sequences of bytes within the executable.
The keywords and sequences of bytes were derived from common
characteristics observed from various installer technologies.
Lastly, an app can run as a normal user but spawn a child process that requires elevated privileges. I don't know if there's really any way to actually detect that short of decompiling the app itself.
This question already has answers here:
Why does rename a loaded .net assembly work?
(3 answers)
Closed 5 years ago.
We are trying to push updates to multiple servers at once and my manager has found that it is possible to rename running .exe file. Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
I guess I need to clarify, He doesn't expect the old copy to magically update, he just expects them to keep running the old copy until they open the exe again, in which case it will then open the new one that has the name of the old one.
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed. On my machine I have yet to be able to get it to work even in a loop.
My first and main question is this: Is it ever acceptable to do this. Should renaming a running executable ever be a valid scenario?
Secondly, if it is a valid scenario then how could one reliably do this? Our current thoughts are try a bunch of times using File.Move (C#) to do a rename and if it doesn't work then write out to an error log so it can be handled manually.
An airplane mechanic and a surgeon meet in a bar. The mechanic says "you know, we have basically the same job. We take broken stuff out and put new, better parts in." The surgeon says "yeah, but you don't have to keep the plane flying as you're making the repairs!"
Trying to update an application by moving files while the application is running seems about as dangerous as trying to fix an airplane in flight. Possible? Sure. Greatly increased risk of catestrophic crash? Yep.
If the application you are updating is a managed application, consider using ClickOnce Deployment. That way, the next time someone runs the application, if there is a new version available it will be copied down and installed automatically. That's much more safe and pleasant than trying to mess with an application while its still running.
No, this is not acceptable. Do not do this. This is not a valid deployment mechanism. This should have been yours or his first clue:
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed.
And it won't work, anyway. His theory is quite wrong:
Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
Specifically, the copy in memory will not be automatically replaced with the new executable just because it has the same name. The reason that you're allowed to rename the executable in the first place is because the operating system is not using the file name to find the application. The original executable will still be loaded, and it will remain loaded until you explicitly unload it and load the new, modified executable.
Notice how even modern web browsers like Chrome and Firefox with their super fancy automatic, in the background, no one ever notices that they exist, updaters still have to close and relaunch the application in order to apply the updates.
Don't worry about shooting the messenger here. It's more likely that your customers and your tech support department will shoot you first.
See number 1.
In our organization, we solved the problem of Updates by having two release folders say EXE_A and EXE_B. We also have a release folder called EXE which only has links ALL of which points to either to EXE_A or EXE_B from which the user runs the applications.
When we publish a new version of the program, we publish it to the folder that is not referenced in the links and then update the links (EXE). In this way, you do not get into exceptions that users are holding the application / assemblies. Also if a user wants to run the updated version, all he need to do is close / re-execute the link in EXE folder.
If you use Windows Vista/Server2k8 or newer you could use mklink to create a symbolic link to the folder containing your application and start the application out of the "symblic linked folder" and then at the update create a new folder, e.g. "AppV2" and change the SymLink to that folder, so the next time the user restarts the application he starts it out of the new folder without noticing.
Renaming open files is ALWAYS a bad choice!
But in general I would think of a better deployment strategy anyway, because if you need to use such "hacks" it is always a messy situation. I don't know your application, but maybee ClickOnce would be a point to start, because you can configure it to check for updates on every start...
Is there a reliable method to check if an application is run from somewhere beneath program files?
If the user installs the application to program files on local machine, we need to put writable files somewhere else to avoid virtualization on Vista and Win7. When installed to a network disk, though, we want to keep these files with the installation for shared access among users.
Today we do an string comparison between startup path and CSIDL_PROGRAM_FILES, but something tells me this is a very unreliable method.
Any smart solution out there?
Is there a 'IsRunningFromProtectedFolder( )'-api that I do not know about?
Are there any other folders giving the same problems as program files do?
This is not a terribly good idea, as a user can install it wherever they want to, and then the check might fail. Instead have a checkbox when the user installs the app, deciding if it is installed locally or on a server.
As you I also found problems dealing with UAC folder virtualization.I suggest a workaround, it seems that it should work.
It comes from the assumption that elevated processes always use original copies and not the virtualized ones (CMIIW). Also I assume that you setup processed was executed elevated
The idea is to create a "general" process (non-elevated, legacy), that your main installer should run. This process will create a file name in the user chosen folder with a name and contents that both your programs know (for example, test73819704.bin). If the folder virtualized, this file should appear in the user VirtualStore and SHOULD NOT in the original one (from the point of view and privileges of the installer).
So for chosen C:\Program_Files_But_Not_Necessarily and Process-1 (elevated)
Process-1 ensures there's no file C:\Program_Files_But_Not_Necessarily\test73819704.bin
It launches Process-2 with no elevation
Process-2 creates C:\Program_Files_But_Not_Necessarily\test73819704.bin and checks whether it really exists. If exists it would return with a good return code, otherwise with a "failed" one.
Process-1 waits for Process-2 and analize the result. If good, checks for C:\Program_Files_But_Not_Necessarily\test73819704.bin, if it exists, go for "Bingo! No virtualization occured", if doesn't exist, "Bad, let's find some other storage place". If the code from the Process-2 is "failed" one, show the user some error message.
Unfortunately I could not test it right now, but I guess it should work and there's a logic behind this, with Process-2 you just emulate the behavior of your main program )
We allow our users to install anywhere...
If the user has taken the default, and is installed in Program Files, we make the assumption that we need to write to Documents and Settings/Users. Otherwise, we write our data to a folder under the directory the software is in. This of course can still cause problems, and the install does indeed allow people to choose a different data location if they choose to not go for the default.
On top of that, it's a simple ini file change and a copy to move the data.
On start up we detect if we are in the Program Files directory by comparing the value we obtain from SHGetFolderPath(CSIDL_PROGRAM_FILES) with the start of the path the executable is in.
I have a few questions related:
1) Is possible to make my program change filetype association but only when is running? Do you see anything wrong with this behavior?
2) The other option that I'm seeing is to let users decide to open with my application or restore default association ... something like: "capture all .lala files" or "restore .lala association". How can I do this? What do you think that is the best approach?
Regarding file associations, I've wrote an answer earlier that at least covers the "How".
This should also point you to the right direction how to handle backup and restore. With direct registry access through c#, there will be no need to use .reg files, so you are free to back up the previous value however you like in your app, and also restore it from there.
The key question here is: Should you change file associations randomly? At least asking the user up-front would obviously be necessary (as you also indicated).
Furthermore, Vista users with UAC enabled, or non-privileged users of other Windows versions may not have the required permission to change global file associations. The (un)installation procedure of your program may be the only place where this can succeed.
EDIT
As Franci Penov indicated in his answer, there is a way to change local file associations on a per-user basis, even for non-admins (that's why I spoke of "global associations" in the previous paragraph). He also mentioned mentioned why going there is not overly advisable.
You can implement an "on the fly" file association change by associating a small executable with that file extension that upon start will check if your main application is running and pass the file name to it or if it's not running it'll invoke the "regular" associated application.
The main advantage of this approach is that you need to muck with the registry only once.
The main drawbacks of this approach are:
you need a helper process
the application that "owns" these file extensions can detect the change and complain to the user, prompting "repair" thus getting you out of the picture.
Alternatively, you could change the file association upon your main program start. This will work even for non-admin users. while file associations are stored in HKEY_CLASSES_ROOT, there's a small trick - HKCR is actually a map of both HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\SOFTWARE\Classes. Thus, you can temporarily register the file extension for the current user in HKCU and "shadow" the original association from HKLM.
Of course, I would advise against this approach though, as it takes just one crash in your application to make that association permanent and since very few applications know how to deal with file associations in HKCU, chances are it'll be an unrecoverable situation for the original application.
It can probably be done but I think it would end up being cumbersome. All file type associations are stored in the registry so you would have to write/revert registry entries every time your app starts and stops. Also, depending on how frequently you do it the new associations may not be picked up in Windows explorer immediately.
The associations are listed under HKEY_CLASSES_ROOT in the registry and can be mapped a whole myriad of ways (mime types/progIDs/etc).
Many apps I have seen ask if you want to associate certain file types with the application during install time, and give you the ability to opt-out and leave the current settings.
I don't think I'd recommend "on the fly" file type associations
1) you get to define the file types that are in the Open Dialog file type droplist.
Outside of that, it's possible to change the filetype default on application open, and then replace during application close, as file type association are just a registry setting.
As for wrong, I wouldn't. First reason is that it's not the standard behavior of applications. The second reason is that if your application or PC exits unexpectedly, you run the risk of not returning the association to it's original setting.
2) Windows by default allows user to choose these options utilizing the right-click and the "open with" command.