A program uses a local-install approach and not a .msi installer and can't use an MSI module. If the win10 ucrt has been installed or is native, I don't want to add my own local copy. Likewise for the VS Redistributables: if the use has formally installed that previously or did so as a prior step, I want to know that, so if it has not been done, I can supply "local" versions.
The obvious idea is to try LoadLibraryEx with the default system search path. But I wonder if there is a call to ask if that's been installed properly, rather than possibly find a stray copy that happens to be on the path or whatnot.
Related
I'm building a setup executable using Visual Studio 2015 Setup Project template.
I added an external executable in the file system of my package that the user needs to install to be able to run my program. Then, I added this package as a custom action on Commit.
I want my install package to recognize if this external executable is already installed on the user computer by looking at the registry of looking at a certain folder structure on the computer (the method to check is not defined yet).
How can I set up this kind of check for the custom actions ? I've seen that there is a Condition property when clicking on the .EXE in the Custom Actions window, but all I can find about this property is that, which does not really answers my problem.
VS setups offer a registry search, and that search will set a property name that you define (in uppercase). If the registry entry exists, meaning that you don't need to run the program, then you give the custom action a condition of NOT FOUNDREGISTRY assuming FOUNDREGISTRY is the name of the property.
Having said that, if that program is a redistributable that installs something then:
They are typically smart enough to figure out if they need to do anything or not, and that includes seeing if what's already installed is an older version, so they should run anyway because it's a newer version. So it may be best to just run it anyway.
If the executable wraps a MSI-based setup then it will fail because you can't install an MSI-based setup with a custom action in a VS MSI setup.
I would like to create an installer for a library (DLL) that can be use in multiple system including MATLAB.
For MATLAB, I have additional *.m and *.mex files to make the DLL functions easily accessible from it.
I also have an installer that modify the PATH environment variable to make my DLL visible to all potential calling system.
My problem is that MATLAB does not make use of the system PATH environment variable. Thus, I am looking for a fix that would allow users of my library to run the installer and have my library accessible from MATLAB "out of the box" (possibly after a restart or session reopen).
I currently see 2 ways to do it which I both do not like :
Write a MATLAB script that uses addpath()/savepath() functions. I don't like this because :
a. MATLAB may not always be installed.
b. This would mess with the user's MATLAB's own path variable.
c. Upon installing a new version of my library, I would have to mess even more with the MATLAB's path to delete the path to older library before adding the path to the newer library.
Look through the system PATH and search for ...\MATLAB\RXXXXn\bin path to use that to install my *.m and *.mex files in the appropriate folder inside MATLAB. I don't like this because :
a. It would mess with MATLAB's own installation.
b. Once again, installation of multiple successive versions of the library may cause some issues (currently multiple version may be installed in separate directory, and the PATH redirects to the last one installed, experts users can modify the PATH according to their needs).
Currently, I am leaning towards option 2, but I am looking for a better, cleaner solution to this installation procedure.
Can anyone give me some MATLAB's expert advice ?
Thanks in advance for your help!
I have 3 driver installers (.exe). I need to wrap them up in a single installer app so that my users can run one executable which then installs the 3 drivers.
In visual studio 2010, what is the best way to do this?
EDIT: I don't want the three executables to remain on the machine once the install is finished.
What I did to solve this problem was to put my multiple exe's into a self-extracting zip file and set the PostExtractCommandLine to a separate "installer" exe, which in turn checked for requirements, installed necessary components, restarted when needed, and installed my original exe's. This does however leave behind all the files, though you can have the "installer" exe delete everything when it's done.
(I used a library called DotNetZip to make the SFX.)
Edit
I had two applications I wanted to install, App1 and App2. These were both msi setup projects and could be installed separately. I then created AppsInstaller.exe, which ran App1.msi and App2.msi by calling msiexec /i C:\\Install\\App1.msi /qn, etc, as well as doing some other work. All three programs were put into an SFX file, with AppsInstaller.exe as the PostExtractCommandLine. My AppsInstaller.exe did everything silently, so no wizards where present, and is why I used msiexec. Since you want the wizard to show you can just call the msi's as Process's and use a WaitForExit to keep it coming one at a time.
I'm writing an NSIS installer for a project that requires the PyOpenGL package, however installation of this package fails because my system doesn't contain mscvr71.dll (VS C runtime lib). According to KB326922, this library should have been packaged with PyOpenGL.
My question is, what is the safest way to correct this so I can install the PyOpenGL dep within my installer? I certainly don't want to have to drop the file into system32 during installation, and I'm not aware of any update that includes this file (other than VS itself).
EDIT:
I can't easily re-package PyOpenGL to include the missing dll. I don't have VS installed and am unsure how to rebuild the package and installer.
You can put the library in the same directory as the installer for PyOpenGL, which is first in the dll search path. mscvr71.dll is included with other applications, like the Java JRE, so you may have a safe copy to use in your Program Files directory (don't use dll's from untrusted sources).
Assuming that you have mscvr71.dll in your References, right-click on the mscvr71.dll file, select Properties, and change the Copy Local property to True.
See the py2exe tutorial, which I augmented last year to describe exactly which version of which DLL files you need for different versions of Python, where to get them from, and how to include them (especially for the tricky newer versions, which require manifest files and the like):
http://www.py2exe.org/index.cgi/Tutorial#Step5
I have a driver which can be installed on Windows (XP/Vista/7). It's accessed via a native C++ DLL that 3rd-party applications link to, and which is also a Winsock Provider (WSP). It used to be installed under System32, but having seen advice not to, I changed it to install under ProgramFiles instead.
Now, the problem is that people are having to either copy it back into System32 or copy it into the application directory whenever they want to use it in their own applications, because Windows won't search the install directory under ProgramFiles when the application tries to load the DLL.
I've been unable to find any Microsoft documentation discussing this issue, so if System32 shouldn't be used then where should shared DLLs be installed?
The Windows side-by-side cache. Backgrounder info is here, technical reference is here.
I haven't seen anybody actually do this yet, other than Microsoft. Quite notable is that MSFT gave up on winsxs deployment for the C/C++ CRT and MFC runtime DLLs for VS2010, it was causing too many problems. They're back in c:\windows\system32. The managed equivalent of this (the GAC) is going strong though. Better tool support, probably.
I'm fairly sure that by a large margin everybody chooses app-local deployment.
Since it's a DLL linked to your driver maybe it's less of an issue, but I'd be wary of trying to share the DLL and would instead try to get all developers of client apps to keep their own version of the dll in their applications folders.
I've had too much fun in DLL Hell to want any more weird bugs because AppX overwrote the DLL with an old version that breaks AppY etc.
Anywhere on the path would work.
If this is only to be used with your set of apps (eg Qt4.dll) then in the root of "c:\program files\my company" would be good, or have a 'shared' folder below that.
If it's to be used by other apps that you don't know about (eg a video codec) then system32 makes sense (you will need admin rights when you install)
Fixed filesystem location
One possibility would be to install them in a sub-directory of Program Files, as already suggested by #Martin Beckett.
Variable filesystem location, fixed entry in Registry
If you don't want to install them at a fixed location, you could also store their location in the Windows Registry. You'd install some keys under HKEY_LOCAL_MACHINE\SOFTWARE that your applications could read to find out where the DLLs are located. Then the DLLs can be loaded at run-time.
P.S.: Preventing orphaned DLLs
You could go one step further and use the Registry, or some other storage (a file, say), to store information about which of your applications uses which of your DLLs. For example:
FooCommon.dll <- FooApp1, FooApp2, FooApp3
FooBar.dll <- FooApp1, FooApp3
FooBaz.dll <- FooApp2, FooApp3
Whenever one of your applications is un-installed, it removes itself from this map. Any uninstaller can then safely delete a DLL that is no longer in use by any application. That method is akin to reference-counting, and the idea is to prevent orphaned DLLs from accumulating on users' filesystem.
Native DLLs can be stored as side-by-side assemblies. See this reference for more information. This is separate from the .NET Global Assembly Cache, but it uses similar concepts. This blog post also has quite a few useful details about how DLLs get resolved as side-by-side assemblies.