I manage an application that requires Microsoft Visual C++ Redistributable (x86) version 14.25.x or higher. The server I'm testing on has version 14.34.31931 and I can find that in PowerShell with:
$Key = Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\VC,redist.x86,x86,14.34,bundle'
$Key.Version
I'm wondering, instead of having "VC,redist.x86,x86,14.34,bundle" in that last spot of the Get-ItemProperty, if I can search for something containing "VC,redist.x86" and use that key, regardless of the version? I know if I get that, I can compare the actual version number, but it seems with my current search, I can only search based on already knowing that it's version 14.34.x.
Related
What will happen if we try to install a software using powershell which has already installed in a server . For an example I already have notepad++ in my server, Now I try to install same notepad++ version in my server using powershell. Then what will be the output?. Besides, Is there a way that I could find whether a software has already installed in server or not.
There are many kinds of installers, but most add records in the Add / Remove list of programs, but there are no guarantees. Here is C++ code to scan the registry and check via WMI. You can use scripts instead of course, but it is not an exact science to find what is installed - some installers are very custom and non-standard and follow few guidelines.
Registry Entries:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
MSI Packages:
For MSI packages there are ways to check whether the exact same version or a related version is installed. If you have the product code of the MSI, you can simply check whether it is installed like this:
Dim installer : Set installer = CreateObject("WindowsInstaller.Installer")
MsgBox installer.ProductState("{00000000-0000-0000-0000-000000000001}") ' <= PRODUCT CODE
Longer sample linked here.
You can find the product code for an installed MSI using several approaches: How can I find the product GUID of an installed MSI setup?
If you have the upgrade code for a family of MSIs you can use the RelatedProducts method to find out whether a related product is installed:
Set installer = CreateObject("WindowsInstaller.Installer")
Set upgrades = installer.RelatedProducts("{UPGRADE-CODE-GUID-HERE}")
For Each u In upgrades
MsgBox u, vbOKOnly, "Product Code: "
Next
How can I find the Upgrade Code for an installed MSI file?. You can get the upgrade code for an MSI due to be installed by looking in the Property table using Orca.
Pragmatic Approaches:
One option is to identify a key file from each installation and check for its existence using any language you want - scripting will do.
Set fso = CreateObject("Scripting.FileSystemObject")
MsgBox fso.GetFileVersion("C:\Windows\System32\vcruntime140.dll")
The above script snippet from this rant on how to find the installed VCRedist version.
Link:
Adding entries to MSI UpgradeTable to remove related products
I am writing a perl script to check if the Visual C++ Redistributable 2010 x64 is installed in the system already.
I came across two ways according to https://blogs.msdn.microsoft.com/astebner/2010/05/05/mailbag-how-to-detect-the-presence-of-the-visual-c-2010-redistributable-package/
To read the registry for the corresponding entry.
or to use MsiQueryProductStateA
Using Win32::TieRegistry is not a possible option with out per setup.
but using use Win32::API is an option
Trying to use MsiQueryProductStateA with Win32::API
use Win32::API;
$function = Win32::API::More->Import(
'msi', 'INSTALLSTATE MsiQueryProductStateA(LPCSTR szProduct)'
);
Supposed to get some valid return value but getting error
Win32::API::parse_prototype: WARNING unknown output parameter type 'INSTALLSTATE' at C:\Program Files\HP\HP BTO Software\nonOV\Perl\a\lib/5.26.2/MSWin32-x64-multi-thread/Win32/API.pm line 600. 4294967294
Could someone please shed some light on how to use/ import the return type as well and how to use this ?
Thanks in advance
Show how to implement in C++ (not in perl) you can refer to.
I installed Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019.
Return value 5 indicate "The product is installed for the current user."
Find the product code in registry like this:
HKEY_CLASSES_ROOT\Installer\Dependencies\Microsoft.VS.VC_RuntimeAdditionalVSU_x86,v14
I'm trying to build a script that installs Mimecast for Outlook depending on which version of Outlook is installed (32-bit or 64-bit.) but I'm not really sure how to go about this.
Initially, I tried having it check if Outlook was installed in Program Files(x86) using a specific path, and if it was, install the 32-bit version (if it wasn't it would install the 64-bit version). This worked on one machine, but I couldn't get it to work on others cause Outlook was installed in a different location. What are some other ways of figuring out if Outlook is 32-bit or 64-bit?
Check the Bitness value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\<ver>\Outlook key (where <ver> is the Outlook version, e.g. 16.0).
If the value is missing, it is 32 bit.
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
I was troubleshooting an issue on a customer's workstation and found that, to my surprise, adodb.dll was nowhere to be found on the customer's workstation.
Typically, I see the file in C:\Program Files\Microsoft.NET\Primary Interop Assemblies folder.
Is this file distributed with the .NET framework or not?
Judging by MSDN, that file is written during a Visual Studio install.
Note Visual Studio.NET provides a Primary Interop Assembly (PIA) for ADO in the "Program Files\Microsoft.NET\Primary Interop Assemblies" directory in the file adodb.dll. If you have a copy of Visual Studio.NET installed, it is recommended that you use this file (adodb.dll) as opposed to importing your own using the Type Library Importer (tlbimp.exe).
I have this file on computers with VS installed, and don't have it on computers without VS installed. It looks like it should be pretty easy to generate your own with TlbImp.