I've created a split Access database application and used the packaging wizard to create a deployment package. All the files are installed by the deployment package into C:\Documemts and Settings\All Users\Application Data\Provision Manager, this is too avoid Windows Vista not allowing write access to the Program Files directory.
The application installs OK on both Vista and XP and creates a Provision Manager entry in the Program Group in the user account that installed the application, however when I login using another account (both Admin and non-admin ones) the there is no Provision Manager item listed in the Program Group.
Can anyone enlighten me as to what is going on here and more importantly how I can ensure that the deployment package creates a Program Group item for each user account.
Thanks
Marc
To ENSURE that the package has created the right Program Group, look in All Users/Start Menu/Programs because these programs are automatically placed in every user's Start Menu when they log in. Similar for Desktop shortcuts, place them in All Users/Desktop
The fundamental problem (and it's not really a problem but a feature) is that MS tightened up security in Windows Vista. Users are no longer allowed to update the All Users Start Menu/Programs or Application Data folder. Only administrators can update such as using instllers. Now that's mostly fine for the shortcuts to Access FEs. The real problem arises with the FE MDB/MDEs as users pretty much have to have read/write/create/delete (although strictly speaking create/delete privilieges are only required for LDB files.) So those can't be installed into the All Users folders.
The solution is to split the runtime install into two components. The administrator types install the actual Access runtime into Program Files along with msaccess.exe , etc, etc.
Then you have a second install with the users can run which puts the Access FE MDB/MDE, and other files in the Current Users Applications Data folder along with shortcuts on the desktop.
If the users are on your local LAN you could use the free Auto FE Updater utility to handle the FE installation for users.
If the users are remote then you can use the Sample inno script which checks to see if a version of Access is installed. If not it tells you to install a runtime version of Access. If installed then it continues to install your FE MDE and other assorted files.
http://groups.google.com/group/microsoft.public.access/msg/10e3fc9234660872?hl=en
Sample inno script which "wraps" the package wizard install into a single .exe
Deploying updates to your software in a Runtime environment for Access 2007
Related
At work, we often create access applications to perform imports from certain files to the database.
We always create those mde files in access 2003.
Normally, people who run these applications have a full office (with access) installed and are able to run the .mde files.
For a new application we have a user that has an office 2010 installed, without access.
So we installed an access runtime version on their PC's so they would be able to open and use our mde file. Although we keep getting the "there is no object in this control" when we open the .mde file with the access RT version.
Anyone has an idea what is causing this issue ?
Kind regards,
When you build a runtime package you have to make sure all dll and other references are included so they get installed on the users machine. I would guess you are missing one of them. Do you know where to view references? If not make sure to open the VBE and look under tools/references. Remove any that aren't used. Then make sure any that are used are in your runtime package.
We fixed it by removing a Progress bar from the application. The libraries were not included in the runtime version neither by default in Windows. After removing it, the application ran perfectly fine on the RT editions of Access.
I've written an app which uses OLE DB, and I've encountered the error from the title. I've installed the Access Database Engine as suggested in this question and all had become work well. However, I want to distribute the app among some users to their locale machines and I have been reported such a error from the testers which do not have this util installed.
Is there any way to embed the Access Database Engine into my binary as dll or, maybe, into installer? I do not want to say "to use my app, install that util please"
if your end-user computer does not have MS office or MS Access installed, you won't be able to use the ACE.OLEDB driver UNLESS you install the basic access runtime/databse engine. However, if your end-users have 64bit windows and 32bit office, you will get the same error. To over come this issue you need to change your app target platform to x86.
if you are using visual studio, on additional way would be to add "AccessDatabaseEngine.exe" as one of your prerequisite which will be then installed along with your software.
more about custom bootstrapper:
http://msdn.microsoft.com/en-us/library/ms165429.aspx
We have a Windows 8 Modern / Metro app that we wish to deploy outside the store. I have read a bunch of materials on getting a side loading license to allow this. However, we need to go beyond just copying the app over and running some PowerShell commands, we also need to install a particular hardware driver and make some registry keys.
Can anyone recommend an installer creator that can perform all of these tasks?
Out of curiosity, is it possible to distribute through the Windows Store and have it do more than just copy the app down, i.e. execute an installations script?
By design, the installation process for a Store app, whether downloaded from the Store or side-loaded, is not customizable. For Store downloads, this is done to guarantee that the app install won't create anything that cannot be reversed during an uninstall, e.g. create registry entries, copy files, and otherwise do things that can permanently alter the system.
For side-loading, although you cannot alter the specific package deployment process itself, you can use the Powershell deployment as just one step in an overall install process. You should be able to build such an installer with any number of existing Desktop application installer tools, which give you control over all steps in your install process including registry, drivers, running scripts, etc. So you'd just have the app package and PS scripts as part of the installer .msi or .exe, and executing the PS script is done from the installer.
(By the way, the Store/PS app install processes use the same API in Windows.Management.Deployment.PackageManager to do the work. This API can be used only from a full-trust process like the Store (a piece of system code) or Powershell running in an admin console, but is there so desktop apps can implement alternate install procedures directly.)
I have an SSIS package that I use for a quick upload to a SQL database. I have recently moved to a different machine. New specs are Win 7 64bit and Office 2010 32bit. Had to have the 32 bit office in order for another program to run correctly. If I build/run the package in SQL Server Data Tools it completes. But if I try to run the solution from a batch script, I get the microsoft.ACE.oledb.12.0 is not registered error. I have searched many sites, and downloaded what I assume were the appropriate install packages to have the ACE driver.
I used a trick from one of the sites where you make a new text file, and rename it TEST.UDL. When I right click on the file, select properties, and go to the provider tab, Microsoft ACE is not listed. Is there another step to register the ACE driver that I am missing?
Thanks
I found that I was still executing the 64bit dtexec.exe, and had to rewrite my batch script to find the 32bit version.
I have a .NET application which uses an accdb file (MS Access 2007 format) as its database. To install this app on another machine I need to install the Access engine on that machine. Microsoft has this file: AccessDatabaseEngine.exe which includes the engine, but when extracted during installation, runs another .msi installer.
As you can guess, since this msi is run during the installation of another msi (my app's installer) the Access engine setup fails with error 1500: "Another installation is in progress. Finish that one before continuing this one..."
I found the Runtime for Access 2007 as well, and it does install the engine, but the Runtime package is again an msi installer which means I'm still having the same problem.
Any ideas to include the engine in my app's installer?
You probably want to have a look at this article: Adding Programs to Access 2007 Deployment Packages
The Access Developer Extensions offer a basic but functional installer that can take care of the general deployment scenarios.
The best think would be to build your own msi pack including needed access files. You could use a product like VERITAS Wininstall. You have this "Discover" method that allows you to build a fully operationial .msi file by (1) taking 2 snapshots of your system (one before the installation, one after) then (2) creating the .msi file corresponding to the installation process.
Anyway, I'd advise you to have multiple packs, one for Access, that can be installed with a "for all users" option when the computer joins your company's domain, one for your app. By doing so you will be able to distribute new versions of your app without redistributing Access, which takes a few mega of space as well as a few minutes of user's most precious time).
Sio if Microsoft already delivers an Access Runtime msi package, just keep it 'as is' and distribute it automatically on your network when a new machine joins the domain.
I wouldn't recommend WinInstall, we have it in my office and we have to keep calling them in to package stuff for us as it's so finiky to use. Some things they haven't been able to package at all. WISE Studio is better or a free alternative is AppDeploy whihc I have heard great things about.
I found this software called "Bootstrapper Manifest Generator" or BMG. It helps create a prerequisite package using an MSI or EXE installer file, and adds it to VS2008 Prerequisites dialog box in Setup and Deployment projects. Although it's not that user friendly, it does the job. It's on MSDN: code.msdn.microsoft.com/bmg
Thought it's good to save others from going through all the trouble.