C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[17]: .NetVBからのmshtml参照


(過去ログ 42 を表示中)

[トピック内 24 記事 (1 - 20 表示)]  << 0 | 1 >>

■21847 / inTopicNo.1)  .NetVBからのmshtml参照
  
□投稿者/ らんぺるーる (1回)-(2008/07/10(Thu) 22:41:21)

分類:[.NET 全般] 

VisualStudil2005の「VB.Net」での「Microsoft.mshtml.dll」の
使用方法について質問があります。

「.NetFrameWork2.0」には「Microsoft.mshtml.dll」が含まれていないため、
アプリケーションから「Microsoft.mshtml.dll」を使用する場合は
アプリケーションと一緒に配布するか、または「Microsoft.mshtml.dll」の使用をやめて
直接COMを参照する対処があるということは、インターネットで調べました。
(「参照の追加」では「.Net」に分類されている為、アプリケーションに同封せず、
「.NetFrameWork2.0」をインストールしただけの試験環境で動作させたら
「Microsoft.mshtml.dll」を参照することができず、
エラーが発生したので、はいっていないことにはじめて気づきました。
「.Net」に分類されているdllで.「NetFrameWork2.0」に入っていないものは
他にあるんですか??余談で申し訳ないですが、はいっているdllととはいっていないdllの
識別方法等ご存知あればこちらも教えてください。)

悩んだ結果、コーディングの難易度が高そうであるのと、
プログラムの可読性を考慮して、dllを同封することにしました。
(圧縮したら1.2M程度になりました。)

そこで、質問はdllのインストール先についてとなります。
開発したアプリケーションと同じフォルダに配置すべきか、
「C:\Program Files\Microsoft.NET\Primary Interop Assemblies」
に配置すべきかわかりません。

「参照設定」の「パス」プロパティで「C:\Program Files\Microsoft.NET\Primary Interop Assemblies」
が指定されていたので、試験環境でも上記フォルダに格納したのですが、
うまく参照できないようです。(試験環境も「RegAsm」によるレジストリ登録はおこなっています。)
アプリケーションと同じフォルダに配置した場合は、正常に動作しました。

上記の結果をみる限り、アプリケーションと同じフォルダに配置すれば何も問題がないですが、
いくつか懸念事項があります。

もう一つ別に「Microsoft.mshtml.dll」を参照するアプリケーションを作成し、
「Microsoft.mshtml.dll」をアプリケーションと同じフォルダに配置します。

そして両方の「Microsoft.mshtml.dll」についてレジストリ登録をおこなうと、
両方のアプリケーションが動作可能です。

ただし、片方の「Microsoft.mshtml.dll」についてレジストリ解除をおこなうと、
両方のアプリケーションが動作しなくなります。

せっかくアプリケーションと同じフォルダに配置をしても
他のアプリケーションの影響を受けるのであれば、要領の関係からしても
「C:\Program Files\Microsoft.NET\Primary Interop Assemblies」
に配置したほうが良いのではないかと思いました。

他のアプリケーションのレジストリ解除の影響を受けないようにすることは可能なのでしょうか。

どのようなdll配置,レジストリ登録をおこなうのが「.Net」として良いのか
教えていただきたいです。
「.Net」の基礎についての質問かもしれませんが、よろしくお願いします。

*レジストリ登録には「RegAsm」を使用しています。
*「Microsoft.mshtml.dll」のバージョンは両方とも「7.0.3300.0」です。






引用返信 編集キー/
■21849 / inTopicNo.2)  Re[1]: .NetVBからのmshtml参照
□投稿者/ 魔界の仮面弁士 (783回)-(2008/07/10(Thu) 23:32:07)
No21847 (らんぺるーる さん) に返信
> 「.NetFrameWork2.0」には「Microsoft.mshtml.dll」が含まれていないため、
(FrameWork ではなく Framework かと)

完全な資料とはなりえませんが、下記のようなページがあります。
http://support.microsoft.com/dllhelp/

[ファイルのみ], [English (United States)] にして「Microsoft.mshtml.dll」を
検索すると、この DLL を同梱している製品の一覧が表示されます。

それによると、Microsoft.mshtml.dll は、Visual Studio シリーズに
含まれているようですね。という事はもしかしたら、
.NET Framework 2.0 再頒布可能パッケージには含まれていないが、
.NET Framework SDK 2.0 には含まれている、という代物なのかも。


> 「.Net」に分類されているdllで.「NetFrameWork2.0」に入っていないものは
> 他にあるんですか??

VSTO 付属の DLL や J#2005 の DLL の一部が該当するようです。
また、Visual Studio によって自動生成される相互運用機能アセンブリも。

あとは、.NET Framework 各国語版 Language Pack 内の *.resources.dll なども、
.NET Framework 本体とは別の配布物となっていますね。


