I've created a basic installer package using Installshield 2013 Premier and everything works fine with default language (English).
But when a user installs software with other than default language (say Catalan), and then uninstalls it again, not all files from ProgramFiles folder are properly removed.
If user installs with default language (English), then after uninstallation, all files from ProgramFiles folder are removed successfully.
Kindly suggest me what should I do to achieve same result irrespective of language.
Thanks in advance.
I have a similar problem with InstallShield 2013. A work-around is to delete the path entries in the registry folder: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs\
To set SHARED to No, I deleted the application files from my InstallShield and re-added them allowing the InstallShield dependency wizard to find dependencies. Now the installer uninstalls these files without the need to delete entries from the registry.
Is there a different means to set SHARED to No? For example, is there a checkbox I can uncheck for each file to set SHARED to No??
Related
I have a Windows service application written in C++ that I would like users to install as a .msi file, so I am using MSVS Installer Projects 2022. The service requires a read from a file config.cfg to setup some parameters on each start. My current implementation installs to wherever a user specifies, but C:\Program Files\<Install Dir> is the default directory. In my source code I hardcoded that directory to get to the configuration file, i.e. C:\Program Files\<Install Dir>\config.cfg which is obviously not very portable, but it has allowed me to do some testing.
I would love to link the file relatively to the executable, but Windows Service applications set the working directory to System32, so doing something like loadFile("config.cfg") would expand to loadFile("C:\Windows\System32\config.cfg"). Installer Projects does allow me to drop the config file there or any sub-folder, but this seems unideal. What is a good way of going about referencing the configuration file in source? Some things to consider:
%appdata% of the installer and %appdata% of the service are completely different.
Installer allows for setting registry values, but setting a string PATH directing to the installation folder does not seem possible.
My application is hosting a server using a class that requires the config file.
Any help is appreciated.
I'm working on a solution (C#) with 3 projects in it (one library and two applications) and I wonder what is the bare minimum of files you need to commit to be able to pull off a fresh solution and get it to work right away?
Obviously all source files, *.sln, *.csproj are needed and not the obj folder or bin folder (unless I want to keep a working copy of the compiled files).
But do I need to commit the:
Properties folder
.vs folder
*.resx
*.config
I have Googled it but all I found was a list of the file types, but no explanation of what files where critical to make the solution/project load and compile.
[EDIT]
It has been suggested that this is the same question as: Should I add the Visual Studio 2015 .vs folder to source control?
The question is not related to only the .vs folder, but to all project/solution files.
Though SVN and Git are different Version Control System, I think the files that should be excluded in the Version Control System should be similar. This file is a ignore file for Git (an .gitignore), but should be work as it should in SVN Version Control Systems.
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
This file is often used in various places like Github Destktop, or the Github Site itself.
How do I go about to make Visual Studio add a folder from my project into the build directory (for example \x64\Release)? I have a folder for images that I want to be included when I build my application so that they can easily be accessed in relation to the executable's location. The problem with doing it manually is that I have to copy it over manually for both my debug and release folders instead of keeping it all compact withing my project. It also helps with uploading to github.
So is there any way to do this? And if so, how?
I have a standard windows forms application that is being deployed using the VS2017 setup project. When opening the setup project using the "File System", I added to the application folder the following:
Primary output from the win forms app.
The EPPlus library's dll.
Some excel files.
The setup project gives the output .msi package just fine. The problem is, when I run the .msi output after building the setup project (of course after building the source project) and run the application, I do not see my updates, even the files on C:\Program Files .... directory are not modified. I tried changing the product code and the increasing the version and it does not work. My questions are:
Besides removing and installing the program again, is there anyway to make the installer package actually updating the software's installation?
How to avoid the problem in #1 no matter how much I update the software?
What is the cause and how to avoid this error "Another version of this product is already installed"? I'm not sure of what I did for it to pop up.
If I want some part of the source code to be in a separate dll, is it as simple as adding a class library project and adding its output to the setup project?
Thank you very much.
The way you do the upgrade is to use the RemovePreviousVersions project setting. The steps are:
Increment the setup project's version and accept the changes, this will include a change of ProductCode.
Make sure that RemovePreviousVersions is set true.
The UpgradeCode (setup project properties) needs to be the same so don't change it.
Increment the file versions of the binaries that need updating (that's the standard rule about updating versioned binaries).
The resulting MSI will do a major upgrade (in Windows Installer terminology) and upgrade the older version, replacing it with your new product MSI. Note that an upgrade will work only with the same context of install. An Everyone will not upgrade a Just me, so that will result in two entries in Programs and Features. Doing the install creating a verbose log and searching foe FindRelatedProducts entries will tell you if it found the upgrade or not. msiexec /I [path to msi file] /l*vx [path to a text log file]
There's a longer explanation here:
https://www.red-gate.com/simple-talk/dotnet/visual-studio/updates-to-setup-projects/?_ga=2.138201520.1662048302.1514485579-1682631157.1514485579
which is old but relevant. and doesn't mention the requirement to update binary file versions (it wasn't needed with early VS setup projects).
I am using VC++ with multiple projects that require a 3rd party library. As developers may have this library in different paths, each developer sets the local machine/user's Microsoft.Cpp.Win32.user property sheet with the appropriate paths.
Now we using a new version of the 3rd party library with some of the projects. As before, different developers may have the new library in different paths. How do we set local machine and project specific paths so that we can compile both old and new library projects?
Modifying a project's 'VC++ Directories' changes the project file (.vcxproj) which then poses a problem as we do not want to commit local settings into the repo.
We normally set an environment variable for each library that can be set by each developer in their environment in a env.bat file they run before running devenv (some made up examples) :-
ZLIB_ROOT=c:\somewhere\thirdparty\zlib
BOOST_ROOT=c:\somewhere\thirdparty\boost\version_123
and then in the project files add directories use "$(ZLIB_ROOT)/Include" or "$(ZLIB_ROOT)/Lib/x86" (all made up examples again...)
That way they will resolve correctly for any developer and they can have a different env.bat script for each version