Betrachten Sie diesen unveränderlichen Typ:

public class Settings
{
    public string Path { get; private set; }

    [ContractInvariantMethod]
    private void ObjectInvariants()
    {
        Contract.Invariant(Path != null);
    }

    public Settings(string path)
    {
        Contract.Requires(path != null);
        Path = path;
    }
}

Zwei Dinge, die Sie hier beachten sollten:

Es gibt eine Vertragsinvariante, die das @ sicherstelPath Eigenschaft kann niemals @ senull Der Konstruktor prüft daspath Argumentwert, um die vorherige Vertragsinvariante zu respektieren

n diesem Punkt einSetting Instanz kann niemals ein @ habnull Path Eigentum

Nun, sieh dir diesen Typ an:

public class Program
{
    private readonly string _path;

    [ContractInvariantMethod]
    private void ObjectInvariants()
    {
        Contract.Invariant(_path != null);
    }

    public Program(Settings settings)
    {
        Contract.Requires(settings != null);
        _path = settings.Path;
    } // <------ "CodeContracts: invariant unproven: _path != null"
}

rundsätzlich hat es eine eigene Vertragsinvariante (auf_path -Feld), das bei der statischen Prüfung nicht erfüllt werden kann (siehe Kommentar oben). Das klingt ein bisschen komisch für mich, da es einfach ist, es zu beweisen:

settings ist unveränderlichsettings.Path kann nicht null sein (da Settings die entsprechende Vertragsinvariante hat)so durch Zuweisen vonsettings.Path zu_path, _path kann nicht null sein

Habe ich hier etwas verpasst?