> 「C:\Program Files\Microsoft.NET\Primary Interop Assemblies」
> に配置したほうが良いのではないかと思いました。

このあたりを入れてもらう事で、配置されないでしょうか。(未確認)
http://support.microsoft.com/kb/897646
引用返信 編集キー/
■21865 / inTopicNo.3)  Re[2]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (3回)-(2008/07/11(Fri) 10:20:17)
No21849 (魔界の仮面弁士 さん) に返信
> ■No21847 (らんぺるーる さん) に返信
>>「.NetFrameWork2.0」には「Microsoft.mshtml.dll」が含まれていないため、
> (FrameWork ではなく Framework かと)
>
> 完全な資料とはなりえませんが、下記のようなページがあります。
> http://support.microsoft.com/dllhelp/
>
> [ファイルのみ], [English (United States)] にして「Microsoft.mshtml.dll」を
> 検索すると、この DLL を同梱している製品の一覧が表示されます。
>
> それによると、Microsoft.mshtml.dll は、Visual Studio シリーズに
> 含まれているようですね。という事はもしかしたら、
> .NET Framework 2.0 再頒布可能パッケージには含まれていないが、
> .NET Framework SDK 2.0 には含まれている、という代物なのかも。
>
>
>>「.Net」に分類されているdllで.「NetFrameWork2.0」に入っていないものは
>>他にあるんですか??
>
> VSTO 付属の DLL や J#2005 の DLL の一部が該当するようです。
> また、Visual Studio によって自動生成される相互運用機能アセンブリも。
>
> あとは、.NET Framework 各国語版 Language Pack 内の *.resources.dll なども、
> .NET Framework 本体とは別の配布物となっていますね。
>
>
>>「C:\Program Files\Microsoft.NET\Primary Interop Assemblies」
>>に配置したほうが良いのではないかと思いました。
>
> このあたりを入れてもらう事で、配置されないでしょうか。(未確認)
> http://support.microsoft.com/kb/897646

DLL同封についてのご説明ありがとう御座いました。
リンク先の資料等拝見させて頂きます。

また、「Microsoft.mshtml.dll」の配置について記載が不十分でした、
失礼しました。
参照設定の「ローカルコピー」プロパティを「true」にして
生成した「Microsoft.mshtml.dll」を独自のインストーラーを作成して利用者に配布しますので、
「Microsoft.mshtml.dll」の入手等については問題にはしておりません。
「Microsoft.mshtml.dll」の配置場所、レジストリの登録等について分からず、困っております。






引用返信 編集キー/
■21972 / inTopicNo.4)  Re[3]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (4回)-(2008/07/14(Mon) 11:06:03)
No21865 (らんぺるーる さん) に返信
> ■No21849 (魔界の仮面弁士 さん) に返信
>>■No21847 (らんぺるーる さん) に返信
> >>「.NetFrameWork2.0」には「Microsoft.mshtml.dll」が含まれていないため、
>>(FrameWork ではなく Framework かと)
>>
>>完全な資料とはなりえませんが、下記のようなページがあります。
>>http://support.microsoft.com/dllhelp/
>>
>>[ファイルのみ], [English (United States)] にして「Microsoft.mshtml.dll」を
>>検索すると、この DLL を同梱している製品の一覧が表示されます。
>>
>>それによると、Microsoft.mshtml.dll は、Visual Studio シリーズに
>>含まれているようですね。という事はもしかしたら、
>>.NET Framework 2.0 再頒布可能パッケージには含まれていないが、
>>.NET Framework SDK 2.0 には含まれている、という代物なのかも。
>>
>>
> >>「.Net」に分類されているdllで.「NetFrameWork2.0」に入っていないものは
> >>他にあるんですか??
>>
>>VSTO 付属の DLL や J#2005 の DLL の一部が該当するようです。
>>また、Visual Studio によって自動生成される相互運用機能アセンブリも。
>>
>>あとは、.NET Framework 各国語版 Language Pack 内の *.resources.dll なども、
>>.NET Framework 本体とは別の配布物となっていますね。
>>
>>
> >>「C:\Program Files\Microsoft.NET\Primary Interop Assemblies」
> >>に配置したほうが良いのではないかと思いました。
>>
>>このあたりを入れてもらう事で、配置されないでしょうか。(未確認)
>>http://support.microsoft.com/kb/897646
>
> DLL同封についてのご説明ありがとう御座いました。
> リンク先の資料等拝見させて頂きます。
>
> また、「Microsoft.mshtml.dll」の配置について記載が不十分でした、
> 失礼しました。
> 参照設定の「ローカルコピー」プロパティを「true」にして
> 生成した「Microsoft.mshtml.dll」を独自のインストーラーを作成して利用者に配布しますので、
> 「Microsoft.mshtml.dll」の入手等については問題にはしておりません。
> 「Microsoft.mshtml.dll」の配置場所、レジストリの登録等について分からず、困っております。
>

