Friendly.Windows.2.15.0(.NetCore対応その2)をリリースしました。

前回のリリースでCore対応をしたのですが、.NetCoreへのアタッチの仕方が微妙やったんですよね。WindowsAppFriendのコンストラクタにcoreclr.dllのフルパスを渡すという鬼仕様。
ishikawa-tatsuya.hatenablog.com
この方法での問題は以下のもの。

対象が.NetCoreアプリかどうか判別する
coreclr.dllのパスの特定

対象アプリのロードしてるdllを取得することで解決

どうしようかなーって思ってたら、@tmytが「ホストプロセスが読み込んでるモジュール列挙で解決できるきがする」って教えてくれました。サンプルコードも書いてくれた。あざっす！
detect_netcore.cs · GitHub

この手法で対象プロセスにcoreclr.dllが読み込まれているか否かが判定できて、かつcoreclr.dllのパスが取得できるので問題が両方解決しました。

.NetFrameworkのアプリと全く同じコード

こんな感じで全く同じコードで書けるようになりました。やったね。

[TestCase]
public void TestCore()
{
    //普通にプロセス取得
    var targetApp = Process.GetProcessesByName("TestTargetCore")[0];

    //普通にアタッチ
    var app = new WindowsAppFriend(targetApp);

    //普通に操作
    var w = app.Type<Application>().Current.MainWindow;
    w.Title = "タイトル変更";

    //RM.Friendly.WPFStandardControlsとかも利用可能
    var textBox = new WPFTextBox(w._textBox);
    textBox.EmulateChangeText("abc");
}

Friendly.Windows.Grasp.2.12.0もリリースしました。

もちろん他のも更新してバージョンあげてリリースしたんですけど（超めんどい）Friendly.Windows.Graspは修正もしました。問題があったのです。

.NetCoreでサポートされないメソッド

いやいや、.NET Portability Analyzer でチェックしたら100%やったやん・・・
f:id:ishikawa-tatsuya:20190820162310p:plain

ダメだったのはこれ。故あって対象アプリ内でソースコードからコンパイルしてる部分があったんですけど、まあそりゃ.NetCoreではRoslynつかうよね・・・。

public static CompilerResults Compile(string[] reference, string code)
{
    if (reference == null)
    {
        throw new ArgumentNullException("reference");
    }
    CSharpCodeProvider codeProvider = new CSharpCodeProvider();
    CompilerParameters param = new CompilerParameters();
    param.GenerateInMemory = true;
    for (int i = 0; i < reference.Length; i++)
    {
        param.ReferencedAssemblies.Add(reference[i]);
    }
    param.IncludeDebugInformation = true;

    //ここで例外 System.PlatformNotSupportedException
    return codeProvider.CompileAsemblyFromSource(param, code);
}