0.9.10 and exit codes

[ferventcoder]

I mentioned this before in April - chocolatey/choco#512. 0.9.10 just released today. This includes the library. As you upgrade, be especially sure to pay attention to this scenario.

Here is the relevant portion of the ChangeLog (under breaking changes):

• Exit with the same exit code as the software being installed - see #512

There are more exit codes from Chocolatey now that indicate success -0, 1605, 1614, 1641, and 3010. You may need to adjust anything you were using that would only check for 0 and nonzero.
If you need the previous behavior, be sure to disable the feature usePackageExitCodes or use the --ignore-package-exit-codes switch in your choco commands.

[mwrock]

yay! I'll plan on a releasing a new boxstarter soon with updated chocolatey. this fix in particular will make debugging certain scenarios much easier!

[riezebosch]

I suspect that I'm having issues with the return codes. All my packages that indicate a required reboot are marked as unsuccessful.

But when I update the chocolatey.dll to version 0.9.10.3 I get errors when the ChocolateyWrapper is instantiated from the SimpleInjector that the container cannot be modified anymore.

[ferventcoder]

@riezebosch share the errors?

[riezebosch]

Boxstarter: Error from chocolatey:

ErrorRecord                 : Exception calling ".ctor" with "5" argument(s): "The container can't be changed after the
                               first call to GetInstance, GetAllInstances and Verify."
StackTrace                  :    at System.Management.Automation.DotNetAdapter.AuxiliaryConstructorInvoke(MethodInforma
                              tion methodInformation, Object[] arguments, Object[] originalArguments)
                                 at System.Management.Automation.DotNetAdapter.ConstructorInvokeDotNet(Type type, Const
                              ructorInfo[] constructors, Object[] arguments)
                                 at Microsoft.PowerShell.Commands.NewObjectCommand.CallConstructor(Type type, Construct
                              orInfo[] constructors, Object[] args)
WasThrownFromThrowStatement : False
Message                     : Exception calling ".ctor" with "5" argument(s): "The container can't be changed after the
                               first call to GetInstance, GetAllInstances and Verify."
Data                        : {}
InnerException              : System.InvalidOperationException: The container can't be changed after the first call to
                              GetInstance, GetAllInstances and Verify.
                                 at SimpleInjector.Container.ThrowWhenContainerIsLocked()
                                 at SimpleInjector.Container.AddRegistration(Type serviceType, Registration registratio
                              n)
                                 at Boxstarter.ChocolateyWrapper..ctor(String boxstarterSetup, PSHostUserInterface ui,
                              Boolean logDebug, String logPath, Boolean quiet)
TargetSite                  : System.Object AuxiliaryConstructorInvoke(System.Management.Automation.MethodInformation,
                              System.Object[], System.Object[])
HelpLink                    :
Source                      : System.Management.Automation
HResult                     : -2146233087

[ferventcoder]

Are you trying to change the container?

[riezebosch]

Not that I'm aware of. The ChocolateyWrapper does so.

[riezebosch]

I'm almost done updating the chocolatey assembly that is shipped with Boxstarter. This solves several incompatibilities of Boxstarter with the current version of chocolatey.

One problem with the chocolatey API that I created a workaround for is the modifications of the SimpleInjector container. The container that is used by GetChocolatey is resolved from a static (lazy) field. This is problematic when GetChocolatey is called multiple times and the container get modified with new registrations. I solved this by storing the GetChocolatey result in a static field and do the registration only once.

Another problem that I haven't fixed yet is a stackoverflow exception with the custom logger that gets injected by boxstarter.

But by disabling the custom logger temporarily I was able to run a very complicated install script successfully. The exit coded and cancelled reboots from chocolatey where all handled just fine and I suspect the newer chocolatey switches and features to work also.

Update
I'm a bit lost in the logger infrastructure of chocolatey. The original PsLogger from mwrock writes to the logfile and also to the $host.UI. But with the new chocolatey assembly that output seems to be intercepted and provided again to the logger which results in an infinite recursive call, hence a stackoverflow exception.

The easy solution for me is not to output it to the $host but do a Console.WriteLine instead.

But the other problem is that all log messages I receive from chocolatey are invoked on the Info method of the custom ILog. That doesn't seem right to me and I can't figure out from where these calls are initiated inside chocolatey. I would like to not worry about the console at all but providing a custom logger resets all original loggers nowadays. I cannot figure out how to add the original Log4NetLog again.

[ferventcoder]

I'm a bit lost in the logger infrastructure of chocolatey. The original PsLogger from mwrock writes to the logfile and also to the $host.UI. But with the new chocolatey assembly that output seems to be intercepted and provided again to the logger which results in an infinite recursive call, hence a stackoverflow exception.

I'd be curious to see the code where you are running into this. The loggers should only log, not write to a log file. Chocolatey will handle the writing to the console and to the chocolatey.log file on its own as long as the Log4NetLogger is still there.

The easy solution for me is not to output it to the $host but do a Console.WriteLine instead.

But the other problem is that all log messages I receive from chocolatey are invoked on the Info method of the custom ILog. That doesn't seem right to me and I can't figure out from where these calls are initiated inside chocolatey. I would like to not worry about the console at all but providing a custom logger resets all original loggers nowadays. I cannot figure out how to add the original Log4NetLog again.

That sounds a bit like a bug, but I think it's likely that it would be better to expose an option for the custom logger to be appended to the list instead of becoming the only logger.

I would like to not worry about the console at all but providing a custom logger resets all original loggers nowadays

This was actually meant to fix another issue. chocolatey/choco@eff02ea.

[riezebosch]

Please, have a look: https://github.com/riezebosch/boxstarter/commit/44928cf2f0bcf25c7883e5cfb031e0f78f9fd84c

I added tests to prove the working functionality. You'll have to install psake and invoke psake .\BuildScripts\default.ps1 install-chocolib to download the chocolatey-lib and dependencies.

One thing I noticed is that AlphaFS is missing as a dependency on the chocolatey-lib in the nuspec.

I've created a separate commit where I filter the VERBOSE messages from the logger. I don't know exactly where the messages are coming from, but is possible these are generated from the boxstarter scripts with all it overrides.

[ferventcoder]

chocolatey/choco#1121

[pauby]

PR #219 was merged. Boxstarter ships with a later version of chocolately.dll now.