本件についてどなたかご存知の方はいらっしゃらないでしょうか。
開発スケジュールの関係で、解決を急いでおります。
なにとぞよろしくお願いいたします。

引用返信 編集キー/
■21976 / inTopicNo.5)  Re[3]: .NetVBからのmshtml参照
□投稿者/ 魔界の仮面弁士 (784回)-(2008/07/14(Mon) 11:56:50)
No21865 (らんぺるーる さん) に返信
> 生成した「Microsoft.mshtml.dll」を独自のインストーラーを作成して
先の URL にあるパッケージ (O2003PIA.MSI) を Orca で眺めると、
Microsoft.mshtml.dll を GAC に登録されるように書かれているかのように
見えたのですが、このパッケージを利用して配布しても
>>> 両方のアプリケーションが動作しなくなります。
の問題を解決できないでいる、という事なのでしょうか。

もしも O2003PIA.MSI で大丈夫なようであれば、それをそのまま利用するか、
もしくは、それと同様の登録作業をマージモジュールに組み込んでおき、その msm を
「独自のインストーラー」から利用する事で対応できないのかな、と。


> 「Microsoft.mshtml.dll」の配置場所、レジストリの登録等について分からず、
> 困っております。
これは私も分かりません。当方では、すでに
C:\WINDOWS\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a\Microsoft.mshtml.dll
に配置済みになっていたため、先の O2003PIA.MSI による確認までは行っていないので…。


> 開発スケジュールの関係で、解決を急いでおります。
そのような状況であれば、インシデントを消費した方が良い結果が得られるかと思います。
引用返信 編集キー/
■21980 / inTopicNo.6)  Re[4]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (5回)-(2008/07/14(Mon) 14:56:31)
No21976 (魔界の仮面弁士 さん) に返信
> ■No21865 (らんぺるーる さん) に返信
>>生成した「Microsoft.mshtml.dll」を独自のインストーラーを作成して
> 先の URL にあるパッケージ (O2003PIA.MSI) を Orca で眺めると、
> Microsoft.mshtml.dll を GAC に登録されるように書かれているかのように
> 見えたのですが、このパッケージを利用して配布しても
> >>> 両方のアプリケーションが動作しなくなります。
> の問題を解決できないでいる、という事なのでしょうか。
>
> もしも O2003PIA.MSI で大丈夫なようであれば、それをそのまま利用するか、
> もしくは、それと同様の登録作業をマージモジュールに組み込んでおき、その msm を
> 「独自のインストーラー」から利用する事で対応できないのかな、と。
>
>
>>「Microsoft.mshtml.dll」の配置場所、レジストリの登録等について分からず、
>>困っております。
> これは私も分かりません。当方では、すでに
> C:\WINDOWS\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a\Microsoft.mshtml.dll
> に配置済みになっていたため、先の O2003PIA.MSI による確認までは行っていないので…。
>
>
>>開発スケジュールの関係で、解決を急いでおります。
> そのような状況であれば、インシデントを消費した方が良い結果が得られるかと思います。

回答ありがとう御座います。
パッケージ (O2003PIA.MSI)の利用については、Office関連のDLLが入っており、
今回必要な「Microsoft.mshtml.dll」以外のインストールされてしまうので、
適用を見送りたいです。

GAC(グローバルアセンブリキャッシュ)に登録することで、アプリケーションと
同じフォルダにDLLを配置しなくても参照可能なことは確認できました。

出来ればGACに登録する方法を適用したかったのですが、開発環境以外の配布方法は
「MicrosoftInstaller」を使用する方法以外は推奨しないと明記されており、
私のシステムでは「MicrosoftInstaller」を現在使用していないため、
GACに登録する方法も適用できません。


