old_3流プログラマのメモ書き

(App-V).Net Frameworkをミドルウェアとしてパッケージする

.Net Framework1.1上で動いている業務アプリケーションがあります。


今回、WindowsServer 2008 R2 のRDS(リモートデスクトップサービス、旧ターミナルサービス)に移行する予定なんですが、WindowsServer2008 R2 や Windows7 では .Net Framework1.0/1.1は利用できなくなりました。

(この件に関しては、詳細は下記を参照。)
.NET Frameworkのバージョンを整理する － ＠IT
.NET Framework 1.0/1.1 上で稼働するアプリケーションをお使いのお客様へ - .NET Framework 移行センター

こういう場合に App-V を使えば.NetFrameworkごと仮想化してしまえるので、サポートされなくなった.Net Framework1.0/1.1を使うアプリケーションも使うことができます。
(.NetFramework2.0～3.5であれば WindowsServer2008 R2 には標準で入っているので何もしなくても動きます)

シーケンサーでパッケージを作るときに、標準アプリケーションと同じ方法で、.Net Framework1.0/1.1インストール→業務アプリケーション インストールという方法でやったら普通にきました。
しかし、別の.Net Framework1.0/1.1 を使うアプリケーションを同じ方法でパッケージ化し、App-Vサーバでインポートしようとすると、下記イメージのように、「アプリケーションは作成できません。指定の名前およびバージョンは既に使用されています。」とエラーになります。


名前を変えればいいのでしょうが、業務アプリケーションのパッケージごとに .Net Framework があるのはキャッシュの点から考えても効率的とは言えません。
ということで、ミドルウェア化を試してみました。構成としては下記のようになります。


このミドルウェア化したアプリケーションを、他のアプリケーションパッケージから使う方法からは、App-V の Dynamic Suite Composition という機能で動いているようですね。


手順は、MS Technet:Dynamic Suite Composition を使用する方法が参考になりますが、概略を下記に書いておきます。
App-V は 4.6 です。


1.まずシーケンスを行うPCのに、ミドルウェア(今回だと.NetFramework1.0/1.1)をインストールします。
(この際、シーケンスの作業はしません。普通にインストールするだけです。)

2.そして、ミドルウェアを利用する業務アプリケーションを、シーケンスします。
できたパッケージをApp-Vサーバのコンテンツフォルダに保存し、インポートします。

3.シーケンスするPCを 1. を行う前の状態にもどして、今度はミドルウェアをシーケンスします。(アプリケーションの種類はミドルウェア)
できたパッケージをApp-Vサーバのコンテンツフォルダに保存し、インポートします。



4.ここから、業務アプリケーションとミドルウェアのパッケージの依存関係設定を行います。
ミドルウェアパッケージ内の osd ファイルをテキストエディタで開きます。(どのファイルでもいいようです。)

5.開いたファイルの CODEBASE HREF 行をコピーします。
(今回だと下記のような行になりました)

<CODEBASE HREF="RTSP://appv-sv:554/dotnet_fr1011_mid/dotnet_fr1011_mid_2.sft" GUID="5AB8B691-3395-4B56-A896-6C87BA7B0FF4" PARAMETERS="" FILENAME="%CSIDL_WINDOWS%\Microsoft.NET\Framework\v1.0.3705\ConfigWizards.exe" SYSGUARDFILE="dotnet_fr1011_mid\osguard.cp" SIZE="169636875"/>

6.業務アプリケーションのosdファイルを開きます。
<DEPENDENCIES> タグを、<VIRTUALENV> セクションの最後にある </ENVLIST> タグの後、</VIRTUALENV> タグの直前に挿入し、コピーしているミドルウェアの CODEBASE HREF 行を <DEPENDENCIES> タグ内に貼り付けます。
また、ミドルウェアパッケージで、OSDファイルの <ENVLIST> セクションに任意のエントリがある場合、これらのエントリを業務アプリケーションOSDファイルの同じセクションにコピーする必要があるようです。(今回はこれは必要有りませんでした。)

注意点として、ミドルウェアが必須パッケージの場合、MANDATORY="TRUE" CODEBASE タグ内に追加しないといけません。たいてい必須になるかと思います。
最初これを忘れていて、うまく業務アプリケーションが動きませんでした。

業務アプリケーション側のOSDファイルですが、赤色の部分が変更点です。

<?xml version="1.0" standalone="no"?>

