How to install Microsoft Access Runtime 2013 32-Bit Silently? - wix

I am trying to install Microsoft Access Runtime 2013 32-Bit silently using quiet property, but still it is showing the Installation UI window and asking to accept EULA. Earlier I was using Access Database Engine 2007 which was getting installed silently with quiet command. What am I missing? I am using below code to install it silently:
<ExePackage DisplayName="Microsoft Access Runtime 2013"
SourceFile="..\Prerequisites\Microsoft Access x86 Runtime 2013\AccessRuntime_x86_en-us.exe"
InstallCommand="/quiet"
InstallCondition="NOT ACCESS_ENGINE=5"
Permanent="yes"
Compressed ="yes"
/>

Please read the following tips from itninja.com (formerly appdeploy.com):
https://www.itninja.com/software/microsoft/access-runtime/2013-14
https://www.itninja.com/question/packaging-access-runtime-2013
Essentially:
Extract files using AccessRuntime_x86_en-us.exe /extract:ExtractedFiles.
Create a config.xml as described in the links above. Let me just duplicate it here in case the links go dead. And obviously update the paths for your purpose and for your environment:
<Configuration Product="AccessRT">
<Display Level="None" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
<Logging Type="standard" Path="C:\Windows\Temp\" Template="Microsoft_Access_2013_Runtime_Setup(*).log" />
<COMPANYNAME Value="Company Name" />
<Setting Id="SETUP_REBOOT" Value="Never" />
</Configuration>
Install with setup.exe /config config.xml.

Related

ExePackage RemotePayload hash value issue

I have implemented prerequisites using ExePackage with RemotePayload because I need to download package using runtime webinstaller (DownloadURL). But in that when package is upgraded after sometime like quarterly update that time package version and hash value is also changed. So, I get error like 0x80091007 (Hash value is not correct). So, please help me if anyone have idea about how to ignore hash value check. Below is code which I have implemented:
<ExePackage
Id="MicrosoftEdgeWebview2"
DisplayName="Microsoft Edge Webview2 Runtime"
Compressed="no"
Cache="no"
PerMachine="yes"
Vital ="yes"
Permanent ="yes"
InstallSize="1"
InstallCommand="/silent /install"
DetectCondition="MicrosoftEdgeWebview2Version >= $(var.MicrosoftEdgeWebview2MinimumVersion) OR MicrosoftEdgeWebview2Version64 >= $(var.MicrosoftEdgeWebview2MinimumVersion)"
Name="MicrosoftEdgeWebview2Setup.exe"
DownloadUrl="https://go.microsoft.com/fwlink/p/?LinkId=2124703">
<RemotePayload
ProductName="Microsoft Edge Webview2 Runtime"
Description="Microsoft Edge Webview2 Runtime Setup"
Hash="080e3e4cdcfc809762a32e8fa7cdc0f37b8e36a5"
Size="1778968" Version="1.3.153.47" />
For security reasons, the Burn engine will always verify the payload. To avoid hash validation, you have to specify certificate information in the RemotePayload so it validates the digital signature instead. You should use heat.exe payload ... to harvest this information.
"%WIX%\bin\heat.exe" payload windowsdesktop-runtime-5.0.5-win-x64.exe -o windowsdesktop-runtime-5.0.5-win-x64.exe.wxs
<RemotePayload
CertificatePublicKey="F49F9B33E25E33CCA0BFB15A62B7C29FFAB3880B"
CertificateThumbprint="ABDCA79AF9DD48A0EA702AD45260B3C03093FB4B"
Description="Microsoft Windows Desktop Runtime - 5.0.5 (x64)"
Hash="9CE1E77FE51E3F104D1DF7670F83F12B8ABF82F6"
ProductName="Microsoft Windows Desktop Runtime - 5.0.5 (x64)"
Size="54977944"
Version="5.0.5.29917"
/>

Remove component with in next update in WiX