そこで、アプリケーションと同じフォルダに配置する方法で断念しようと思います。
「Microsoft.mshtml.dll」は独自開発のDLLではなく、他のアプリケーションでも使用
しそうなので、出来れば共通的な場所に配置し、GACへの登録をおこなって使用し、
プライベートフォルダには配置しないほうが一般的だとは思うのですが…。
引用返信 編集キー/
■21981 / inTopicNo.7)  Re[5]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (6回)-(2008/07/14(Mon) 15:03:04)
No21980 (らんぺるーる さん) に返信
> ■No21976 (魔界の仮面弁士 さん) に返信
>>■No21865 (らんぺるーる さん) に返信
> >>生成した「Microsoft.mshtml.dll」を独自のインストーラーを作成して
>>先の URL にあるパッケージ (O2003PIA.MSI) を Orca で眺めると、
>>Microsoft.mshtml.dll を GAC に登録されるように書かれているかのように
>>見えたのですが、このパッケージを利用して配布しても
>>>>> 両方のアプリケーションが動作しなくなります。
>>の問題を解決できないでいる、という事なのでしょうか。
>>
>>もしも O2003PIA.MSI で大丈夫なようであれば、それをそのまま利用するか、
>>もしくは、それと同様の登録作業をマージモジュールに組み込んでおき、その msm を
>>「独自のインストーラー」から利用する事で対応できないのかな、と。
>>
>>
> >>「Microsoft.mshtml.dll」の配置場所、レジストリの登録等について分からず、
> >>困っております。
>>これは私も分かりません。当方では、すでに
>>C:\WINDOWS\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a\Microsoft.mshtml.dll
>>に配置済みになっていたため、先の O2003PIA.MSI による確認までは行っていないので…。
>>
>>
> >>開発スケジュールの関係で、解決を急いでおります。
>>そのような状況であれば、インシデントを消費した方が良い結果が得られるかと思います。
>
> 回答ありがとう御座います。
> パッケージ (O2003PIA.MSI)の利用については、Office関連のDLLが入っており、
> 今回必要な「Microsoft.mshtml.dll」以外のインストールされてしまうので、
> 適用を見送りたいです。
>
> GAC(グローバルアセンブリキャッシュ)に登録することで、アプリケーションと
> 同じフォルダにDLLを配置しなくても参照可能なことは確認できました。
>
> 出来ればGACに登録する方法を適用したかったのですが、開発環境以外の配布方法は
> 「MicrosoftInstaller」を使用する方法以外は推奨しないと明記されており、
> 私のシステムでは「MicrosoftInstaller」を現在使用していないため、
> GACに登録する方法も適用できません。
>
>
> そこで、アプリケーションと同じフォルダに配置する方法で断念しようと思います。
> 「Microsoft.mshtml.dll」は独自開発のDLLではなく、他のアプリケーションでも使用
> しそうなので、出来れば共通的な場所に配置し、GACへの登録をおこなって使用し、
> プライベートフォルダには配置しないほうが一般的だとは思うのですが…。

追加で1点確認したいのですが、
GACに登録されている場合でもRegAsmによるレジストリ登録をおこなわないとdllは動作せず。
また、RegAsmでのレジストリ解除をおこなうとGACに登録されている場合でも参照することが
できないとう動作になるのでしょうか?


引用返信 編集キー/
■21992 / inTopicNo.8)  Re[5]: .NetVBからのmshtml参照
□投稿者/ 渋木宏明(ひどり) (823回)-(2008/07/14(Mon) 17:40:57)
渋木宏明(ひどり) さんの Web サイト
> >>開発スケジュールの関係で、解決を急いでおります。
>>そのような状況であれば、インシデントを消費した方が良い結果が得られるかと思います。

ですね。

> パッケージ (O2003PIA.MSI)の利用については、Office関連のDLLが入っており、
> 今回必要な「Microsoft.mshtml.dll」以外のインストールされてしまうので、
> 適用を見送りたいです。

.dll 単体での配布は認められていない場合もあるので、正規のルート(=公式文書を検索してみつけたり、サポートに連絡するなど)で配布条件を確認した方がいいですよ。

> GAC(グローバルアセンブリキャッシュ)に登録することで、アプリケーションと
> 同じフォルダにDLLを配置しなくても参照可能なことは確認できました。

RegAsm は不要なんですか?
RegAsm が必要な場合、結果的に GAC にも登録しないとダメな場合もあり得ます。

> 「MicrosoftInstaller」を使用する方法以外は推奨しないと明記されており、

Windows Insltaller じゃないすか?
用語は正確に。

> 「Microsoft.mshtml.dll」は独自開発のDLLではなく、他のアプリケーションでも使用
> しそうなので、出来れば共通的な場所に配置し、GACへの登録をおこなって使用し、
> プライベートフォルダには配置しないほうが一般的だとは思うのですが…。

GAC への登録が必要なものは必ずしないと駄目だし、GAC への登録が必要ないものをむやみに登録しては駄目です。
安易に GAC 登録を行うと、ひどい混乱を招くことがあります。

引用返信 編集キー/
■21997 / inTopicNo.9)  Re[6]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (9回)-(2008/07/14(Mon) 20:40:23)
No21992 (渋木宏明(ひどり) さん) に返信
>>>>開発スケジュールの関係で、解決を急いでおります。
> >>そのような状況であれば、インシデントを消費した方が良い結果が得られるかと思います。
>
> ですね。
>
>>パッケージ (O2003PIA.MSI)の利用については、Office関連のDLLが入っており、
>>今回必要な「Microsoft.mshtml.dll」以外のインストールされてしまうので、
>>適用を見送りたいです。
>
> .dll 単体での配布は認められていない場合もあるので、正規のルート(=公式文書を検索してみつけたり、サポートに連絡するなど)で配布条件を確認した方がいいですよ。

