X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Repackaging Runtime W/sp2 And Config.xml, Access 2010    
post Jan 31 2019, 05:50 PM

Posts: 7
Joined: 2-January 19

Greetings !

I am building an installer (Installshield Basic MSI) for the new version of our vertical market app which is built in Access 2010.

I have 2 issues:
1. Since we are deploying the UI as an ACCDE file, I need to also deploy the Access 2010 Runtime SP2.
Without SP2 of the runtime being installed, I get the "The expression you entered has a function name that Microsoft Access can't find" error.

I've configured my Installshield Project with a PreRequisite that runs AccessRuntime.exe (this is the 32 bit version)

I could create another PreRequisite with SP2 that runs after AccessRuntime.exe, but I think it would be slicker to patch the original runtime with the SP2 updates.
Has anyone done this ?

2. I'd like to use a config.xml file to perform the runtime's "activation" silently and hide everything but the progress bar.
I have found multiple sources on how to create this file and what to put in it to change various behaviors, but nothing about how to repackage the files with config.xml back into the AccessRuntime.exe

Googling these issues hasn't yielded much. I'm hoping someone in this forum has done this and could provide some pointers.

Thank you in advance !
Go to the top of the page
post Jan 31 2019, 08:15 PM

UtterAccess VIP
Posts: 2,954
Joined: 12-April 07
From: Edmonton, Alberta Canada

Ok, I “think” what you want here is how to include the SP2 update in your install. This is usually called “slipstreaming”.

In a nut shell, you simply have to un-pack the 2010 runtime.

While you never install the runtime on your dev computer, take a copy of the 2010 runtime, and un-pack it to a folder.

From the command prompt:
AccessRuntime.exe /extract:myruntime

