@0xced
Thanks for your effort.

Can your PR help in fixing the issue #499?

Ping.

Thanks for your work.
The Parser already throw InvalidOperationException not NullReferenceException for default constructor.
What about if the Exception message is reworded and contain something like:

... the constructor should have parameters with the same names as Type properties and in the same order(inherited options are expected at the end of the constructor parameter list)..

Have a look to this discussion
This may help in resolving immutable types Ctor Exceptions.

The Parser already throw InvalidOperationException not NullReferenceException for default constructor.

Sorry, I should have properly explained the purpose of this pull request in the description; this is actually not always the case. When help is requested, the code takes another path and we get a NullReferenceException instead of InvalidOperationException. I have added OptionClass_IsImmutable_HasNoCtor_HelpRequested test to cover that specific issue.

I'll have a look at #188, but it looks orthogonal at first sight.

When help is requested, the code takes another path

That is correct. But Parser isn't calling the InstanceBuilder.Build . It Fire the Help Screen.
InvokeBuild in Test call InstanceBuilder.Build .

The Parser still in help request fire InvalidOperationException.

The attached file is a demo project to demonestrate help request with the Immutable class.
ConsoleApp1.zip
run:

    consoleapp1 --help

Edit:
In case of using InvokeBuild, autohelp parameter should be false.

The next Test case Pass successfully.

 [Fact]
        public void Parse_Immutable_with_default_ctor_and_help__request_throw_InvalidOperationException()
        {

            Action act = () => InvokeBuild<ValueWithNoSetterOptions>(new string[] { "--help" }, false);
            act.Should().Throw<InvalidOperationException>();
        }