⇒了解しました、サービス開始まではまだ期間がありますので、正式な配布方法については継続調査を行う予定です。

>>GAC(グローバルアセンブリキャッシュ)に登録することで、アプリケーションと
>>同じフォルダにDLLを配置しなくても参照可能なことは確認できました。
>
> RegAsm は不要なんですか?
> RegAsm が必要な場合、結果的に GAC にも登録しないとダメな場合もあり得ます。

⇒RegAsmは必要でした。
 今回の調査では、「参照設定」の「ファイルの種類」プロパティが「アセンブリ」に設定されているファイルのうち、
 「.NetFramework2.0」に同封されていないファイルについては、レジストリ登録が必要であるという見解になりました。
 また、上記ファイルのうち、他のアプリケーションでも使用されるものをGACに登録し、
 それ以外のファイルについては、プライベートに配置をすれば良いのかと思っています。認識はあっているでしょうか?

>>「MicrosoftInstaller」を使用する方法以外は推奨しないと明記されており、
>
> Windows Insltaller じゃないすか?
> 用語は正確に。

 ご指摘のとおり、「MicrosoftInstaller」が正しいです。
 失礼しました。
>
>>「Microsoft.mshtml.dll」は独自開発のDLLではなく、他のアプリケーションでも使用
>>しそうなので、出来れば共通的な場所に配置し、GACへの登録をおこなって使用し、
>>プライベートフォルダには配置しないほうが一般的だとは思うのですが…。
>
> GAC への登録が必要なものは必ずしないと駄目だし、GAC への登録が必要ないものをむやみに登録しては駄目です。
> 安易に GAC 登録を行うと、ひどい混乱を招くことがあります。

 具体的な失敗談等御座いましたら、ぜひお聞かせください。
>
引用返信 編集キー/
■21998 / inTopicNo.10)  Re[7]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (10回)-(2008/07/14(Mon) 20:42:50)
ご指摘のとおり、「MicrosoftInstaller」が正しいです。
⇒ご指摘のとおり、「Windows Insltaller」が正しいです。
の誤りですね。2度も間違えてしまいました…。
引用返信 編集キー/
■22007 / inTopicNo.11)  Re[7]: .NetVBからのmshtml参照
□投稿者/ 渋木宏明(ひどり) (824回)-(2008/07/15(Tue) 01:25:58)
渋木宏明(ひどり) さんの Web サイト
>  また、上記ファイルのうち、他のアプリケーションでも使用されるものをGACに登録し、
>  それ以外のファイルについては、プライベートに配置をすれば良いのかと思っています。認識はあっているでしょうか?

基本的な考え方としては、そう間違ってはいません。

ですが、GAC 登録したアセンブリをバージョンアップすると、その影響はそのアセンブリを利用しているアプリケーションすべてに及びます。

共有アセンブリに対して変更を加えた時に、それを利用するすべてのアプリケーションのテストが行えるなら問題はありませんが、それが不可能な場合等は無理に GAC に登録せず、各アプリケーション毎に最適なバージョンのアセンブリをプライベートアセンブリとして配置する、という選択もありえます。

>>安易に GAC 登録を行うと、ひどい混乱を招くことがあります。
>
>  具体的な失敗談等御座いましたら、ぜひお聞かせください。

混乱を招くことが事前に分かっているので、.NET では失敗してません。

危なそうなプロジェクトは1個ありますが、それは僕が管理しているやつじゃないので警告してオシマイ。

引用返信 編集キー/
■22089 / inTopicNo.12)  Re[8]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (11回)-(2008/07/15(Tue) 16:38:35)
No22007 (渋木宏明(ひどり) さん) に返信
>> また、上記ファイルのうち、他のアプリケーションでも使用されるものをGACに登録し、
>> それ以外のファイルについては、プライベートに配置をすれば良いのかと思っています。認識はあっているでしょうか?
>
> 基本的な考え方としては、そう間違ってはいません。
>
> ですが、GAC 登録したアセンブリをバージョンアップすると、その影響はそのアセンブリを利用しているアプリケーションすべてに及びます。

「.Net」以前に使用していた「System32」フォルダについては、ファイル自体を格納する為、ファイル名が同じ場合は「上書き」となるため、バージョンアップした場合は、
ファイルを使用している全てのアプリケーションに影響が及びますが、
「GAC」に登録する場合は厳密な名前を指定されているのが前提となっており、同じファイル名でもバージョンによる管理が出来ている為、バージョンアップによる影響は受けないと思っておりました。
また、アプリケーションから参照する場合も、ファイル名が同じでも、「厳密な名前」で識別をしている為、異なるバ−ジョンのファイルは参照しないと思っていたのですが。
いかがでしょうか。