Ok, the above will output to a folder called runtime. (just do a cd from the command prompt to the a test folder in which you placed the Access runtime.

The above folder (myruntime) now has this:

Directory of C:\runtimetest\myruntime

2019-01-31  05:42 PM    <DIR>          .
2019-01-31  05:42 PM    <DIR>          ..
2019-01-31  05:42 PM    <DIR>          AccessRT.en-us
2019-01-31  05:42 PM    <DIR>          AccessRT.WW
2010-03-11  10:48 PM               175 autorun.inf
2019-01-31  05:42 PM    <DIR>          Catalog
2019-01-31  05:42 PM    <DIR>          Office.en-us
2019-01-31  05:42 PM    <DIR>          Office64.en-us
2010-03-25  11:51 AM             1,941 README.HTM
2010-03-11  12:29 PM         1,100,664 setup.exe
2019-01-31  05:42 PM    <DIR>          Updates
               3 File(s)      1,102,780 bytes
               8 Dir(s)  100,948,955,136 bytes free

In above, note the folder updates. That is where you can toss in a copy of the sp2 update.

Note the folder called updates.

Into that folder, you want to place a copy of the sp2 update, but you again have to extract the update.

So, in our working folder, we can go:

accessrtsp2010-kb2687444-runtime.exe /extract:myupdate

This will produce a folder with the SP updates. It don’t really matter, but the contents look like this:

Directory of C:\runtimetest\myupdate

2019-01-31  05:52 PM    <DIR>          .
2019-01-31  05:52 PM    <DIR>          ..
2013-06-27  10:49 AM         1,534,464 accessrtmui-en-us.msp
2013-06-27  10:49 AM             2,160 accessrtmui-en-us.xml
2013-06-27  10:48 AM        70,189,568 accessrtww-x-none.msp
2013-06-27  10:48 AM             7,424 accessrtww-x-none.xml
2013-06-27  10:49 AM         3,651,584 clientshared64mui-en-us.msp
2013-06-27  10:49 AM             3,104 clientshared64mui-en-us.xml
2013-06-27  10:49 AM        15,785,984 clientshared64ww-x-none.msp
2013-06-27  10:49 AM             3,379 clientshared64ww-x-none.xml
2013-06-27  10:49 AM         6,578,688 clientsharedmui-en-us.msp
2013-06-27  10:49 AM             6,158 clientsharedmui-en-us.xml
2011-02-01  06:33 AM             1,202 eula.txt
              11 File(s)     97,763,715 bytes
               2 Dir(s)  100,757,315,584 bytes free

Now, simple select all files in above, and move (paste) them into the updates folder you see in the runtime.

At this point, if you were to run the setup.exe in the runtime folder, it will install access runtime, and then apply + automatic install the sp2 update.

I suppose you could just daisy chain in the 2nd setup.exe in your installer package, but it certainly a lot easier to simply include the update in the above folder.

To install, you simply package up the resulting runtime folder. (and it not going to be a msi anymore). So pull in the folders + sub folders into your installer. Unpack (place) them on the target computer with your installer, and fire off the setup.exe.

You want to launch the setup.exe in silent mode, but of course show the progress bar.

Your command line will thus be:

Setup.exe /config config.xml

In addition to the above, note the config.xml file. This lets you skip the EULA.

That xml looks like:

<Configuration Product="AccessRT">
<Display Level="Basic" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
<COMPANYNAME Value="MyCoolSoftwre" />
<Setting Id="SETUP_REBOOT" Value="NEVER" />

You can also add I /q to the setup (or is it /b - sorry I can't remember). However, with the above xml it is not required. There also a registry edit you can add that will eliminate the final office update panel (in which you can chosoe to not get updates).

I use Inno setup. As noted, you could dump all of the above, and simply launch the access runtime msi, and then launch the sp2 udpate msi, but that will cause some “messy” prompting of the user.

So my installer simply writes out the above folder to a local drive and then launches the setup.exe.

However, because customers near ALWAYS have a server folder of which to install software from, I in fact simply place the whole above folder “as is” in a folder (one above my installer routines), and have my installer reference and FIRE off a copy of setup.exe.

However, my software FIRST checks if the runtime already been installed, and skips that part.

In addition, I also set the install folder where the accDE front end goes as trusted. I use this in Inno:

Root: HKCU; Subkey: "Software\Microsoft\Office\14.0\Access\Security"; ValueType: dword; ValueName: "VBAWarnings"; ValueData: "1"                                              ; Check: HasAccess2010()
Root: HKCU; Subkey: "Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ControlMIS"; ValueType: String; ValueName: "(Default)"; ValueData: ""                ; Check: HasAccess2010()
Root: HKCU; Subkey: "Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ControlMIS"; ValueType: dword; ValueName: "AllowSubfolders"; ValueData: "1"             ; Check: HasAccess2010()
Root: HKCU; Subkey: "Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ControlMIS"; ValueType: string; ValueName: "Date"; ValueData: "12/17/2012 1:31 PM"      ; Check: HasAccess2010()
Root: HKCU; Subkey: "Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ControlMIS"; ValueType: string; ValueName: "Description"; ValueData: "12/17/2012 1:31 PM"; Check: HasAccess2010()
Root: HKCU; Subkey: "Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ControlMIS"; ValueType: string; ValueName: "Path"; ValueData: "c:\ControlMIS\"          ; Check: HasAccess2010()

You using a different installer, but the above is the basic outline of what you need to get a single setup.exe install of the runtime. The above reg is from Inno, and I have some routines to check if 2010, 2013, or 2016 is installed.

So I quite much suggest that you do NOT chain in the two msi installs (runtime + sp update), because you cannot control the prompts (a silent install), and you have two sets of install prompts if you simply chain in the two msi installs.

By un-packing the msi into the above folders, then you let your installer simply include all fo the above. You thus un-pack to some folder on the target computer. I suppose your installer should delete the folders, but as noted, I actually place the above folder on the server (one folder up) from where my installer is to setup the front end. As noted, the front end checks if the runtime is installed. The beausy of this approach is that:

I can use the same installer to update the front end.

The size of the installer is very small. It does not include the runtime.

And as noted, in 99% of company locations, we have a folder on the server. (so if you want, you can build + setup a server folder installer that installs your font end install on the server with the above runtime folders also included.

Albert D. Kallal (Access MVP, 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
post Feb 7 2019, 05:54 PM

Posts: 7
Joined: 2-January 19

Thank you, Albert !

Following your instructions, I was able to successfully have the Access 2010 RT install SP2 from it's Setup.exe execution.
I'm still struggling with:
1) Repacking the Access 2010 RT w/SP2 back into a single Setup.exe
It should be a simple thing to accomplish but Installshield is famous for making simple things complex.
The default way Installshield configures a Basic MSI project is to "install" a program. That means if I create a Basic MSI installation for the Access RT, it will make the Access RT installer itself the thing that gets installed, rather than the Access RT.
I have paid support for Installshield, so I'll be calling them about that.

2) Eliminating all the activation prompts.
I have a Config.XML in the same directory as the Access RT Setup.exe

<Configuration Product="AccessRT">
<Display Level="Basic" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
<COMPANYNAME Value="My Company" />
<Setting Id="AUTO_ACTIVATE" Value="1"/>
<Setting Id="SETUP_REBOOT" Value="NEVER" />


I add the following registry keys during my App's install:


but I'm still getting prompts.

Go to the top of the page

Custom Search

RSSSearch   Top   Lo-Fi    19th February 2020 - 06:48 AM