I have a service component installed twice in one of my previous releases.
<Component Id="MyServiceWin7" Guid="{GUID_WIN7}">
<File Id="mysvc_Win7"
Name="mysvc.exe"
Source=mysvc.exe"
KeyPath = "yes"/>
<ServiceControl Id="MYSVC_Win7"
Name="MYSVC"
Remove="uninstall"
Start="install"
Stop="both"
Wait="no" />
<ServiceInstall Id="My_Svc_Win7"
Name="MYSVC"
DisplayName="MYSVC"
Type="ownProcess"
Start="auto"
ErrorControl="normal"
LoadOrderGroup=""
Description="My service">
</component>
<Component Id="MyServiceWin8" Guid="{GUID_WIN8}">
<File Id="mysvc_Win8"
Name="mysvc.exe"
Source=mysvc.exe"
KeyPath = "yes"/>
<ServiceControl Id="MYSVC_Win8"
Name="MYSVC"
Remove="uninstall"
Start="install"
Stop="both"
Wait="no" />
<ServiceInstall Id="My_Svc_Win8"
Name="MYSVC"
DisplayName="MYSVC"
Type="ownProcess"
Start="auto"
ErrorControl="normal"
LoadOrderGroup=""
Description="My service">
</component>
So there will be two instances of the MYSVC component. Both are mapping to MYSVC.exe.
I missed the OS version condition check in the previous release.
It runs successfully.
I am thinking to delete the dummy additional COMPONENT (GUID_Win7 or GUID_WIN8) in the next update.
How I can delete it, do I need to write a custom action?
Any help would be appreciated.
EDIT::
Please find answers,
mysvc is having some third party lib dependancy os specific Win7 and Win8, it works means it installed successfully if we check sc qc mysvc I get service created and mysvc.exe is mapped to service binpath
yes these two service components targets same destinationand there is only one component when I do sc query mysvc
No there only one entry of service. mysvc.exe is win8 version on disk.
Thanks for suggestions, that breaking link.
Currently I have %ProgramFiles%\MyApp\mysvc.exe common path for both win 7 and win8.
So my question if create new common path to break previous link.
ProgramFiles%\MyApp\mysvc\mysvc.exe [[NEW_GUID1]] for win7
ProgramFiles%\MyApp\mysvc\mysvc.exe [[NEW_GUID2]] for win8
Components with [[OLD_GUID1]] , [[OLD_GUID2]] will be on system forever
until my product is uninstalled, so cant we just delete components with [[OLD_GUID1]], [[OLD_GUID2]] to clean stale(non functional) components
Thanks
Some Questions:
First of all, can we ask why you decided to install the service in two flavors? Does this mean that the service has different binaries for Win7 and Win8? If so, then it is unclear why you say it works as it stands.
Do these service components target two different installation locations so they both run side-by-side, or do you target the same target destination with both components? (so there is only one instance of the file after installation).
Are there two entries in the list of services on the box after installation? If you target the same location with both components, what file version of mysvc.exe made it onto the disk? (if they are different).
I wrote the below before the above questions. Please update your question with the answers to the questions. The below might be irrellevant - we need more information.
Sins of The Past: If you have installed the same file twice with two different component GUIDs in the previous version then this is wrong and I would recommend you "break the link" to the sins of the past by setting two new component GUIDs for the new release and crucially: set a new absolute installation location for each component (do not target the same absolute key path with two different GUIDs! - conditions or not).
The idea is to de-couple the old and new versions so that you start with a clean(er) slate.
Something like:
Comp 1: {77777777-7777-7777-7777-777777777777}, [ProgramFilesFolder]My App\Win7\mysvc.exe
Comp 2: {42424242-4242-4242-4242-424242424242}, [ProgramFilesFolder]My App\Win8\mysvc.exe
Personally I would avoid the Windows version number and maybe use something else. How about a year?
Comp 1: {77777777-7777-7777-7777-777777777777}, [ProgramFilesFolder]My App\2007\mysvc.exe
Comp 2: {42424242-4242-4242-4242-424242424242}, [ProgramFilesFolder]My App\2014\mysvc.exe
Just to not hard code a misleading value if the Win8 version runs on Win10 for example.
N.B!: Note that the above, sample GUIDs are well-known and dysfunctional GUIDs and
should not be copied and used! This is of high cruciality :-).

Microsoft.AspNetCore.All 2.1.1

I have a Web Api application targeting NET Core 2.1. When I upgrade the Microsoft.AspNetCore.All nuget package to v2.1.1, the application stops running.
My dotnet:
$ dotnet --version
2.1.300
In my Windows Application event viewer, I first see this warning:
The directory specified for caching compressed content C:\inetpub\temp\IIS Temporary Compressed Files\myproj.Logs.HostedApi AppPool is invalid. Static compression is being disabled.
And then I have two of this error:
Log Name: Application
Source: IIS Express AspNetCore Module
Date: 6/21/2018 4:15:11 PM
Event ID: 1000
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: CarbonVic
Description:
Application 'MACHINE/WEBROOT/APPHOST/MYPROJ.LOGS.HOSTEDAPI' with physical root 'C:\myproj\Code\myproj-moonshot\apps\myproj.Logs\myproj.Logs.HostedApi\' failed to start process with commandline 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\VSIISExeLauncher.exe -argFile "C:\Users\me\AppData\Local\Temp\tmp27D2.tmp"', ErrorCode = '0x80004005 : 0.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="IIS Express AspNetCore Module" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-06-21T20:15:11.470607900Z" />
<EventRecordID>9844</EventRecordID>
<Channel>Application</Channel>
<Computer>machinename</Computer>
<Security />
</System>
<EventData>
<Data>Application 'MACHINE/WEBROOT/APPHOST/myproj.LOGS.HOSTEDAPI' with physical root 'C:\myproj\Code\myproj-moonshot\apps\myproj.Logs\myproj.Logs.HostedApi\' failed to start process with commandline 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\VSIISExeLauncher.exe -argFile "C:\Users\me\AppData\Local\Temp\tmp27D2.tmp"', ErrorCode = '0x80004005 : 0.</Data>
</EventData>
</Event>
Every machine in my shop has this issue. We had to revert back to Microsoft.AspNetCore.All v2.0.8 to make it work again.
Funny thing is: there is no c:\inetpub on any of our machines and there never has been.
Also, I tried to run it on both IISExpress and self-hosted; it will not start with either profile.
Am I missing something here? Anyone know if there's a fix for this?
Help is appreciated always.
V
Well, the good news is that .NET Core 2.1.1 is released now, so you can go and install the new SDK version (2.1.301) from https://dot.net. :)
Now about the issue you had: The meta packages work by referencing the shared framework, which gets installed by the SDK. Since the SDK for 2.1.1 was not installed (2.1.301) your application blew up.
You also mentioned that in the NuGet window the updated packages where already visible. That's true. The individual packages were already released. They just couldn't be resolved because the Microsoft.AspNetCore.All metapackage version 2.1.1 wasn't installed.
On a sidenote: It's recommended to target Microsoft.AspNetCore.App instead of .All . Also the version number can be inferred from the SDK, so you can remove that too.
See: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/metapackage?view=aspnetcore-2.1#migrate
The 2.1.1 release is still in progress. You should use the 2.1.0 packages until it's complete: https://twitter.com/DamianEdwards/status/1009873842662043648.