引用返信 編集キー/
■22098 / inTopicNo.13)  Re[9]: .NetVBからのmshtml参照
□投稿者/ 渋木宏明(ひどり) (825回)-(2008/07/15(Tue) 17:07:42)
渋木宏明(ひどり) さんの Web サイト
> 「GAC」に登録する場合は厳密な名前を指定されているのが前提となっており、

あれ? 厳密名って必須でしたっけ?
署名だけが必須と勘違いしてました。

とすれば

>同じファイル名でもバージョンによる管理が出来ている為、バージョンアップによる影響は受けないと思っておりました。

です。

が、複数バージョンを並行してメンテしなくてはならない可能性が増えるので、やはり個人的にはあまり積極的には勧めません>GAC 登録

引用返信 編集キー/
■22105 / inTopicNo.14)  Re[10]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (12回)-(2008/07/15(Tue) 18:53:44)
No22098 (渋木宏明(ひどり) さん) に返信
>>「GAC」に登録する場合は厳密な名前を指定されているのが前提となっており、
>
> あれ? 厳密名って必須でしたっけ?
> 署名だけが必須と勘違いしてました。
>
> とすれば
>
> >同じファイル名でもバージョンによる管理が出来ている為、バージョンアップによる影響は受けないと思っておりました。
>
> です。
>
> が、複数バージョンを並行してメンテしなくてはならない可能性が増えるので、やはり個人的にはあまり積極的には勧めません>GAC 登録
>

⇒了解致しました。

まだまだ、アセンブリ登録や配置については、教えて頂きたいことが多いですが、
今回の質問については、解決出来ましたので、一旦このスレはクローズさせて頂きます。


渋木宏明(ひどり) 様、魔界の仮面弁士 様、お忙しい所、ご回答有難う御座いました。

解決済み
引用返信 編集キー/
■22152 / inTopicNo.15)  Re[10]: .NetVBからのmshtml参照
□投稿者/ 渋木宏明(ひどり) (826回)-(2008/07/16(Wed) 10:31:32)
渋木宏明(ひどり) さんの Web サイト
もう1個 GAC 登録のイヤな点思い出した。

> >同じファイル名でもバージョンによる管理が出来ている為、バージョンアップによる影響は受けないと思っておりました。
>
> です。

ですが、逆に共有アセンブリにバグが見つかった場合、最悪、そのアセンブリを使用しているアプリケーションすべてを更新しなければならないです。
引用返信 編集キー/
■22560 / inTopicNo.16)  Re[11]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (15回)-(2008/07/25(Fri) 17:26:32)
No22152 (渋木宏明(ひどり) さん) に返信
> もう1個 GAC 登録のイヤな点思い出した。
>
>>>同じファイル名でもバージョンによる管理が出来ている為、バージョンアップによる影響は受けないと思っておりました。
>>
>>です。
>
> ですが、逆に共有アセンブリにバグが見つかった場合、最悪、そのアセンブリを使用しているアプリケーションすべてを更新しなければならないです。

すみません、追加でアドバイスを頂いていたのを確認しておりませんでした。
以下のような状況をさしているのでしょうか。

・アセンブリファイル名「Asem1」
・格納場所「C:\Program Files\Microsoft.NET\Primary Interop Assemblies\Asem1」
・GAC登録したアセンブリ「Asem1(Ver1.0)」
・GAC登録したアセンブリ「Asem1(Ver1.1)」←バグ改修版です。

アプリA⇒GACの「Asem1(Ver1.0)」を参照
アプリB⇒GACの「Asem1(Ver1.0)」を参照
アプリC⇒プライベートの「Asem1(Ver1.0)」を参照

この場合、GAC登録自体は「Asem1(Ver1.0)」「Asem1(Ver1.1)」」両方がありますが、
両バージョンともファイル格納先、ファイル名が同じ為、ファイルの上書きとなり、
「Asem1(Ver1.0)」はGACから参照できなくなり、アプリA,アプリBは動かなくなります。
ただし、プライベートに配置したアプリCは動作します。

*このことを考えると、GAC登録の意味はほとんどありません。
 バージョンアップの影響をもろに受けます。
 (たしか、GAC登録は、System32とちがい、バージョンが違う場合は
  読み込まないという動作をするといった説明を読んだ記憶がありますのでより状況は悪化するかもしれません。)
 バージョン毎にファイル名を変えるかフォルダの格納先を変える必要があるのであれば、
 System32時代とほとんどかわらない気がします?
 やはりプライベート配置を基本としたほうが良いということなのでしょうか。

*アドバイスいただいた内容と解釈が違う場合は、コメントをくださいませ。