<SOFTPKG GUID="xxxx" NAME="HogeApri" VERSION="1.0.0.0">

  <IMPLEMENTATION>

    <CODEBASE HREF="RTSP://appv-sv:554/hogeapri/hogeapri_2.sft" GUID="xxxx" PARAMETERS="" FILENAME="hogeapri\hoge\hoge.exe" SYSGUARDFILE="hogeapri\hoge.cp" SIZE="133042724"/>

    <VIRTUALENV TERMINATECHILDREN="FALSE">

      <POLICIES>

        <LOCAL_INTERACTION_ALLOWED>FALSE</LOCAL_INTERACTION_ALLOWED>

      </POLICIES>

      <ENVLIST/>





      <DEPENDENCIES>

         <CODEBASE HREF="RTSP://appv-sv:554/dotnet_fr1011_mid/dotnet_fr1011_mid_2.sft" MANDATORY="TRUE" GUID="5AB8B691-3395-4B56-A896-6C87BA7B0FF4" PARAMETERS="" FILENAME="%CSIDL_WINDOWS%\Microsoft.NET\Framework\v1.1.4322\ConfigWizards.exe" SYSGUARDFILE="dotnet_fr1011_mid\osguard.cp" SIZE="169636875"/>

      </DEPENDENCIES>



    </VIRTUALENV>

    <WORKINGDIR/>

    <VM VALUE="Win32">

      <SUBSYSTEM VALUE="windows"/>

    </VM>

  </IMPLEMENTATION>

...省略

おそらくこのミドルウェアでパッケージする方法は、Javaランタイムとかにも使えると思います。

追記：
さっき気づいたんですが、パッケージ間の依存関係を上記手順では直接OSDファイルを書き換える方法でやっていました。
しかし、Application Virtualization Dynamic Suite Composition Tool というものを使えば、GUIで簡単にできるということが、山市良のえぬなんとかわーるど: App-V にあっぷっぷ: Dynamic Suite Composition に書かれてました。


参考：
MS TechNet:新しいミドルウェア アプリケーションをシーケンス処理する方法

VisualStudio無いけど、.Net Framework1.1のアプリを作りたい

検証で、.Net Framework1.1の HelloWorld アプリケーションを作る必要がありました。

しかし、.Net Framewrok1.1用のIDEである VisutalStudio2003 が有りません。

ということで、IDEを使わずにコンパイルしてみました。

コンパイルには、.NetFramework1.1 SDKが必要です。

インストールして、下記のようなコードを書き、C:\helloroworld.cs に保存しました。

namespace helloworld

{

  using System;

  using System.Text;

  using System.Windows.Forms;

  class helloworld

  {

    public static void Main()

    {

        //ビルドCLRバージョン取得

        string clrVerBuild = System.Reflection.Assembly.GetExecutingAssembly().ImageRuntimeVersion;

        clrVerBuild = "ビルドCLR ver:" + clrVerBuild + "\n";

        //実行CLRバージョン取得

        string clrVerRuntime = System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion();

        clrVerRuntime = "実行CLR ver:" + clrVerRuntime ;

        MessageBox.Show( clrVerBuild +  clrVerRuntime);

    }

  }

}

ビルドはコマンドプロンプトから、下記のようにしてやります。

C:\>C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\csc.exe C:\helloroworld.cs

Microsoft(R) Visual C# .NET Compiler version 7.10.6001.4

for Microsoft(R) .NET Framework version 1.1.4322

Copyright (C) Microsoft Corporation 2001-2002. All rights reserved.

これで、カレントフォルダにexeが出来ていはずです。
簡単ですね。

参考：
.NET Framework 開発環境構築

(.Net)ビルドされた時と実行時のFramework CLRのバージョンを知りたい

最近知ったんですが、例えば .Net Framework1.0 でアプリケーションを作成して、実行環境に .Net Framework2.0 しか入ってない場合、アプリケーションは2.0上のCLR(Common Language Runtime)で動こうとします。(基本的には、ビルドされた時と同じバージョンのCLRで動こうとします。)

ということで、ビルド時と実行時のCLRのバージョンを取得するアプリケーションをつくって試してみました。

