|
■No99297 (くま さん) に返信
> 説明不足ですみません。
>
> VSTOはふつうのvb.net Windowsフォームで作成される「\bin\Debug」とは別に
> 「System.Reflection.Assembly.GetExecutingAssembly().Location」の場所に実行dllを配置
> 実際動かしているのが「System.Reflection.Assembly.GetExecutingAssembly().Location」にあるdllだそうです。
> パスは自動生成の為一度コードを実行してパスを確認してもらいたかったのです。
>
> また関連するdllやexeは先で書いた階層ごとにインストールされ管理するそうですが
> 本来なら「WebView2Loader.dll」をコピーしなければならない所、先の例の「\bin\Debug\ExcelVSTOTest.dll」の直下に存在しない為
> 自動コピーされず「WebView2Loader.dll」が存在しませんとなっています。
そうではありません。
runtimes以下のフォルダ並びにWebView2Loader.dllは\bin\Debug\からWebView2Loader.dllを呼ぶメソッドが正常に相対パスを判断できる場所にあるのに存在しないとなってます。
確かに、自動コピーであるところを「実際動かしている」箇所に手動コピーしたら、「存在しない」は解消されますが、結局はアクセス拒否で読めません。
VSTOに配置したWinforms(実際はActiveXのラッパーみたいですが)からの起動の時のみそういう異常現象が起きる状態です。
なので、「存在しません」になっている原因追求としては有益ですが、根本問題解決としては無意味です。
> まず「WebView2」が動くことを前提に確認して
>
> インストール用のファイル設定等で「WebView2Loader.dll」をその場所へコピーできればその方法でも良いし
> また全体的にインストール環境を変えてしまえればそれでも良いし
読める場所にコピーしたら、アクセス拒否になるのでそれは問題の解決にはなりません。
> もしそれもできないのであれば別に前にお話ししたWebView2をCOMオブジェクトとして作成して参照設定で操作は実績もありますよ。
> VSTOからそのCOMオブジェクトを参照して動作するようにすれば配置の問題もなくなりますよね？
他の方に紹介してもらったデコンパイルツールでWebView2Loader.dllをCallしてる箇所のロジックを確認したところ、
そのメソッドでCoreWebView2EnvironmentがドットネットであるというIf文が存在してたので、この辺りが悪さしてる可能性があります。
なので、内部的にはCOMであろうVSTOからCOM参照すればいいだろうというのはその通りかもしれませんが、
そうであればその時点が外部参照なので別プロジェクトのExeをCallするのとほぼ変わりません。手間はむしろ多いです。
結局のところ、同一プロジェクト内から呼べないのが、不具合もしくは仕様制限であるのならば、そうと判断できる材料を知りたいんですよ。
それがわかれば、外部参照に方針は切り替えます。
|