私はこれを数週間調査してきましたが、解決策を見つけるのに苦労しています。ここにやや一般的な質問を投稿して、洞察を得たいと思っていました.
リソース (.xlsm) を埋め込んだクラス ライブラリ (この場合は .xll) があります。ご存じないかもしれませんが、.xll は Excel に関連付けられているため、誰かが .xll を開くと、Excel のインスタンスに読み込まれます。私のシナリオでは、その .xll が Excel に読み込まれると、.xll は埋め込まれた .xlsm のコピーを読み込みます。ここまでは順調ですね。これにより、すべての意図と目的から見て、職場のエンド ユーザーに対して単に見慣れない Excel ファイルのように見えるものを送信することができます。
問題は、ユーザーが Excel シートに加えた変更を保存できるようにしたい場合に発生します。デスクトップに保存すると (保存機能に組み込まれた Excel を使用)、保存されるのは .xlsm だけです。その .xlsm を再度開くと、.xll は読み込まれなくなり、.xlsm に含まれる .NET 機能は機能しなくなります。
この時点で、おそらくいくつかの疑問が生じます。まず、.xll をシステムに登録しないのはなぜですか? 主な理由は、.xll を登録した場合、誰かが Excel を開くたびに .xll が開くためです。これは、埋め込まれた .xlsm も開くことを意味します (.xll が起動時に行うことを覚えておいてください)。 ... :-)。
次に、両方のファイルを送信してみませんか? 回答: エンド ユーザーにとって混乱が多すぎます (これについてはご容赦ください)。好きか嫌いかは別として、彼らは 1 つのファイルを開いてから変更することを望んでいます。彼らにとって、.xll は .xlsm の別のバージョンにすぎません。私は、自分自身を説明するのがはるかに簡単になるので、その認識を維持することを望んでいます。
最後に、グループ全体に .xll を配布し、それに対して .xlsms をリリースしないのはなぜですか? 回答: これらの .xlls は、ユーザーが自分のマシンに何を持っているかを制御できないランダムな場所に送信されるため、自己完結型にすることを好みます。
頭に浮かぶ2つの基本的な解決策があります。
オプション 1は、.xlsm から (おそらく .xll のインスタンスを介して) その場で .xll を単純に再コンパイルする方法を見つけ出し、その .xll をユーザーが選択した場所に保存することです。これには、独自の保存方法を作成する必要があります。これは、Excel では役に立たないためです。おそらく、保存時にユーザーが行った作業を傍受して、独自の保存方法にリダイレクトできるようにする必要があります。問題は、.xll 自体を再コンパイルする方法がわからないことです。特に、必ずしも SDK が搭載されていないマシンに .xll を送信するためです。それに加えて、ユーザーに独自の保存方法を強制することは、別の望ましくない混乱になります (少なくとも私の意見では...)。
オプション 2は、実行可能ファイルとして機能するアセンブリを作成することです。基本的に、.xlsm と .xll が含まれ、実行可能ファイルは Excel をロードしてから .xll を適用します。実行可能ファイルが管理者権限を必要としない限り、通常の古いファイルの代わりにそれらを送信しても問題ないと思います (ここにいるほとんどの人はとにかく拡張子を見ることさえありません。正しいアイコンが付いているため、ほとんどの人はできません。違いを教えてください）。唯一の問題は、リソース ファイルを使用せずに .xlsm をアセンブリにリンクし、.xlsm をバイトコードに変換する方法がわからないことです。これは基本的に私たちを振り出しに戻します。
本質的に、オプション 1 では、外部マシンでコンパイルする方法を理解する必要があり、オプション 2 では、.xlsm 全体を変更して元の場所に戻す方法を理解する必要があります... または少なくとも実行可能ファイルが簡単に見つけられる場所に配置します。
とにかく、ここまで来てくれたなら、永遠の感謝を捧げます。次にどこを見るべきかを見つけようとして立ち往生しているだけで、誰かが私を正しい方向に向けることができることを望んでいます。
前もって感謝します。