On Sep 11, 5:56 pm, rmgala...@galaware.com wrote:
> On Sep 3, 10:03 am, rmgala...@galaware.com wrote:
>
>
>
>
>
> > 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).
>
> 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 -
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.
|
Similar Threads
Linear Mode