まずビルド時のCLRのバージョンは下記のように取得できます。(C#)

//ビルドCLRバージョン取得(.NetFramework1.0では使用不可)

string clrVerBuild = System.Reflection.Assembly.GetExecutingAssembly().ImageRuntimeVersion;

label1.Text = "ビルドCLR ver:" + clrVerBuild;

実行時のCLRのバージョンは下記のように取得できます。

//実行CLRバージョン取得

string clrVerRuntime = System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion();

label2.Text = "実行CLR ver:" + clrVerRuntime;

 

//下記のようにしても取得できる(リビジョン番号も取得できるのでSP適用有無がわかる) 

clrVerRuntime = System.Environment.Version.ToString();

余談ですが、.NetFrameworkの混在した環境でアプリケーションを動かすと、使用するCLRのバージョンは下記のようになります。
(もしかしたら間違いがあるかもしれませんが。。。また、.Net3.0/3.5部分はCLR2.0だけの機能を利用した場合です)




CRLは現在、1.0 , 1.1 , 2.0 , 4.0 の4種類有ります。(.Net3.5 , 3.0 は .Net2.0 の拡張なので CLR は2.0になります)
.Net4 は下位互換性が全く無いようです。

.Netのサイドバイサイドを使えばアプリケーションが利用するCLRのバージョンを指定することもできるようです。

しかし、.Net Frameworkはアプリ作るときは楽なんですが、運用となるとこのあたりの事を考えないといけないので面倒ですね。


Windows7とWindowServer2008での.NetFramework1.0/1.1
最近まで知らなかったんですが、.Net Framework1.0 と 1.1 は Widnows7,WindowsServer2008 R2 ではサポートされなくなったようです。
これは .Net Framework1.0/1.1 を使ってるユーザには、非常に大きな問題ですよね。

しかし、.Net Framework1.0/1.1 のアプリケーションがWindows7,2008上で全く動かなくなる というわけではなく、冒頭のようにCLR2.0の下位互換性機能によって動くようです。
ただ、完全互換ではないので複雑なアプリケーションだとうまく動かないようですね。
業務アプリケーションで試してみましたが、下位互換性機能では動きませんでした。



参考：
＠IT：.NET TIPS ビルド時および実行時のCLRバージョンを取得するには？ - C# VB.NET
.NET Frameworkのバージョンを整理する － ＠IT
Windows Vistaにおける.NETアプリケーションの互換性問題 - Windows Vista徹底解説：ITpro
.NETFrameworkEnvironment - attosoft.info Trac
.NET Framework - Wikipedia
＠IT：.NET TIPS サイド・バイ・サイドによりCLRバージョンを指定するには？
MSDN:side-by-side 実行の概要
.NET Framework 1.0/1.1 上で稼働するアプリケーションをお使いのお客様へ - .NET Framework 移行センター

App-V動作報告 Oracle10gClient

Oracle10gのクライアントをシーケンサーでパッケージ化して App-V for RDS で動かしてみたんですが、動きました。
ただ、Enterprise Manager コンソール 実行時は、RDS側で管理者権限として実行してやらないと、データベースログイン後に落ちてしまいます。

App-Vでインストーラがないソフトを展開する方法

(最近バタバタしており、久しぶりの更新になってしまいました。。)

App-Vは基本的にインストーラの動きをトレースしてパッケージ化するので、インストーラがないソフト(いわゆるxcopy配置)は App-V で使えないのかと思ってました。

が、どうやらそうでないようです。


試しにCPU-Zをパッケージ化して配信してみました。
App-V for RDS環境です。(バージョンは4.6)
新しいパッケージの作成ウィザードで、種類を、標準アプリケーションとし、その次の画面で、「カスタムインストールを実行する。」を選択します。


あとは、パッケージ名を入れて、「アプリケーションを今すぐインストールしてください。」の画面になったら、仮想ドライブ(デフォルトQ:だけど、今回はM:)のアプリケーション名のフォルダ(バルーン表示される)に、CPU-Zのファイルをコピーします。


で、「インストールを終了する」にチェックをいれ、ウィザードを進めます。

終了するか,カスタマイズするか の画面になったらカスタマイズを選択します。
その次の画面で、「追加」ボタンを押下して、実行するexeを選択します。(ショートカットもここで指定できます)



アプリケーションを実行するかのウィザードでは、実行しておいたほうが無難なようです。



で、OSを選び、パッケージを保存します。

後は、パッケージの編集ウィザードで、実行対象OSとサーバのホスト名を指定します。



これで、App-VサーバにインポートしクライアントのRDSサーバに配信したんですが 「ディレクトリ名が無効です。エラーコード: 4604EE8-1F701639-0000010B」 とエラーになります。



調査すると、Technet:Microsoft Application Virtualization Management System リリース ノートによると、osd ファイルのパスの設定部分で、短縮パスを表す「~」があるとダメなようです。
CPU-Zの場合、WORKINGDIR の所の設定にチルダが入ってました。
App-VサーバのCPU-Zの osd ファイルから、「~」をのけて、クライアント側から一旦削除し、再度読み込ました。

が、今度は「要求された操作には管理者特権が必要です。」と怒られます。



一般ユーザ権限でRDSにログインしていたのでCPU-Zを右クリックし、管理者権限で動かすと無事に動きました。


xcopy配置のアプリケーションも安心してApp-Vで配信できますね。