On Sep 3, 10:03 am, rmgala...@galaware.com wrote:[color=blue]
> I have written a VB.Net Windows Forms application that uses the
> Composite UI Application Block, the Data Application Block, and a Sql
> Server Express 2005 database. The database is accessible across a
> network, but it can run in standalone mode as well. The application
> was completed in January 2007.
>
> I created a setup and deployment project that installs Windows
> Installer 3.1, .Net Framework 2.0, Sql Server Express 2005, and my
> Windows Forms application. I created a custom action that launches
> after my program is installed. The custom action executes an Installer
> class, which is embedded in my Windows Forms application. If an error
> occurs in the custom action, the setup rolls back the installation.
>
> The custom action uses osql to create and initialize the database that
> my application uses. I feed osql a SQL file with all the details.
> Before the custom action executes the osql command, it modifies some
> of the details in the SQL file to make it unique to the machine on
> which it's running. Then it initializes a common area in the registry,
> which my Windows Forms application uses to determine whether or not
> the application has been installed correctly. This worked fine in all
> installations where the machine is running XP Home and XP Pro.
> Multiple users may be using the same machines in many installation
> locations. So the registry location has to be common.
>
> Now, many new machines are running Vista. The custom action fails to
> launch, and I get error 2869. I have no clue what the problem is,
> because I don't get an error message box, like I did on XP Pro
> machine. I have seen that I can use Orca to modify the Custom Action
> Table so that the msidbCustomActionTypeNoImpersonate flag is set. This
> does not solve the problem. Disabling UAC does not alleviate the
> problem either. In both instances I am executing setup.exe as an
> Administrator ("Run as Administrator").
>
> I read an article that says the MSIService no longer provides a
> privilege, seBackup, which enables access to the registry. I'm not
> sure if this is the problem. But, how are we supposed to create Sql
> Server Express databases, initialize data in the db tables, and
> configure a registry entry, if we can't do it from a custom action?
> It's a custom action because the standard registry configuration in
> Setup and Deployment doesn't suffice, and setup and deployment doesn't
> provide a way to create a SQL Express database (at least one that is
> accessible from the network).[/color]

My solution is to remove the ProjectInstaller class from the
application. Also, I removed the custom action from the setup and
deployment application.

I wrote a Windows application which performs the database creation and
initialization, and registry configuration. Then I created a batch
file which launches the setup.exe program and waits for it to finish.
If no error occurs, the batch file launches the Windows application
and waits for it to finish. I have to run the batch file as an
administrator, but this seems to work.