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).

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.

On Sep 11, 5:56 pm, rmgala...@galaware.com wrote:[color=blue]
> On Sep 3, 10:03 am, rmgala...@galaware.com wrote:
>
>
>
>
>[color=green]
> > 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.[/color]
>[color=green]
> > 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.[/color]
>[color=green]
> > 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.[/color]
>[color=green]
> > 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").[/color]
>[color=green]
> > 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.- Hide quoted text -
>
> - Show quoted text -[/color]

This problem has cost me alot in time and customer satisfaction. The
solution is less than optimal. So what have I learned?

1. Applications that require Sql Server 2005 Express involve far too
much administrator interaction on client machines to get them
configured properly. Installation is easy, but configuration is hard.
Between the firewall configuration, the protocol configuration, and
other configuration details, such as mixed mode configuration in the
registry, it is just too hard to setup. Access databases are far
easier, and I will recommend that solution in my next project if a
local database is required and network access is not.
2. The difference between Windows XP and Windows Vista is so great
that creating installation packages that run in both environments is
difficult to say the least. You can create a custom action that uses
the ProjectInstaller class, but you can't do much in the launched
application because the MSIService's permissions have been changed,
and that is the context in which a launched custom action runs.
3. Windows Vista - Administrator does not mean administrator.
Microsoft has now decided that you do not know enough to be trusted.
Therefore, even if you are logged in as an administrator, you are not
an administrator.
4. Error 2869 - yet another cryptic error message.