How to Create a Patch in WiX with the different product codes

I use Purely WiX approach to making patches and am trying to make a single MSP work for 2 different MSI's.
I have v1.1 MSI and v1.2 MSI, and plan to create an MSP using v1.2 MSI, so that the MSP can be used for both v1.1 and v1.2.
I set Validate/#ProductId='no' as its description says:
Requires that the installed ProductCode match the target ProductCode
used to create the transform. The default is 'yes'.
However, it only works for v1.2. So far, the only way I was able to work was to add 2 TargetProductCode/#Id as below.
Is this a bug for Validate/#ProductId? Or Is that the right way to do?
<Media Id="5000" Cabinet="RTM.cab" >
<PatchBaseline Id="RTM" >
<Validate ProductId='no' ProductLanguage='no' ProductVersion="Update" ProductVersionOperator='LesserOrEqual' UpgradeCode='no' />
</PatchBaseline>
</Media>
<!-- Why do I need this when Validate/#ProductId='no'? -->
<TargetProductCodes Replace='no'>
<TargetProductCode Id='{xxx}' />
<TargetProductCode Id='{xxx}' />
</TargetProductCodes>
<PatchFamilyRef Id="myRollup"/>
There is a same question but both didn't work.
I had the same issue, the Validate/#ProductId='no' doesn't seem to do much for me, unless I'm doing something wrong.
What I've found is you need to keep the ProductId the same for each update, and only change it for a major version upgrade (at which point there is no MSP to go from v1.x to v2.0, it's an upgrade install via an MSI).
Then you can build the MSP based on v1.0 and set ProductVersionOperator to GreaterOrEqual, or build it based on v1.1 and set it to LesserOrEqual, and the MSP's will work on any v1.x MSI.

How to check an installed version of a product from MSI

After review a lot of posts in this site finally I decide to put mine.
I am preparing an MSI file with Wix.
I need to check if a particular version of an enterprise product is installed, before to install my system. I have the GUID of that product (which is the same for all versions), but I need to check if 1.10.0 version is installed.
Any idea, please.
Thanks in advance.
PD: I am newbie in Wix, so at this moment I am just using the wxs file created by default with the Setup Project.
Clarifying: I don't want to upgrade the software that I am installing, I need to check another program and version which my installer depends.
To do it properly, you probably want to use a custom action. Inside the custom action, use the MsiGetProductInfo function.
A way of doing it in pure-WiX would be to modify the example found here: How do I compare registry versions in WiX?
First create a RegistrySearch element:
<Property Id="PRODUCTVERSION">
<RegistrySearch Id="ProductVersionSearch" Root="HKLM" Key="software\Microsoft\Windows\Current Version\Uninstall\[PRODUCTCODE]" Name="DisplayVersion" Type="raw" />
</Property>
Then use a Condition element:
<Condition Message="Product version 1.10.0 must be installed">
<![CDATA[PRODUCTVERSION AND PRODUCTVERSION = "1.10.0"]]>
</Condition>
This would search for exactly version 1.10.0, so may not be what you want if you're looking for something like "v1.10.0 or newer"... But should get you started.
Perhaps try the proposed solution in this post: WiX Installer: getting version of the product being upgraded
It involves using the Upgrade table to identify the installed product, and a custom action using VBScript to determine the version.
If you want to do something like create an error message or fail the install if that version is present you can have multiple upgrade entries. Have one that has something like this, bad syntax...
<Property Id="VERSION110INSTALLED" Secure="yes" />
<Upgrade Id="YOUR_GUID">
<UpgradeVersion
Minimum="1.10.0" Maximum="1.10.0"
Property="VERSION110SINSTALLED"
IncludeMinimum="yes" IncludeMaximum="yes" OnlyDetect="yes" />
</Upgrade>
Then you have that property set if version 1.10.0 is present, and if you want to produce an error message condition it on VERSION110SINSTALLED, and sequence it after FindRelatedProducts.