What type is the application file in a call to COMAdminCatalog.InstallApplication - com+

Has anyone used COMAdminCatalog.InstallApplication to successfully install an application into COM+? If so what type of file do you need to pass as the bstrApplicationFile parameter?

An .msi installer. ExportApplication is the opposite (it creates an .msi installer from an existing application)

Related

How to remove an appimage's user mofied settings after or before deleting the appimage file?

I launched an appimage using appimagelauncher. Then, I modified some settings of that app.
I know that appimages are not installed, so it can't be uninstalled. So, I deleted the appimage file.
But, when I downlaoded the appimage again, I observed that the user's previously modified settings were still there.
Now, how can I completely remove those user modified settings and launch that software as if it were newly installed?
The AppImage format doesn't define an explicit place where the applications configuration should be installed. Which means that the application can write such file wherever they please (as a regular installed application does).
Applications usually write their configurations to "$HOME/.config", you can look there for a file or folder with the application name. You can also ask the application author or check the documentation.

Application installed with Inno Setup writes files to unknown location instead of its installation folder

I try to make a setup with Inno Setup for my program.
I have installed more file XML in the same folder as the .exe. The install work well, but when I run the program and modify the XML, the file is saved in another place, not the folder of the .exe and I can't find it. I think the file is stored in the PC because the program can open it without problems.
I also try to make the same setup with InstallAware Express 7 and it works well. Io I think it's not a problem in my exe but in Inno Setup.
Thanks
I think you are a victim of Windows File virtualization.
You probably install data files to Program Files folder.
That folder is not writable (unless your program runs with elevated privileges). If your program does not have application manifest, Windows considers it a legacy application that is not aware of its inability to write to Program Files and enables file virtualization. So, when your application tries to write the data/XML files, Windows redirects the write (and future reads) to a virtual store (C:\Users\username\AppData\Local\VirtualStore). The actual files in the Program Files are not modified.
It's difficult to answer, why it works with the InstallAware Express. If you tried it after the Inno Setup, the results can be affected by an existence of the file in the virtual store.
Anyway, the root cause is that your application tries to write the files in the Program Files. That's just wrong. No application should write to Program Files.
See also Application does not work when installed with Inno Setup.

Inno Setup - Stop windows asking permission to run my application

I have a 'simple' .exe (helper.exe), which is part of a software licensing package. My understanding of this file is that initializes a license file; it is run during install at elevated privileges.
I would like this file to be included with my install. I created an installer using the Wizard with default settings but every time I try to run my .exe UAC pops up and asks permission. How can I stop that from happening?
The first part of the answer was given by TLama:
You will have to modify your application's manifest to not set the
requestedExecutionLevel node to level="requireAdministrator. It has
nothing to do with the setup itself.
Later I realised I was using the file incorrectly...
I have edited the question so remainder of the answer is: helper.exe is used to initialize a license file and is supposed to be run once (I thought helper was used to check the license file and thus was supposed to be run for each check). For the record the software seems really good (I'm currently evaluating).
Cheers,

Program File saved file

I have developed an application in Visual Basic.net. When I install this application to a ProgramFiles/[Appname] folder, and I create a file that is saved in the same folder (a settings file, created from in the application), the file is not visible, yet the application can still read it.
Where is this file saved?
On Windows Vista and higher, writing to the Program Files directory requires administrative privileges. Your file is probably being affected by virtualization (a redirection of the write operation) to the virtual store. You can find it (in Windows 7) in C:\Users\<username>\AppData\Local\VirtualStore.
The obvious solution is not to try to save the settings in the wrong location in the first place. Your app should create a folder under %APPDATA%, and write it's settings there instead. This answer to a related question can provide some links that might help.

Edit a file on IIS Manager by wix installer

My requirement is to edit a .xap file which is already in the IIS Manager.. when install another web application on IIS manager. (I want to add the end points of a web application in the previous web application .xap file)
You could write a custom action to:
Open the .xap file (it's a .zip file named differently)
Extract the file(s) that need to be modified
Edit the extracted file(s)
Re-zip the extracted file(s) back into the .xap file.
You could find the existing .xap file using AppSearch of some sort. Maybe a FileSearch element. Most of the work is going to be in your custom action though. Good luck!
Please see Mike's answer over at:
NSIS Changing config file present in XAP file i.e. silverlight component build
There's two parts here:
1) Authoring the Silverlight application to use an external config file.
2) Authoring your installer to update that config file. In this case of WiX, it's the XmlConfig element in the Util extension.
The reasons for doing it this way is to have a highly reliable installer. If you write custom actions to extract, edit and compress the XAP you'll invalidate digital signatures and introduce complexity and fragility to your deployment process. Avoiding the temptation to do all this and just use XmlConfig gives you a robust, declarative installation that fully supports the Windows Installer rollback story.

Resources