I've got a pretty simple installscript MSI project - it copies some files into a folder, updates a few registry keys and that's pretty much it.
When I try to use the Repair function (either by re-launching the installer, or by choosing the app's Modify option under Apps & Features), I get the following message, when it gets to the "Copying new files" stage:
"The feature you are trying to use is on a network resource that is unavailable.
Click OK to try again, or enter an alternate path to a folder containing the installation package 'project.msi' in the box below."
The path in which it looks for the .msi file is %TEMP%\[SOME_RANDOM_HEXADECIMAL_STRING]
This random hexadecimal string doesn't seem to be specifically related to the project. It's neither the Product Code nor the Upgrade Code nor the Package Code.
When I look for it in the registry, I find it in the values of the following keys:
Computer\HKEY_CLASSES_ROOT\Installer\Products\[SCRAMBLED_PRODUCT_CODE]\SourceList\LastUsedSource
Computer\HKEY_CLASSES_ROOT\Installer\Products\[SCRAMBLED_PRODUCT_CODE]\SourceList\Net\3
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\[ANOTHER_SCRAMBLED_PRODUCT_CODE]\SourceList\LastUsedSource
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\[ANOTHER_SCRAMBLED_PRODUCT_CODE]\SourceList\Net\3
Looking at the %TEMP% folder, I can find the .msi file in a folder that has another random hexadecimal string as its name. That folder does not appear in the registry at all.
I don't want my clients to go looking for .msi files every time they want to repair an installation of my product. How can I let the installer know the .msi file's location?
The source files you installed from are probably just missing since your temp folder has been cleaned out (where the install originally ran from).
There used to be a cache the whole MSI - feature you could enable on a release-configuration basis (Cache MSI Locally). This would "solve" this problem I believe by caching the whole MSI in a safe location (see section 3). Many do this, despite the increased disk space used.
Another option is to install from an administrative installation (essentially an extract of your setup's files - run via setup.exe /a or msiexec.exe /a MySetup.msi - which has been put available on a network share, always available for repair or modify operations). This is what corporate deployment uses to support repair and modify operations.
Related
Hi DocuSign CLM geeks and the DocuSign API in-house team-
Our team will be using DocuSign CLM with the DocuSign Edit add-on to easily open Microsoft Word files and save back to CLM.
We'd like to include the installation of DocuSign Edit in our Silent Mode installation configuration. We're hoping there's an msi File available for the DocuSign Edit extension? If so, please link!
Plan B- If we were to make our own msi from the available exe, does anyone have a trail stomped out for doing this? (a blog post, documentation, step by step, video demo, even a horror story)
Thanks for tips.
https://tools.springcm.com/sites/default/files/apps/docusign-edit-pc-2.01.00.exe
This is an exe that is built from an MSI, so it is an MSI.
If you want to get the MSI out of this https://www.codetwo.com/kb/msi-from-exe/:
The first method is based on the fact that most installers extract their .msi files to the temporary files folder during the installation process. To extract an MSI file from an EXE installer, you need to:
Launch your .exe file.
When you see the first prompt (e.g. a question about whether you want to continue installation, accept a license agreement, etc.), do not click anything in this window and do not close it.
Open Windows Explorer, type %temp% in the address bar and press Enter.
Sort the files in the folder by the modification date. The newest file on the list should be the .msi file you are looking for.
Copy the MSI file to a safe location before you close the installer prompt window (see step 2). Be aware that if you close the installer window, the MSI file will be immediately deleted from the temporary files folder.
The second method uses a free third-party tool called 7-Zip to browse the content of the .exe installer file. Follow the steps below.
Download 7-Zip from this page and install it.
Right-click on the .exe file (from which you want to extract an .msi file) and from the shortcut menu choose 7-Zip > Open Archive.
Do not extract any files yet. Instead, browse and look for the folder MSI within the contents. It might take some time to find this folder because it is not always located directly in the root directory (its location may vary depending on the installer).
When you locate the MSI folder, you will notice that it most likely does not contain any .msi files, but a file or files with no extensions and rather cryptic names such as 132. Despite these misleading names, these are actually the MSI files you are looking for.
Drag and drop these files to any desired folder or select them and extract them with 7-Zip. Close 7-Zip after that.
Change the names of the extracted files so that they include the .msi extension.
If there are two files, the larger one is the 64-bit installer, and the smaller one is the 32-bit version. Use the one you need.
Finally, if you want to tweak an MSI, you can use the Orca tool by Microsoft - https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe
I'm probably just being very thick here, but it's not clear to me where I'm supposed to install 'new' user-specific programs on Windows 7 (and presumably Vista too, though I've not specifically looked at that scenario yet).
Under Windows XP (rightly or wrongly) we always installed our programs into folders under 'Program Files' and accepted that they'd be kind-of available to everyone. From what I can gather under Windows 7 I'm supposed to install my software under the user's AppData folder (possibly AppData\Local\MyApp). That makes a degree of sense, but the fact that this folder is 'hidden' by default means that we're going to have 'fun' talking our users through support stuff.
I want to install our software so that it's user specific (the Users bit in Windows 7 makes perfect sense) but I do want the user to be able to access it if required. Our program also includes a 'data' subdirectory which it needs to write into while it's running (embedded database), but as the program is intended to be single-user/standalone, the data folder being inside a user-specific folder isn't going to be a problem.
My problem is just that whole 'hidden folder' aspect of AppData. As much as I've trawled the MSDN, I can't work out where else I'm supposed to install user-specific programs. Taken one way it would seem to be something like AppData\Local\MyApp, and another way it would seem to be just as valid under the user's My Documents\MyApp equivalent.
Has anyone got a clear guide for where all this stuff goes? I found the MSDN docs confusing. :-)
Not really.
The directory that serves as a common
repository for application-specific
data for the current roaming user.
AppData is, surprisingly, for application data, not for installation (Click Once/Silverlight applications aside). You can, and should still install into Program Files, just don't expect to write into that folder.
You can install software into AppData if you want it to follow a user about in an Active Directory environment, which happens if you put it in AppData\Roaming (the SpecialFolder.ApplicationData location).
You can also install into AppData if you want the software to be available to just the user that installs it. This can be useful if, for example, you have multiple users on the same machine, who all want to run different versions of the software in complete isolation.
If you want settings to only apply on the local machine then you use AppData\Local, which is SpecialFolders.LocalApplicationData - this will make AD administrators very happy as the roaming profile size won't suddenly jump up 50Mb or whatever the size of your software is.
If you wanted to create settings which apply to all users then you're looking at SpecialFolders.CommonApplicationData
You should remember never to rely on the actual name of the directory - localisation issues mean this can change and the location does change with OS versions two. You should be using the special folder enumeration in your software, or the equivalent in your installer.
Could you not install into Program Files, but use AppData as it's supposed to be used, and store your database in there?
Windows 7 added the FOLDERID_UserProgramFiles known folder and by default this maps to %LOCALAPPDATA%\Programs. This is used by MSI when ALLUSERS=2 & MSIINSTALLPERUSER=1.
On Vista and earlier there is no canonical per-user application folder but just using %LOCALAPPDATA% is pretty common. Sadly MSI will just use %ProgramFiles% on these systems.
It's 2019, and I just installed Visual Studio Code (a Microsoft product) in the default folder of
%userprofile%\AppData\Local\Programs\Microsoft VS Code
This is probably for getting around the requirement to have an administrator or UAC prompt authorise the installation
Windows 7 folder structure is deeply inspired on Unix structure:
/usr/ -> C:\Program Files\ -> binaries: executables and dynamically linked
/etc/ -> C:\ProgramData\ -> global settings
/home/ -> C:\Users\ -> a folder for each user
~/.* -> C:\Users\Hikari\AppData\Roaming\ -> settings for each user
Windows has more folder, like My Documents for files with content produced by user, AppData Local and Roaming (which Unix usually handles with NFS).
It's about time for us developers to start using these structures. We must separate at least binary files that don't need to be replicated, global and user settings.
When a setup is installing an app, this setup should expect to have permission to write on Program Files. Once the setup is finished, Program Files should be writable only for other setups aiming to update binaries to other versions.
Please install executable files to the %programfiles% folder in Windows - a simple MSI based install package can perform an active setup for any new user who logs onto the machine to create the user specific files and folders in their profiles %appdata% folder. You see this behaviour for Internet Explorer, Adobe reader, etc. - It's the little MSI installer window that pops up the first time you log onto a machine which has those applications installed. - Thanks - a system admin :)
My opinion, for what it's worth, is that user-specific program files is just asking for trouble and is a damn stupid thing to do.
A much more sensible approach is to install different versions of your program to:
\Program Files\Your Program\Program_v0.1\Program.exe
\Program Files\Your Program\Program_v0.2\Program.exe
\Program Files\Your Program\Program_v0.3\Program.exe
\Program Files\Your Program\Program_v0.4\Program.exe
I would then place a bootstrapping launcher at:
\Program Files\Your Program\ProgramLauncher.exe
Then, the user application data folder will only contain data, including an INI/XML/Settings file that indicates the version of the program that this user is working with.
Such an approach satisfies the core tenant of keeping data and executing code separate, allows every user to run a specific version of the code, and offers a small amount of de-duplication by ensuring the same executable code is not copied multiple times across user folders.
Otherwise, go right ahead with installing programs to AppData and undoing the years it has taken us to achieve clean separation of code and data. I found this thread because I noticed that Chromium and DropBox are installing code to AppData. I'm going to uninstall those program, and change the permissions on my AppData folder to exclude execution to ensure I can easily spot other programs attempting the same BS.
I created some custom modules and Visual Studio drops the build files directly into the Kofax Bin directory. It is important to note that I'm using the modules as Winforms applications and Windows services (at the same time). The generated files are
MyModule.exe
MyModule.exe.config
MyModule.InstallLog
MyModule.InstallState
MyModule.pdb
I think that I only need the .exe file here. Of course I also add the .aex file to the directory to install the module. I also created two batch files to register the module on the local machine
RegAscEx.exe MyModule.aex
pause
and to install the module as a Windows service
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe" "%~dp0MyModule.exe"
pause
after running them as administrator I can delete them from the directory of course. I would like to know if it should be always fine to provide the .exe file, .aex file and the two batch files (which will be deleted later) only?
Basically correct. Some thoughts:
Build your application using the Release configuration (vs Debug). See discussion here.
PDB files usually are not needed in production. Still, you may want to generate and keep them if you plan on debugging in production.
The app.config file should be kept. Maybe you want to use application settings later on, and the supportedRuntime element is useful if someone wants to run your CM on a machine without that version of .NET framework being present (Windows will show a nice error message)
Keep the AEX file. This is required if someone wants to register your CM on another machine (e.g. deploying from DEV > TEST > PROD).
Include a single batch file that allows registering your CM on a new machine as well as adding it to Kofax Capture. Here's an example:
rem "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" SmartCAP.CM.Sample.dll /codebase /tlb:SmartCAP.CM.Sample.tlb
rem RegAscSc.exe /f Register.inf
Another thing I usually include is the ability to install my CM in a similar fashion to native KC modules, for example: SmartCAP.CM.Sample.exe -install and SmartCAP.CM.Sample.exe -uninstall. Take a look at the AssemblyInstaller class for details.
I have a project that uses clickonce to generate the setup.exe. During the run time my program create some extra files like "Log" and "Attachments" inside the User Folder. However, those folders are not removed when I perform an uninstall of the clickonce application from the ARP. These remaining files are interfering the next install.
I know that click once does not support for adding custom action to install or uninstall. I am wondering if is there is a way that I can remove those extra file programmingly after performing uninstall?
One way I have tried was to create a cleanup script and added it as a bootstrapper package to pre-requisite of the click once project. That worked in a way that every time before a new product was installed, the previous dirty data had been removed. However, this messed up the upgrade case.
Any ideas on how to remove the extra files that left by clickonce uninstallation?
Thank you
JS
There is no way to do anything when uninstalling a ClickOnce application other than uninstall the ClickOnce application.
Have you considered putting the files in the ApplicationDeployment.CurrentDeployment.DataDirectory ? Then they will be removed when the application is unisntalled.
If the files are part of the project, you can set the type to Data in the Application Files dialog, and it will automatically place them in the data directory when deploying.
This solution works on multiple re-installations (clean), however it doesn't remove the data on last uninstall or until the next installation takes place.
Stil there is no custom action place on uninstall to remove the files beyond clickonce scope.
Leave a file in to ApplicationDeployment.CurrentDeployment.DataDirectory.
On startup, see if the file exists on conditions network deployed, firstrun (which resets on upgarde too).. success case, it is a first installation or upgrade. Failure case, the application is been uninstalled and installing again .. now you have a chance to clean up the application data.
If the data is sensitive, you may want to use other solution to remove files on uninstall ( as of now I don't see that Microsoft is given us an option)
I am using Installshield 2010. I made a basic MSI setup, and I am having a problem with uninstalling.
Uninstalling does not remove all folders.
After a complete install, I then uninstall only to find that there is still a path leftover.
For example, C:\ProgramFiles\CompanyName\Account\User_1234.xml
still remains, while everything else is gone.
The User_1234.xml file is generated by the application, and this file is not normally in the install process. So it makes sense why this file may have some problems getting rid of it (installer side).
At the same time, I would think that it would be removed due to the fact that it is within the CompanyName folder.
Is there any way to specify to get rid of everything inside and including the CompanyName folder?
Thanks for any ideas.
You have a couple problems and I'll address the obvious one first. Yes, Windows Installer default behavior is to not delete user data. This could be files not installed by the installer or files that were modified since the installer modified them. To get the installer to remove them, you must author the RemoveFiles table to teach it which files to remove.
Remove Files Table (Windows Installer)
Now I'll address the less obvious problem. You shouldn't expect your application to be able to write to ProgramFiles at runtime. I don't know what your software does but you should seriously consider this aspect of your application design.