locked
Service Installer Project - Default Command Line Args? RRS feed

  • Question

  • Is there a way in a service setup project to specify an initial command line arg string?

    Neither the ServiceInstaller or ServiceProcessInstaller offer any way to do this.

    So I must document and explain to the user that they need to run a config tool right after installation, in order to setup initial args.

    This seems a little dumb to me?

    H
    Tuesday, February 24, 2009 10:51 AM

Answers

  • I haven't used that approach, but it should work fine. Don't forget that you'll need to remove it too on an uninstall (because you created it with your code).
    I try to avoid installer classes - other issues you are likely to have are that upgrades don't work well. When a service is created with code (rather than with MSI tables) the sharing does not work because the installer classes don't ref count how many installs are using the service. A RemovePreviousVersions upgrade requires sharing to work properly, and you see issues because the installer class tries to reinstall the service.  I use the ServiceInstall and ServiceControl tables in the MSI file, but that requires some internal knowledge about MSI internals.
    You might find this interesting or useful:
    http://www.installsite.org/pages/en/msi/tips.htm 
    scroll down to Installing Services with Visual Studio.
    Phil Wilson
    • Marked as answer by Captain Kernel Thursday, February 26, 2009 8:14 AM
    Thursday, February 26, 2009 1:10 AM

All replies

  • It's only dumb in the sense that a Visual Studio Setup project isn't a fully-featured setup tool that offers all the same capabilities of Wise, InstallShield, WiX, Advanced Installer, or any number of other tools that people use to build MSI setups. I'm not quite sure what people's expectations are for VS seup projects. It's free with some Visual Studio editions, but I don't know why it's expected to have every feature an install might require. I'm not picking on you, it just seems to be a common path that people go down, to choose it without making sure it fits their requirements.

    Most install tools populate the built-in ServiceInstall table in an MSI file, and that includes an Arguments value. Visual Studio setup projects don't.

    Phil Wilson
    Tuesday, February 24, 2009 9:43 PM
  • PhilWilson said:

    It's only dumb in the sense that a Visual Studio Setup project isn't a fully-featured setup tool that offers all the same capabilities of Wise, InstallShield, WiX, Advanced Installer, or any number of other tools that people use to build MSI setups. I'm not quite sure what people's expectations are for VS seup projects. It's free with some Visual Studio editions, but I don't know why it's expected to have every feature an install might require. I'm not picking on you, it just seems to be a common path that people go down, to choose it without making sure it fits their requirements.

    Most install tools populate the built-in ServiceInstall table in an MSI file, and that includes an Arguments value. Visual Studio setup projects don't.


    Phil Wilson



    Hi Phil

    Yes you are correct of course. I guess the problme is that unless one is already very knowledgable about working with installs, it is very hard to ascertain whether Visual Studio's support is or is not adequate, there is no detailed feature list one can see and it is only when one hits a problem, that they become aware of a limitation.

    However, having said all this, I did read up and found that this code is added to your project when you add/define an installer:

    1     [RunInstaller(true)]  
    2     public partial class ProjectInstaller : Installer  
    3     {  
    4         public ProjectInstaller()  
    5         {  
    6             InitializeComponent();  
    7               
    8               
    9         }  
    10     }  
    11  

    It now seems that in there I can implement (override) OnAfterInstall().

    In here I could create the default registry arguments for the service.

    Have you used this approach much?

    Thx
    H

    Wednesday, February 25, 2009 10:28 AM
  • I haven't used that approach, but it should work fine. Don't forget that you'll need to remove it too on an uninstall (because you created it with your code).
    I try to avoid installer classes - other issues you are likely to have are that upgrades don't work well. When a service is created with code (rather than with MSI tables) the sharing does not work because the installer classes don't ref count how many installs are using the service. A RemovePreviousVersions upgrade requires sharing to work properly, and you see issues because the installer class tries to reinstall the service.  I use the ServiceInstall and ServiceControl tables in the MSI file, but that requires some internal knowledge about MSI internals.
    You might find this interesting or useful:
    http://www.installsite.org/pages/en/msi/tips.htm 
    scroll down to Installing Services with Visual Studio.
    Phil Wilson
    • Marked as answer by Captain Kernel Thursday, February 26, 2009 8:14 AM
    Thursday, February 26, 2009 1:10 AM
  • PhilWilson said:

    I haven't used that approach, but it should work fine. Don't forget that you'll need to remove it too on an uninstall (because you created it with your code).
    I try to avoid installer classes - other issues you are likely to have are that upgrades don't work well. When a service is created with code (rather than with MSI tables) the sharing does not work because the installer classes don't ref count how many installs are using the service. A RemovePreviousVersions upgrade requires sharing to work properly, and you see issues because the installer class tries to reinstall the service.  I use the ServiceInstall and ServiceControl tables in the MSI file, but that requires some internal knowledge about MSI internals.
    You might find this interesting or useful:
    http://www.installsite.org/pages/en/msi/tips.htm 
    scroll down to Installing Services with Visual Studio.


    Phil Wilson



    Phil

    Thanks for this info, I look fwd to studying this later.

    Many thanks
    H
    Thursday, February 26, 2009 8:14 AM