F #: Nachschlagen auf Objekt unbestimmter Art Bei der Verwendung von FluntNHibernate

Question

Ich versuche, NHibernate in F # -Projekt von FluentNHibernate zu konfigurieren.

static member GetNHibernateConfig = 
    Fluently.Configure() 
      .Database(MsSqlConfiguration.MsSql2008 
       .ConnectionString(fun c -> c.FromConnectionStringWithKey("connectionString") |> ignore) 
        .ShowSql()) 

Visual Studio Highlight "c.FromConnectionStringWithKey" mit Fehler:

Lookup auf Objekt von unbestimmter Art basieren auf Informationen, die vor diesem Programmpunkt. Vor diesem Programmpunkt kann eine Typ-Annotation erforderlich sein, um den Typ des Objekts einzuschränken. Dies kann ermöglichen, dass die Suche aufgelöst wird.

Answer 1

Ich weiß nichts darüber, aber das Web für API-Dokumentation von der Suche, würde ich versuchen, Ändern

fun c -> 

zu

fun (c:ConnectionStringBuilder) -> 

weil diese

http://fluentnhibernate.org/api/FluentNHibernate.Cfg.Db/PersistenceConfiguration%602.htm#ConnectionString

schlägt mir vor, dass das t sein kann Der Typ c.

EDIT:

(. Anscheinend ist der Typ ist MsSqlConnectionStringBuilder)

Wie auch immer, ganz allgemein, wenn Sie laufen in F # nicht Lambda-Typen Folgern, wenn C# der Fall ist, dann wahrscheinlich

• Sie‘ Verwenden Sie eine Methode mit mehreren Überladungen
• eine Teilmenge der Überladungen verwenden Action oder Func

und die einfachste Sache ist es, den Action oder Func Delegattyp explizit hinzuzufügen, damit F # die Überlastung korrekt auflöst. In diesem Fall denke ich,

Ändern

.ConnectionString(fun c -> ...) 

zu

.ConnectionString(Action<MsSqlConnectionStringBuilder>(fun c -> ...)) 

behebt es, und das ist oft die zweckmäßigste Weise entsperrt zu bekommen.

Answer 2

nicht sicher, warum, aber erklärt, die Art des Funktionsparameters funktioniert:

Fluently.Configure() 
     .Database(MsSqlConfiguration.MsSql2008 
      .ConnectionString(fun (c: MsSqlConnectionStringBuilder) -> c.FromConnectionStringWithKey("connectionString") |> ignore) 
       .ShowSql()) 

Wie auch immer, werden Sie besser dran # mit FunctionalNHibernate statt FluentNHibernate in F.