引用返信 編集キー/
■22564 / inTopicNo.17)  Re[12]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (16回)-(2008/07/25(Fri) 18:30:22)
No22560 (らんぺるーる さん) に返信
> ■No22152 (渋木宏明(ひどり) さん) に返信
>>もう1個 GAC 登録のイヤな点思い出した。
>>
> >>>同じファイル名でもバージョンによる管理が出来ている為、バージョンアップによる影響は受けないと思っておりました。
> >>
> >>です。
>>
>>ですが、逆に共有アセンブリにバグが見つかった場合、最悪、そのアセンブリを使用しているアプリケーションすべてを更新しなければならないです。
>
> すみません、追加でアドバイスを頂いていたのを確認しておりませんでした。
> 以下のような状況をさしているのでしょうか。
>
> ・アセンブリファイル名「Asem1」
> ・格納場所「C:\Program Files\Microsoft.NET\Primary Interop Assemblies\Asem1」
> ・GAC登録したアセンブリ「Asem1(Ver1.0)」
> ・GAC登録したアセンブリ「Asem1(Ver1.1)」←バグ改修版です。
>
> アプリA⇒GACの「Asem1(Ver1.0)」を参照
> アプリB⇒GACの「Asem1(Ver1.0)」を参照
> アプリC⇒プライベートの「Asem1(Ver1.0)」を参照
>
> この場合、GAC登録自体は「Asem1(Ver1.0)」「Asem1(Ver1.1)」」両方がありますが、
> 両バージョンともファイル格納先、ファイル名が同じ為、ファイルの上書きとなり、
> 「Asem1(Ver1.0)」はGACから参照できなくなり、アプリA,アプリBは動かなくなります。
> ただし、プライベートに配置したアプリCは動作します。
>
> *このことを考えると、GAC登録の意味はほとんどありません。
>  バージョンアップの影響をもろに受けます。
>  (たしか、GAC登録は、System32とちがい、バージョンが違う場合は
>   読み込まないという動作をするといった説明を読んだ記憶がありますのでより状況は悪化するかもしれません。)
>  バージョン毎にファイル名を変えるかフォルダの格納先を変える必要があるのであれば、
>  System32時代とほとんどかわらない気がします?
>  やはりプライベート配置を基本としたほうが良いということなのでしょうか。
>
> *アドバイスいただいた内容と解釈が違う場合は、コメントをくださいませ。

⇒GAC登録後に「C:\Program Files\Microsoft.NET\Primary Interop Assemblies\Asem1」
 のファイルを削除した場合でも「Asem1」を参照することができました。
 キャッシュという名前ですし、GACに登録した時点で登録に使用したファイルは参照しなくても動作可能なのでしょうか。
 であれば、バージョンも識別してくれるので「GAC」登録は非常に有効な気がします。
 ご指摘いただいたバージョンアップによる問題も起きないのではないでしょうか?

 アセンブリロードまでの流れを分かりやすく解説しているページがあったので紹介いたします。
 <http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_index/idnfw11_l.jpg>
 *ここのHPでも「GAC」による登録は不要であると言い切っています。
 *ただ、「.NET Frameworkではレジストリを使わなくてよくなった」とレジストリ登録が不要なことが
  頻繁に書かれているのですが、実際には「RegAsm」によるレジストリ登録をおこなわないと動作しないと思うのですが。
  どうなっているのでしょうか…。


引用返信 編集キー/
■22565 / inTopicNo.18)  Re[12]: .NetVBからのmshtml参照
□投稿者/ 渋木宏明(ひどり) (835回)-(2008/07/25(Fri) 18:31:09)
渋木宏明(ひどり) さんの Web サイト
まず

> アプリA⇒GACの「Asem1(Ver1.0)」を参照
> アプリB⇒GACの「Asem1(Ver1.0)」を参照
> アプリC⇒プライベートの「Asem1(Ver1.0)」を参照

という状況があってよいものかどうか疑問です。

開発環境とかの特殊な場合を除いて、GAC に配置されるべきアセンブリなら、GAC から「のみ」参照されるべきでわ。



>ですが、逆に共有アセンブリにバグが見つかった場合、最悪、そのアセンブリを使用しているアプリケーションすべてを更新しなければならないです。

というのは、もっと単純な話で

アプリA⇒GACの「Asem1(Ver1.0)」を参照
アプリB⇒GACの「Asem1(Ver1.0)」を参照

の時、仮にアプリA使用中にAsem1(Ver1.0)のバグが見つかったら

・Asem1(Ver1.1)を作成
・Asem1を利用するようにアプリAを改定

となりますが、同時に

・Asem1を利用するようにアプリBを改定

の検討をしなければならないのでは?ということです。

