1度#nowarnしちゃうと、その行以下のファイル全体に対して影響が及んでしまう(イケていない)ので。ファイル内で再び警告を有効化できるように対応してもらいたいですね(はよ!)。↓このあたりの話ですね。こんな感じのアクティブパターンでがんばります?になるのかな。諸兄の中で不完全なパターンマッチを絶対コロスマンの人ってどのくらいいるのでしょう。以下のような感じにコンパイルオプションでこの警告をコンパイルエラーに設定してる人のことです。listで最初に渡ってくるヤツがソレなので。Quotations.Expr.Coerceを用いて強制的に適切な型にキャストしてあげればよいです。この方法で生成しようとしている型のインスタンスに対してコネコネ操作することができます。Microsoft.CSharp.CSharpCodeProviderを使用して、IsValidIdentifier(有効な識別子かどうか)など厳密にチェックするような実装を検討してもいいかもしれません。parameterをすべて省略したときのやり方のやーつ静的パラメータありのTypeProviderで、すべての静的パラメータを省略できることをサポートするためには、渡されるすべてのProvidedStaticParameterについて、省略された場合の既定値を設定しておいてあげればよいです。GTWSP2.Method_省略されたよ()という感じで、静的パラメータをすべて省略可能なTypeProviderを作ることもできますのでご活用ください。お役立ち情報ではないうえ、知ってた速報!かもしれませんが。コンストラクタで呼び出すには、ProvidedConstructorのBaseConstructorCallでよしなに処理してあげればよいです。[top])とゆー感じで書けるます。プロパティーを生やす場合の実装方法として、返却する値はリフレクションを使ってプロパティに突っこんでおけばええやん!説が、私の中では割と正義だったのですが。onlyなプロパティで返してあげるように実装してあげる方がキレイなのかな。思い直している今日この頃です。力強くリフレクションで済ませてしまう方が実装楽ではあります(雑にそう書いてもバチはあたらないでしょう!)。把握してうまく活用することで、TypeProviderでできることの幅がぐんと広がるかと思います。↓を参照してください。(F#)少しだけ例を紹介しようかなとも思いましたが、長くなるので雑にリンクだけ貼っておきます(読めば察せると思いますので!)。これがサポートされると...、もうやりたい放題!!ですね。消去型のTypeProviderにおいてはまったく意識する必要はないのですが、生成型のTypeProviderでは意識すべき内容です。HogeTypeProvider<"Piyo">上記のように1つのTypeProviderを用いて複数の異なる型を生成する。こんな当たり前(そう)なことが、生成型のTypePrpviderにおいては、そうできるように実装を考慮をしていないと実現できません。考慮せずに実装した場合は、たとえばおおよそ以下のような感じのエラーが出てしまい、ほげーーーっと剥げてしまいます。例外がスローされました。1このようなエラーを回避するには、TypeProviderの各ルートタイプに対して個別の一時アセンブリを作成してあげる必要があります。この考慮が割と忘れがちになります(TypeProvider実装考慮漏れあるある)。生成型のTypeProviderを作るときのお決まりのパターンというか、ある種嗜みのようなものかなと思いますので、覚えておいて損はないかと思います。やり方については以下を参照してもらえればよいかと思います。ファイルを参照してくれない件についてTypeProviderが参照するDLLからConfigurationManagerを使用してapp.configから情報を取得しようとした場合、われわれが期待するapp.configを参照してくれないことがある!とゆ-残念無念な問題があります。configファイルを対象として動作してしまうのが原因です(どーしよーもない)。devenv.exe(VisualSudio)からみたconfigは、われわれが期待するソレではなく、以下のようないわゆるVisualStudioの在り処にあるconfigファイルを対象に動作します(これはひどい罠)。14.0\Common7\IDE\devenv.exe.configTypeProviderから参照されるDLLからConfigurationManagerを用いて、適切にわれわれが期待するapp.configを読み込みたいケースでは、なんらかの方法で対象のPathをConfigurationManagerに直接指定せざるを得ないです。この問題にぶちあたるケースの方がよっぽどレアケース説!がありすぎて。誰の役にも立たない情報かもしれません。Mavnn(@mavnn)さんがまとめてくださっているので、くわしくはそちらをご参照ください!(THE丸投げ)。Providersとかなんとか何やら興味深い記述が。リポジトリにある以下の3つのファイルを追加すれば利用できるとのこと。ProvidedTypesContext.fsこれ、実はPaketやNuGetを介して最新版を取得しても、まったく降ってこないんですよね。気づきにくい(!)軽い気持ちでコードを読もうとしても黒魔術すぎてわたしのような雑魚にはぶっちゃけわけわかめ(難しい)なんですが、AssemblyReader.fsは軽量.NETアセンブリリーダー、AssemblyReaderReflection.fsはディスク上のアセンブリに対するリフレクションオブジェクトの実装。ProvidedTypesContext.fsは、mscorlibまたはSystem.RuntimeのDLLが見つからないような環境下において、軽量.NETアセンブリリーダーを使用してよしなにCross-Targeting対応してくれるやーつみたいな感じなのかな。これの使い方自体は簡単で。ProvidedTypesContext.Create(config)そのコンテキスト経由で各種Providedほげもげを生成してTypeProviderを構成していけばよいみたいです。typeof<obj>)実装構成によっては割と面倒くさいことになり兼ねない感じがプンプンします(が、そんなときはReaderモナドとかでうまいこと乗り切ってください(察し))以下あたりも読んでおきましょうかね。Providersということで、とりとめもなくTypeProviderに関する小ネタをいくつか書いてみました。時間切れ)たところで終わります。あとで書くかものやつは、書かない可能性が高そうですが大目に見てください(誰かが書いてくれてもいい)。ところで、TypeProviderは、弊社次期タイトル「黒騎士と白の魔王」でもガチで使用されています。リリースされましたら、そのあたりにも注目してみてください(まったく表に出てきませんので注目のしようがありませんが!)。どのように使われているのかについてお話する機会が持てるかどうかはわかりませんが。その時は面白い話もできるかもしれません。書きましたが、何かひとつでも参考になれば幸いです。不変オブジェクトのすゝめ。月別アーカイブ参加グループプログラミング。