none
VS2010 Setup Projects Failing on Error 1001

    Question

  • Hello,

    We've got a fresh set of Setup Projects in our VS2010 solution, and I am experiencing an error when I attempt to Install it from the IDE (right click select to Install).

    The error goes something like this one:

    http://social.msdn.microsoft.com/Forums/en/winformssetup/thread/829d5c90-9a0d-4258-9d4d-1341cc50f95b

    I do have custom actions running, which I see all three names appearing one after the other with the same error: "Could not find file <path>\<filename>.InstallState ..."

    Do we need to be saving something in the process of running the installation through custom actions?

    I've been able to get somewhat past that and now I need to verify that my CustomActionData is getting through to my Installer handlers, Install(IDictionary) mainly at this point, possibly also Commit(IDictionary).

    I am finding evidence, however, that the parameters are not getting through. How can I debug this and know for certain?

    Best regards,

    Michael

    Tuesday, April 10, 2012 10:13 PM

Answers

  • So the answer is: it's a timing issue. I was handling the InstallContext during the constructor. This is too early. Instead, handle the InstallContext when Install, Uninstall, Commit, or Rollback are called. This is the correct time.
    • Marked as answer by mwpowellhtx Monday, April 16, 2012 5:27 PM
    Monday, April 16, 2012 5:27 PM

