locked
assemblyの登録方法 RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    質問させて頂きます。
    同じようにインストールした3台で
    windows\assemblyの構成が異なっているので困っております。

    1台はassemblyの中に直接DLLが入っています。
    DLLをコピー&ペーストで登録できます。

    残り2台はwindows\assemblyの中にいくつかフォルダが出来ており
    コピー&ペーストではDLLの登録は出来ません。

    3台とも同時に私自身でインストールしました。

    Windows 2012 server R2
    IIS8.5
    です。

    直接登録できる1台(A)は
    Activedirectoryサービス
    SQL2012 SP1(フルインストール)
    IIS
    の順にインストールし、DLLを登録した後にASP.NETのインストールを忘れており
    役割追加より[ASP.NET3][ASP.NET4]をインストールしました。

    直接登録できない
    もう1台(B)は
    SQL2012 SP1(フルインストール)
    IIS
    の順にインストールし、ASP.NETはIISと同時に役割追加しています。

    さらにもう1台(C)は
    IIS
    Activedirectory
    の順にインストールし、ASP.NETはIISと同時に役割追加しています。

    直接登録できないB,Cの共通点はAPS.NETのインストールの順番くらいで
    IISの役割を確認しても同じです。

    順番くらいしか原因がわかりませんが思い当りませんが
    いずれのサーバにもDLLをコピー&ペーストで直接追加できるようにしたいのです。

    何をどのようにしたらサーバAのようになりますでしょうか？

    2013年12月17日 0:13

