Custom Action Fails to Run
David Morris
post-install SQL Script. I currently have a vbs script that runs in a custom
action. Here is the script source named DatabaseInstall.vbs:
Set objShell = CreateObject("WScript.Shell")
Set objScriptExec = objShell.Exec("Sqlcmd -S .\SqlExpress -i
DatabaseInstall.sql -o DatabaseInstall.log")
This script is installed in my application directory and runs fine from a
command line if I just run it in a cmd window. However, it doesn't seem to
run in the installer. I turned on logging and see the following lines in the
MSIxxxxx.log file:
Action 21:15:40: _F95A2892_9672_45CA_A2EA_F5C1BB6707BE.
MSI (s) (50:B0) [21:15:40:827]: Executing op:
CustomActionSchedule(Action=_F95A2892_9672_45CA_A2EA_F5C1BB6707BE,ActionType=1030,Source=Set objShell = CreateObject("WScript.Shell")
Set objScriptExec = objShell.Exec("Sqlcmd -S .\SqlExpress -i
DatabaseInstall.sql -o DatabaseInstall.log")
Do you have any suggestions on what I may be doing wrong? I am also open to
an alternate method of running my database setup script via sqlcmd.
Thanks,
David Morris
Richard [Microsoft Windows Installer MVP]
=?Utf-8?B?RGF2aWQgTW9ycmlz?= <dmmo...@newsgroup.nospam> spake the secret code
<99F54A78-66D1-435D...@microsoft.com> thusly:
>Do you have any suggestions on what I may be doing wrong? I am also open to
>an alternate method of running my database setup script via sqlcmd.
The recommended practice is to configure your database the first time
the application is run. That would be where I would execute and SQL
that needs to run.
If you put it in the install, it vastly complicates the install log.
Its best to leave installation to the MSI and configuration (database
configuration, template data file generation, etc.) to the application
on first run. Sometimes people have the application launched from the
last dialog of the install and that makes the configuration more
likely to happen right away after installation is complete and
successful.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Linda Liu[MSFT]
Firstly,
> This script is installed in my application directory and runs fine from a
command line if I just run it in a cmd window.
Do you mean that when the MSI package is installed, the vbs script file
will be installed on the application directory and then a custom action
runs the installed vbs script file at the end of the installation?
If so, the Type value of the custom action should be 1046 and the Source
value should be the File key of the vbs script file in the File table. FYI
you can open the MSI package with Orca. In the CustomAction table, you can
see the Type and Source values of the custom action.
Secondly, since the vbs script file uses the sqlcmd utility, please make
sure the client machine on which the MSI package is installed has the
sqlcmd utility installed already.
Thirdly, what's the OS version of the client machine? If it is Windows
Vista, you may need to register vbscript.dll manually because for some
reason the vbscript.dll isn't registered automatically within Windows Vista.
To do this , Start button -> All Programs -> Accessories -> Right click on
Command Prompt, select 'Run as administrator'. You should be in directory
C:\Windows\System32
Type regsvr32 vbscript.dll (enter)
Should get a message box saying DLL has been registered. Then run the
installer again.
Hope this helps.
Sincerely,
Linda Liu
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
David Morris
is in the directory but it doesn't run. The project was developed using
VS2005 because I encountered too many problems in VS2008 with SQL2005 to fit
an upgrade in right now. From the log it looks like the type is 1030. Is
there some way to set the type in VS2005 to 1046?
The output of the DB Professionals project built such a nice install script
for SQL that I decided to use it directly. That is why there is a dependency
on sqlcmd. I am hopeful that this gets better with VS2008/SQL2008.
A Vista install is not an absolute requirement this first pass but it will
be in a few months so I will keep your comments about registering the DLL.
Thanks,
David Morris
David Morris
"open the MSI package". It always kicks off an install unless I select open
with but I am not sure what to use. Could you please give me more information
on how I open an MSI in Orcas (VS2008?).
Thanks,
David Morris
"Linda Liu[MSFT]" wrote:
> Hi David,
>
> ...FYI
> you can open the MSI package with Orca. In the CustomAction table, you can
> see the Type and Source values of the custom action....
Phil Wilson
Studio 200n, which was Orcas.
--
Phil Wilson
"David Morris" <dmmo...@newsgroup.nospam> wrote in message
news:80684E3B-EE4B-48EC...@microsoft.com...
Phil Wilson
not going to work. The script is not running in your application folder,
it's running in an msiexec.exe process from the system folder. You'll need
tp pass a full path, something like [TARGETDIR]Sqlexpress -1 ...
And Richard is right. Doing this from the install is always full of gotchas,
and it will just get more complicated on Vista amd 2008.
--
Phil Wilson
"David Morris" <dmmo...@newsgroup.nospam> wrote in message
news:99F54A78-66D1-435D...@microsoft.com...
Christopher Painter
my installs all the time. I just installed a new instance of VSTS
TFS and it included loads of configuration questions to enable setting
up the entire system including creating databases to go behind the
application layer.
Let's say I suddenly agree that this is all wrong and that it should
wait until application first run. How do you know the first person
to run the application will be and administrator? ( Think silent SMS
push. ) Would you set it all up so that a non-administrator has
privs to create the database to finish the installation and
configuration of the system?
I'm afraid I just don't buy the whole argument that configuration data
is a pain ... it can be done painlessly with a much better user
experience. You just have to have the right tools to help get it
done.
Phil Wilson
installs, doing some configuration as part of the install is more of an
option. For the legions of Visual Studio Developers who:
1) Are really C# or VB developers that discovered (or were told to use)
Visual Studio Setup Projects and..
2) Are unaware of the limitations and behavior of Visual Studio Setups
and...
3) Are unaware of the implications of running code from within an install...
I think that configuration when the app first runs is preferable. Sure,
there are going to be issues sometimes if admin privilege is required, but
people using VS 2005 custom actions on Vista are already struggling with the
fact that they run impersonated but limited even if they are administrators.
It's my experience that trying to explain all that behavior and getting it
fixed is in many cases a worse problem than having a configuration program
that can run by an administrator, in a startup script as admin if necessary.
So, I think your "right tools" point is on the money, but Visual Studio
setup projects aren't it.
--
Phil Wilson
Definitive Guide to Windoows Installer
http://www.apress.com/book/view/1590592972
"Christopher Painter" <chr...@yahoo.com> wrote in message
news:0a84c08d-7697-4501...@k13g2000hse.googlegroups.com...
Richard [Microsoft Windows Installer MVP]
"Phil Wilson" <phil....@wonderware.something.com> spake the secret code
<OzNN820m...@TK2MSFTNGP03.phx.gbl> thusly:
>For people who know all about setups and know the issues surrounding MSI
>installs, doing some configuration as part of the install is more of an
>option. For the legions of Visual Studio Developers who:
>
>1) Are really C# or VB developers that discovered (or were told to use)
>Visual Studio Setup Projects and..
>2) Are unaware of the limitations and behavior of Visual Studio Setups
>and...
>3) Are unaware of the implications of running code from within an install...
>
>I think that configuration when the app first runs is preferable. [...]
As a Windows Installer expert, *I* prefer configuration when the app
first runs. Why would I want my install to be more complex and
fragile?
Christopher Painter
[Microsoft Windows Installer MVP]) wrote:
> As a Windows Installer expert, *I* prefer configuration when the app
> first runs. Why would I want my install to be more complex and
> fragile?
I would think that a `Windows Installer Expert` should be able to
solve complex business problems for customers without sacrificing
quality. I know that's what I strive to do for my clients.
David Morris
see why you recommend not running this script as part of the installer but I
do have a fairly controlled environment so it may not be as big a problem. I
did find the right Orca (guess I didn't need to install VS2008 but at least
that let me debug another problem). I see that the type is 1030 and the
script source shows as a hex value.
Regardless of whether I should build the database as part of the install or
not, I think I will need to run some kind of post-install process. On the
surface, a vbs script is easy and seems like a reasonably good fit. However,
I can't seem to get this thing to run as part of the install. In the mean
time, I changed the install to built a menu shortcut to the .vbs file and
named it Database Initialization. Clicking on that link gets me by for now.
You are right that I am a .NET Developer that doesn't have a lot of
experience with the VS Build tool. Based on past experience, I will need to
build a pretty good understanding of the VS Build tools because I am
rewriting a several Java applications that use the NullSoft installer. I may
be able to put this off until I switch over to VS2008. Recognizing this, I
did a search for MSI books and your name came up. A source of sample build
projects would also help.
Thanks,
David Morris
Linda Liu[MSFT]
Thank you for your reply!
Could you tell me with which tool you create your MSI package?
If you're using VS2005 to create a setup project, the following is a
walkthrough to create an MSI package that runs a simple VB script at the
end of the installation. You may check whether there's any difference
between yours and the following.
1. Create a Setup project in VS2005.
2. Create a new file with Notepad and type the following text in the file:
msgbox "hello from test msi package"
then save this file as test.vbs.
3. Click the 'File System Editor' button at the top of the Properties
window to open the 'File System' editor. Add the test.vbs file to the
'Application Folder'.
4. Click the 'Custom Actions Editor' button at the top of the Properties
window to open the 'Custom Action' editor. Right click the 'Install' node
and choose 'Add Custom Action'. Select the test.vbs file in the 'Select
Item in Project' dialog. Click OK.
5. Build the Setup project and install the resulting MSI package. A message
box saying "hello from test msi package" pops up at the end of the
installation. Close the message box and the installation is finished.
Hope this helps.
Sincerely,
Linda Liu
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
andyong
One thing that caught me out for a little while was getting paths right. I wasn't sure if the MSI was using a working directory of the MSI itself, or of the target deployment folder. Turned out it was actually using the system32 folder as the working directory.
Got this script to work for me in the end
set objShell = CreateObject("WScript.Shell")
set fso = CreateObject("Scripting.FileSystemObject")
install32 = "C:\Program Files\"
install64 = "C:\Program Files (x86)\"
'msgbox "Working Directory is " + fso.GetAbsolutePathName("")
'Check if the install is 32 or 64 bit and point sqlcmd to correct location of .sql scripts
if fso.FolderExists(install64) Then
msgbox "installing 64 bit version"
installPath = install64 & "\ProjectFolder"
cmdString = "Sqlcmd -d Master -i """ & installPath & "\dbProject.sql"" -o """ & installPath & "\dbProject.log"""
'msgbox cmdString
Set objScriptExec = objShell.Exec(cmdString)
else
'msgbox "installing 32 bit version"
installPath = install32 & "\ProjectFolder"
cmdString = "Sqlcmd -d Master -i """ & installPath & "\dbProject.sql"" -o """ & installPath & "\dbProject.log"""
'msgbox cmdString
Set objScriptExec = objShell.Exec(cmdString)
End if
I know it's far from ideal as I'd need to modify the target folders if I wanted to deploy the files elsewhere (though we probably won't need to), plus a whole host of other reasons, but at least I CAN deploy the database via msi now.
For others reading this I have a solution with a SQL Server 2005 database project (DB Pro), and a setup project. I added the primary output from the DB Pro project to the setup project (that will build the dbProject.dbmeta and the dbProject.sql), added the .vbs script above, and followed the other instructions by Linda to add the .vbs to the Application Folder and add the custom action to execute this