All replies

  • Actually, and I need to dig through the documentation in some more depth, the thought occurs to me:

    What is the difference between Context.Parameters and the IDictionary stateSaver?

    Am I grasping this that the Parameters are actually what get captured and reported to the installer code?

    While the IDictionary stateSaver is what gets saved in InstallState when the operation finishes?

    So really and truly I just need to support my Context.Parameters in order to capture that.

    Then save messages or other details to InstallState afterward?

    Wednesday, April 11, 2012 12:09 AM
  • I'm at a loss: I believe I've corrected our usage of Context and Parameters: we've got a console app that runs the install steps not including any Installer operation, basically just passes in Parameters and runs.

    Those then generically adapt into an Installer-derived InstallerClass.

    The installation runs fine from the console application: the steps all run like I am expecting them to.

    Of plausible note: we're spawning a process to run the setup, which is basically just calling out to Sql Server 2008 Express installer, with requisite command line parameters. Like I said: runs fine through console spawning process, only not through the installer context.

    I am formatting my CustomActionData along these lines: /SAPWD="[SAPWD]" (and so on, all single-space delimited).

    However, we get the following log details:

    2012-04-11 09:45:45 Slp: ----------------------------------------------------------------------
    2012-04-11 09:45:45 Slp: Running Action: ProcessFeatureCommandLineArguments
    2012-04-11 09:45:45 Slp: ----------------------------------------
    2012-04-11 09:45:45 Slp: Setting: SAPWD
    2012-04-11 09:45:45 Slp: New setting source: CommandLine; previous setting source: Default
    2012-04-11 09:45:46 Slp: Error: Action "ProcessFeatureCommandLineArguments" threw an exception during execution.
    2012-04-11 09:45:46 Slp: Microsoft.SqlServer.Setup.Chainer.Workflow.ActionExecutionException: The specified value for setting 'SAPWD' is invalid. The expected value type is SqlSecureString. ---> Microsoft.SqlServer.Chainer.Infrastructure.InputSettingValidationException: The specified value for setting 'SAPWD' is invalid. The expected value type is SqlSecureString.
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.SaveInputSettingValueToObjectSqlSecureString(String settingName, Object hostingObject, PropertyInfo propertyInfo, Type propertyType, String[] stringValues)
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.SaveInputSettingValueToObject(InputSettingInfo inputSettingInfo, List`1 values)
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.SaveParsedArgumentsIntoInputSettingStore(InputSettingSource source, Dictionary`2 parsedArguments, Boolean chainerSetting, Boolean ignoreSettingsForNotAllowedScnearios)
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.ProcessCommandLineArguments(String[] commandLineArguments, Boolean chainerSetting)
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Configuration.BootstrapExtension.ProcessFeatureCommandLineArgumentsAction.ExecuteAction(String actionId)
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Chainer.Infrastructure.Action.Execute(String actionId, TextWriter errorStream)
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Setup.Chainer.Workflow.ActionInvocation.InvokeAction(WorkflowObject metabase, TextWriter statusStream)
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Setup.Chainer.Workflow.PendingActions.InvokeActions(WorkflowObject metaDb, TextWriter loggingStream)
    2012-04-11 09:45:46 Slp:    --- End of inner exception stack trace ---
    2012-04-11 09:45:46 Slp:    at Microsoft.SqlServer.Setup.Chainer.Workflow.PendingActions.InvokeActions(WorkflowObject metaDb, TextWriter loggingStream)
    2012-04-11 09:45:46 Slp: Received request to add the following file to Watson reporting: C:\Users\<user>\AppData\Local\Temp\tmp74C5.tmp
    2012-04-11 09:45:46 Slp: The following is an exception stack listing the exceptions in outermost to innermost order
    2012-04-11 09:45:46 Slp: Inner exceptions are being indented
    2012-04-11 09:45:46 Slp:
    2012-04-11 09:45:46 Slp: Exception type: Microsoft.SqlServer.Chainer.Infrastructure.InputSettingValidationException
    2012-04-11 09:45:46 Slp:     Message:
    2012-04-11 09:45:46 Slp:         The specified value for setting 'SAPWD' is invalid. The expected value type is SqlSecureString.
    2012-04-11 09:45:46 Slp:     Data:
    2012-04-11 09:45:46 Slp:       DisableWatson = true
    2012-04-11 09:45:46 Slp:     Stack:
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.SaveInputSettingValueToObjectSqlSecureString(String settingName, Object hostingObject, PropertyInfo propertyInfo, Type propertyType, String[] stringValues)
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.SaveInputSettingValueToObject(InputSettingInfo inputSettingInfo, List`1 values)
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.SaveParsedArgumentsIntoInputSettingStore(InputSettingSource source, Dictionary`2 parsedArguments, Boolean chainerSetting, Boolean ignoreSettingsForNotAllowedScnearios)
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Chainer.Infrastructure.InputSettingService.ProcessCommandLineArguments(String[] commandLineArguments, Boolean chainerSetting)
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Configuration.BootstrapExtension.ProcessFeatureCommandLineArgumentsAction.ExecuteAction(String actionId)
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Chainer.Infrastructure.Action.Execute(String actionId, TextWriter errorStream)
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Setup.Chainer.Workflow.ActionInvocation.InvokeAction(WorkflowObject metabase, TextWriter statusStream)
    2012-04-11 09:45:46 Slp:         at Microsoft.SqlServer.Setup.Chainer.Workflow.PendingActions.InvokeActions(WorkflowObject metaDb, TextWriter loggingStream)

    Wednesday, April 11, 2012 3:30 PM
  • Those managed code installer class custom actions need to be on all the nodes, and the installstate file carries any state from first to last. If you do a Commit custom action only, it will look for the file from the previous custom actions. You don't need to do any code in the Install etc custom actions, just let the base method be called to create the installstate file. Anyway that might be the problem.


    Phil Wilson

    Wednesday, April 11, 2012 9:08 PM
    Moderator
  • Okay, I've done this, and put some exception handling in to see if I am indeed passing any parameters. Somehow my parameters are not making it from CustomActionData to my Installer Context.Parameters collection. How does this work from the CustomActionData perspective? Like I said, when I integrate my handlers through a test console using something like NDesk.Options to feed my parameters, this works just fine. So it's something about how the parameters are hooked into the Installer context that isn't working...
    Friday, April 13, 2012 2:22 PM
  • More investigation... Upon closer examination, my Parameters are empty because my Context is actually null; this is true across the board.

    So... How does one obtain the InstallContext from the MSI environment? This isn't automatically picked up by the base class code?

    Friday, April 13, 2012 5:14 PM
  • The remarks for InstallContext would lead me to believe that I can expect an instance of InstallContext when the CustomActions are run. This doesn't seem to be the case: I find null for Context.

    http://msdn.microsoft.com/en-us/library/system.configuration.install.installcontext.aspx

    Is the example code just an example, or is that more typical of how it's supposed to be used?


    Typically, an InstallContext is created by an installation executable, such as InstallUtil.exe, that installs assemblies. The installation program invokes the InstallContext constructor, passing it the default log-file path and command-line parameters.

    Prior to calling its Install, Commit, Rollback, or Uninstall methods, the installation program sets the Context property of an Installer to the instance of InstallContext. Before calling these methods, an Installer that contains an installer collection in the Installers property sets the Context property of each contained installer.

    The Parameters property contains a parsed version of the command line that is entered to run the installation executable. The property contains information such as the path to a log file, whether to display log information on the console, and whether to show a user interface during the installation. Call the IsParameterTrue method to find out whether a command-line parameter is true.

    Use the LogMessage method to write status messages to the installation log file and the console.

    Monday, April 16, 2012 3:42 PM
  • So the answer is: it's a timing issue. I was handling the InstallContext during the constructor. This is too early. Instead, handle the InstallContext when Install, Uninstall, Commit, or Rollback are called. This is the correct time.
    • Marked as answer by mwpowellhtx Monday, April 16, 2012 5:27 PM
    Monday, April 16, 2012 5:27 PM
  • Hi mwpowellhtx,
    I’m glad you have solved the issue and thank you for share it with us.
    Best Regards,

    Bob Wu [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, April 17, 2012 1:51 AM
    Moderator
  • No problem. The next round of questions aren't going to be so straightforward I'm afraid: we're installing through MSI and bumping into Win7 (Vista) UAC (User Account Control) issues to do with credentials, plausibly needing to impersonate and/or run in heightened mode. However, these deserve a separate thread I think.
    Tuesday, April 17, 2012 3:07 PM
  •  However, these deserve a separate thread I think.
    Hi mwpowellhtx,
    Yes, if you have a new issue, create a new thread would be a better choice.
    Have a nice day.

    Bob Wu [MSFT]
    MSDN Community Support | Feedback to us


    Wednesday, April 18, 2012 2:16 AM
    Moderator