回答

  • Question
    サインインして投票
    0
    サインインして投票
    理由はわかりませんが自己解決いたしました。

    まずこちらで書かせて頂いた内容で間違いがありました。
    Shfusion.dllはwindows\Microsoft.NET\Framework\v2.0.xxxxの中に
    全てのサーバで存在しました。※ファイル検索ではやはり出てきませんが...

    \windows\assemblyはファイルの実体が見えているわけではない
    ということだったので、アセンブリキャッシュを見せる動作が
    正常に動いていないと思い、サーバAにしたことと同じことをしてみました。

    プログラマーの作業で
    DLLを登録する際に共有設定された開発機のWindowsフォルダ内のassembly内を[サーバAから]
    エクスプローラのネットワークにて確認してから
    サーバAにDLLをドロップでインストールしたということでした。


    同じことをサーバBで行ったところ、サーバBのWindows\assemblyでキャッシュが
    ビュー出来るようになりました。

    更にサーバCではどの段階で見れるようになるか調べたところ
    ネットワーク上の開発機のassemblyフォルダをサーバCから表示させた時点で
    サーバC自身のローカルパスであるc:\windows\assemblyでアセンブリキャッシュが
    表示されるようになりました。

    なぜこのような動作をするのかは全く理解できませんが
    表示させる方法はわかりましたのですっきりしました。

    私の稚拙な質問にお付き合いいただきましてありがとうございました。
    • 回答としてマーク 佐伯玲 2013年12月20日 2:11
    2013年12月17日 9:29

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    原因を説明します。質問者さんが見たのはアセンブリ キャッシュ ビューア (Shfusion.dll)です。そしてこの機能は.NET 4から廃止されました。
    つまり、.NET 3.5.1以前がインストールされているコンピューターではコピー＆ペーストによるインストールが可能になっています。他のPCにはインストールされていなかったということでしょう。
    # 余談ですがDIRコマンドで確認すれば同様の構造をしているのが確認できるでしょう…？ といいつつ.NET 4から \Windows\Microsoft.NET\assembly に場所が変更されていますが。

    さてリンク先にも説明されていますが、インストールにはGacutil.exeを使うよう勧められています。ただし、これは開発環境における説明であり、一般の環境では当該EXEは見つからないのではと思います。正しくは.NET Framework およびアプリケーションの配置に従い適切にインストールしてください。
    # なにかGACにインストールする必要があるのでしょうか？

    2013年12月17日 1:49
  • Question
    サインインして投票
    0
    サインインして投票

    回答ではなくて確認です。


    アセンブリとは具体的に何なのでしょうか？　そもそも手動で GAC に登録しなければならないものなのでしょうか。以下のページような意見もありますが（「■アセンブリの配置」のセクション参照）。

    第3回　アセンブリのロード
    http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_03/idnfw11_03_03.html


    それから、以下のような話はご存知でしょうか？　見るところが違うということはありませんか？

    .NET Framework 4.0から何気にGACの場所が変わっている (Global Assembly Cache)
    http://d.hatena.ne.jp/gsf_zero1/20120316/p1


    グローバルアセンブリキャッシュツール（Gacutil.exe）を使うという手段もありますが、試して見ましたか？

    グローバルアセンブリキャッシュにアセンブリをインストールする
    http://dobon.net/vb/dotnet/deployment/installgac.html

     

    #佐祐理さんのレスと一部ダブってしまいましたが、せっかく書いたのでアップします。

    2013年12月17日 2:07
  • Question
    サインインして投票
    0
    サインインして投票

    佐佑理様　SurferOnWww様

    ご回答ありがとうございます。
    DLLを登録する目的はActiveReportです。
    私はプログラムは一切出来ないのですが、環境を作れということで
    環境を作っております。

    プログラマーの方が言うには今までコピーでいけてたのに
    何で出来ないサーバがあるの？何とかしてくれ
    ということで困っております。

    話は戻りますが、コピーできているサーバAにもframework4 Multi-Targeting Pack
    というものしかインストールされていません。
    SQL 2012 Stdをインストールしたのでその際にvisualstudioと一緒に入ったのだと思います。
    これはサーバBも同様です。特にOSの初期インストールから一気にインストールしたので
    framework3は意識的には入れておりませんし、役割にも記載がありません。
    またいずれのサーバにもwindows\assemblyのフォルダとWindows\Microsoft.net\assemblyの
    両方が存在します。これはAPS.NETを両方インストールしているからでしょうか。

    とりあえずのアプリケーションを動作させるという点に関して解決策は何とかなるとして
    なぜ同じものを同じようにインストールしたのに1台はコピーできる状態で
    2台はコピーできないのか。というのが非常に気になっています。

    インストールされている機能は違いますが、
    各機能をインストールする時にはモニターを横に並べて
    例えばIISなら全く同じものを追加しながらインストールしていきました。

    [AD,SQL2012,IIS8.5]を全てインストールするとコピーできる環境になって
    [AD,IIS][SQL2012,IIS8.5]等1つ欠けるとコピーできない環境になる
    というのが納得がいかず、他の要因があるのじゃないか。と思ってしまっています。

    私もframeworkやら.NETやらがよくわからない状況で構築しているので
    言っている意味が分からない部分があるかもしれません。
    しかしなぜ異なる環境になってしまったのか気になってしまっています。

    2013年12月17日 3:03
  • Question
    サインインして投票
    0
    サインインして投票

    話が噛み合ってないようです。

    回答者のレスを読まれたでしょうか？

    読んだけど理解できないのでしょうか？

    前者の答えが NO なら、まず回答者のレスやその中で紹介しているページをよく読んでください。話はそれからです。

    > 私もframeworkやら.NETやらがよくわからない状況で構築しているので

    とのことなので、たぶん後者（回答者のレスを理解できない）だと思いますが、もしそうなら、あなたの近くにいる上司、先輩、同僚など、回答者のレスを理解できる知識を持っている人に手伝ってもらわないと無理だと思います。

    よく分からない人が掲示板でやり取りして Windows Server を構築するなんてのは、そもそも間違っていると個人的には思います。


    • 編集済み SurferOnWww 2013年12月17日 4:39 一部追記
    2013年12月17日 4:33
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様
    ご回答ありがとうございます。

    ご説明が足らず申し訳ございません。
    お二方から教えて頂いたWEBサイトは読ませて頂いております。

    その上での質問でした。
    ・3台共にASP.NET3.5及び拡張機能はIISの役割で追加されています。
    　※同時にASP.NET4及びその拡張機能も追加されています。

    ・\Windows\assemblyでアセンブリキャッシュを見ることが出来たサーバ上のファイル検索で
    　Shfusion.dllを検査しましたがファイルは見つかりませんでした。
    　※エクスプローラで隠しファイルも探しましたがこの名前のファイルが見当たりませんでした。

    ・SDKをインストールし、Gacutil.exeからアセンブリを登録する方法は理解できました。
    　運用ではこの方法を使用するか、インストーラを作成してインストールすることになります。

    インストールされたプログラム、役割追加を見比べましたがサーバ1にだけあるというものが
    見当たりませんでした。

    二十数年Unix、Linuxサーバのみを構築してきたのですが
    今までWindowsの環境を全て社内で構築してきた人間が辞めてしまい
    社内開発の誰に聞いてもわからず[サーバ管理者]ということで私に鉢が回ってきました。

    .NET4からはGacutil.exeを使用するように。ということマイクロソフトが強く言っていることは
    理解できました。
    現在の私の興味は「何の違いでこうなったんだろう」という一点でございます。

    2013年12月17日 5:24
  • Question
    サインインして投票
    0
    サインインして投票
    理由はわかりませんが自己解決いたしました。

    まずこちらで書かせて頂いた内容で間違いがありました。
    Shfusion.dllはwindows\Microsoft.NET\Framework\v2.0.xxxxの中に
    全てのサーバで存在しました。※ファイル検索ではやはり出てきませんが...

    \windows\assemblyはファイルの実体が見えているわけではない
    ということだったので、アセンブリキャッシュを見せる動作が
    正常に動いていないと思い、サーバAにしたことと同じことをしてみました。

    プログラマーの作業で
    DLLを登録する際に共有設定された開発機のWindowsフォルダ内のassembly内を[サーバAから]
    エクスプローラのネットワークにて確認してから
    サーバAにDLLをドロップでインストールしたということでした。


    同じことをサーバBで行ったところ、サーバBのWindows\assemblyでキャッシュが
    ビュー出来るようになりました。

    更にサーバCではどの段階で見れるようになるか調べたところ
    ネットワーク上の開発機のassemblyフォルダをサーバCから表示させた時点で
    サーバC自身のローカルパスであるc:\windows\assemblyでアセンブリキャッシュが
    表示されるようになりました。

    なぜこのような動作をするのかは全く理解できませんが
    表示させる方法はわかりましたのですっきりしました。

    私の稚拙な質問にお付き合いいただきましてありがとうございました。
    • 回答としてマーク 佐伯玲 2013年12月20日 2:11
    2013年12月17日 9:29