>たしか、GAC登録は、System32とちがい、バージョンが違う場合は読み込まない

アセンブリに「強い名前」をつけた時点でそーだったような。

>バージョン毎にファイル名を変えるかフォルダの格納先を変える必要があるのであれば、

異なるバージョンのアセンブリを共存させたい(=古いバージョンに不具合があったとしても)なら、バージョン毎に異なるフォルダに配置するべきでしょうね。

引用返信 編集キー/
■22568 / inTopicNo.19)  Re[13]: .NetVBからのmshtml参照
□投稿者/ らんぺるーる (17回)-(2008/07/25(Fri) 18:58:34)
すみません、アセンブリを検索にいく順位があるので↓はありえないですね。

>アプリA⇒GACの「Asem1(Ver1.0)」を参照
>アプリB⇒GACの「Asem1(Ver1.0)」を参照
>アプリC⇒プライベートの「Asem1(Ver1.0)」を参照

アプリA⇒プライベートに「Asem1(Ver1.0)」を配置せず(GACの「Asem1(Ver1.0)」を参照)
アプリB⇒プライベートに「Asem1(Ver1.0)」を配置せず(GACの「Asem1(Ver1.0)」を参照)
アプリC⇒プライベートに「Asem1(Ver1.0)」を配置する(GACの「Asem1(Ver1.0)」を参照)

この場合ですとアプリCは、「Asem1」ファイルの上書きの影響を受けないということが言いたかったのですが、
当然、同じ会社のアプリ間では統一した方がいいと思います。
ただし、他の会社が作成したアプリが参照するアセンブリが同じもので、かつGAC登録してきた場合を考えると
上記のようなことは起こりえるかもしれないです。

>・Asem1を利用するようにアプリBを改定の検討をしなければならないのでは?ということです。
⇒上記の内容は、GAC登録と関係があるのでしょうか?
 参照する「Asem1」がバージョンアップした場合は、「GAC」を参照しようが、プライベート配置にしようが、
 アプリBにバージョンアップ版の「Asem1」を適用するかの判断は必要ではないでしょうか?
 
>>たしか、GAC登録は、System32とちがい、バージョンが違う場合は読み込まない
>アセンブリに「強い名前」をつけた時点でそーだったような。
⇒そうですね!GAC登録は関係ないです。

>>バージョン毎にファイル名を変えるかフォルダの格納先を変える必要があるのであれば、
>異なるバージョンのアセンブリを共存させたい(=古いバージョンに不具合があったとしても)なら、バージョン毎に異なるフォルダに配置するべきでしょうね。
⇒Re[12]:に記載したのですが、「GAC」に登録した場合は、元のファイルが不要なようです。登録時間もすごく短いですし、キャッシュされているとは思えませんが
 うーむ。



引用返信 編集キー/
■22569 / inTopicNo.20)  Re[13]: .NetVBからのmshtml参照
 
□投稿者/ 渋木宏明(ひどり) (836回)-(2008/07/25(Fri) 19:21:10)
渋木宏明(ひどり) さんの Web サイト
2008/07/25(Fri) 19:23:00 編集(投稿者)

> ⇒GAC登録後に「C:\Program Files\Microsoft.NET\Primary Interop Assemblies\Asem1」
>  のファイルを削除した場合でも「Asem1」を参照することができました。
>  キャッシュという名前ですし、GACに登録した時点で登録に使用したファイルは参照しなくても動作可能なのでしょうか。
>  であれば、バージョンも識別してくれるので「GAC」登録は非常に有効な気がします。
>  ご指摘いただいたバージョンアップによる問題も起きないのではないでしょうか?

どうでしょう。試したこともないので分かりません。

>  アセンブリロードまでの流れを分かりやすく解説しているページがあったので紹介いたします。
>  <http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_index/idnfw11_l.jpg>

それ画像。

>  *ここのHPでも「GAC」による登録は不要であると言い切っています。

何の? Microsoft.mshtml.dll 固有の話については僕は分かりません。

>  *ただ、「.NET Frameworkではレジストリを使わなくてよくなった」とレジストリ登録が不要なことが
>   頻繁に書かれているのですが、実際には「RegAsm」によるレジストリ登録をおこなわないと動作しないと思うのですが。
>   どうなっているのでしょうか…。

Microsoft.mshtml.dll 固有の話だとどうなのか知りませんが、一般論としては RegAsm と GAC 登録はまったく関係ありません。

GAC に登録されるアセンブリは同時に RegAsm もされるべき、というルールはありません。

また、GAC に登録していないアセンブリであっても、RegAsm することで COM サーバとなるため、COM サーバとしては複数アプリケーションから利用可能です。

引用返信 編集キー/

次の20件>
トピック内ページ移動 / << 0 | 1 >>

管理者用

- Child Tree -