Linux Monoで、BlogEngine.NETを動かすで書いたとおり、Mono2.0以上では、うちのクリエモンが動かなかったのですが、やっぱり最近のバージョンの方がパフォーマンスも上がってるだろうし、もっかい試してみんべってことで、mono-2.6.1をソースからビルドしてみました。openSUSE向けならバイナリもあるみたいですが、さぶろーが使ってるCentOSでは、ソースから入れないとダメみたいです。

前提として、今回使用するマシンには、以前古いバージョンのMonoをソースから入れた気がするので、OSインストール直後のまっさらな状態だと、もっと依存ライブラリのエラーが出るかもしれません、注意。（たしか、画像関連のライブラリと、apacheの開発用パッケージが必要だった気がする）

さぶろーの場合、あくまでもWebサイトをホストするのが目的なので、簡易ASP.NETサーバのXSPと、ApacheのMonoモジュールであるmod_monoも入れることにします。あと、System.Drawing名前空間のクラスを使う場合は、libgdiplusも必要です。クリエモンは画像のアップロードで、該当クラスを使ってるので、こっちも入れます。

また、ソースからインストールすると削除するときなど手動では大変なので、ソースコードパッケージを管理できるPacoっていうツールを使います。make installするときに、次のようにかませて使います。 # paco -D make install

必要なパッケージをダウンロード

Mono 2.6.1 Sourcesからソースパッケージをダウンロード、解凍します。 さぶろーは、以下のパッケージをダウンロードしました。

• libgdiplus-2.6
• mono-2.6.1
• xsp-2.6
• mod_mono-2.6

libgdiplusをビルド

# cd libgdiplus-2.6 
# ./configure 
# make 
# paco -D make install 

monoをビルド

# cd mono-2.6.1 
# ./configure 
# make 
# paco -D make install 

xspをビルド

# cd xsp-2.6 
# ./configure 
# make 

と、ここまでやったところでエラーが（￣□ ￣ ||

/usr/local/bin/mcs -pkg:dotnet -r:System.Xml.dll -target:library -out:SiteMapReader_1.1.dll SiteMapReader_1.1.cs Package dotnet was not found in the pkg-config search path. Perhaps you should add the directory containing `dotnet.pc' to the PKG_CONFIG_PATH environment variable No package 'dotnet' found error CS8027: Error running pkg-config. Check the above output.

メッセージの通りに、PKG_CONFIG_PATHを設定してあげたらうまくいきました（￣∇ ￣ ）

# export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
# make
# paco -D make install 

mod_monoをビルド

# cd mod_mono-2.6
# ./configure
# make
# paco -D make install

割とすんなり終了。やっぱ、前回入れたからかな。あんまり参考にならないエントリでした・・・。

長いことVisualStudio使ってましたが、じつは去年の終わりくらいにMonoDevelopへ移行しました。MonoDevelopは、去年末に出したバージョン2.2から、Windowsを本格的にサポートしたみたいで、若干おかしい動きもありますが、開発に重大な支障なく使えてます。

移行したメインの理由は、Viモードがあるからです。VisualStudioでも有料のVimプラグインや、VimエディタからVisualStudioを操作するようなツールはあるんですが、MonoDevelopはIDEが最初からViのキー入力をサポートしており、メニューで設定をいじるだけでコードエディタでViキーバインドが使えるようになります。まだまだサポートしているキー自体は少ないですが、それでも作業効率が上がった気がします。もちろん、インテリセンスもちゃんと使えますよ（￣∇ ￣ ）

さて、お目当てはViモードだったんですが、他にもいくつか良い点がありました。

１つ目は、C#の最新の構文が使えるようになったことです。じつは、さぶろーは、VisualStudio2005を使っていました。、MonoRailが正式にVS2008をサポートしてないという話だったからです。たぶん2008でも開発は出来るだろうと思うんですけど、大事をとって2005にしていたのでした。2005は、C#2.0までしかサポートしないんで、ラムダ式、LINQ、型推論、拡張メソッドなどの便利な機能が使えません＞＜ MonoDevelop2.2は、C#3.0をサポートしているほか、一部C#4.0をサポートしているそうです ←（これはMonoの話でMonoDevelopは関係なかったかも）。今ではラムダ式使いまくりです（＾＾）

２つ目は、フリーでありながらExpressEditionの制約がないことです。MonorailをVS2005 ExpressEditionで開発する方法まとめで書いたとおり、ExpressEditionではVSC#とVSWDを切り替えつつ開発していく必要があり、プロジェクト構成も汚くなりがち。MonoDevelopでは、VSのStandardEdition以上と同じく、１つのIDEでクラスライブラリも、ASP.NETプロジェクトも同一のソリューション上で開発できます。

３つ目は、Monoで動かない機能は、そもそも作れないようになっていることです。VisualStudioで作って、Linux上のMonoVMで動かそうとすると、Monoでは動作しないような場合があるんですが、MonoDevelopはMonoと足並みを揃えて開発されているので、そのようなことがありません。MonoVMで動かしたいという方は、検証が楽になると思います。

もちろん、良い点だけではなく、不満点もいくつかありました。

• MonorailのViewEngineの１つ、AspView用のaspxファイルでで開けないものがある
• デバッグ時に、変数の値がなかなか表示されないことがある

aspxが開けなかった問題は少し面倒でしたが、別途テキストエディタで開いて編集しています。

最後に、移行時に行なった作業ですが、MonoDevelopはVisualStudioのプロジェクトをそのまま開くことが出来るので、基本的には作業不要でした。ただ、日本語は文字化けしたので、Shift-JISから、UTF-8への変換だけ行ないました。

さぶろーは、かなりMonoDevelop気に入ってしまいましたが、みなさんどう感じましたでしょうか。MonoVM上でプログラムを動かしたい方にはオススメです（￣∇ ￣ ）

クリエモンでURLエンコード周りのバグを出してしまいました（￣□ ￣ ||

原因はCGIとJavascriptでURLエンコードが微妙に違うことでした。WikipediaのURLエンコードのページをみると、Javascriptでは、スペースは「%20」にエンコードされるが、CGI側では普通は「+」に変換されると書いてあります。なんでそんなややこしいことになってんだろ。これって知らないの僕だけで他のWeb開発者の間では常識なのかな（_ _ ||

とりあえず、おかしくなっていた部分では、HttpUtilityクラスのUrlEncodeメソッドが使われていました。以下はPowerShellでちょっと確認してみたところ。HttpUtilityクラスは、そのままでは参照できないんでリフレクションで「System.Web.dll」を読み込んでいます。

PS C:> [System.Reflection.Assembly]::LoadWithPartialName("System.Web")

GAC    Version        Location
---    -------        --------
True   v2.0.50727     C:\Windows\assembly\GAC_32\System.Web\2.0.0.0__b03f5f7f11d50a3a\System.Web.dll

PS C:> [System.Web.HttpUtility]::UrlEncode("<hoge fuga>")
%3choge+fuga%3e

PowerShell覚えると、インタプリタで動作確認ができちゃって楽ちんだな～（￣∇￣）　で、結果を見ると確かに「+」にエンコードされていますね。

調べてみると、UriクラスのEscapeDataStringメソッドを使えばJavascript形式のエンコードが出来るらしいとのこと。どれどれ

PS C:> [Uri]::EscapeDataString("<hoge fuga>")
%3Choge%20fuga%3E

おお、たしかに「%20」にエンコードされました（＾＾）　結局、UrlEncodeメソッドを使用している箇所を、のきなみEscapeDataStringメソッドに置き換えて、問題は解決したのでした。

ちなみに、UriクラスにはEscapeUriStringというメソッドもあります。こちらがどんな動作をするのか気になったので、サクッと確認してみました。

PS C:> [Uri]::EscapeDataString("http://www.hogefuga.com/<hoge fuga>")
http%3A%2F%2Fwww.hogefuga.com%2F%3Choge%20fuga%3E

PS C:> [Uri]::EscapeUriString("http://www.hogefuga.com/<hoge fuga>")
http://www.hogefuga.com/%3Choge%20fuga%3E

EscapeDataStringメソッドは、URLのコロンやスラッシュもエンコードしてしまいますが、EscapeUriStringメソッドは、URLを構成するための記号はエンコードしていません。すでに、URLになっている文字列に対してエンコードしたい時はこちらを使えばいいわけですね（￣∇ ￣ ）

ちょっと、とあるWebサーバ上にあるZipファイルを定期的にダウンロードして解凍する必要が出てきたんで、適当な言語でスクリプト作ることにしました。ただ、要件としてWindows上で動作する必要があって、せっかくなんで、前から気になってたPowerShellでやってみることにしました。

# Zipファイル操作用のライブラリをロード
[System.Reflection.Assembly]::LoadFile('C:\temp\ICSharpCode.SharpZipLib.dll')

# WebClientクラスのインスタンスを作成
$wc = New-Object System.Net.WebClient

# Zipファイルをダウンロード
$wc.DownloadFile("http://www.hoge.com/fuga.zip","C:\temp\temp.zip") 

# Zipファイルを解凍
$zip = New-Object ICSharpCode.SharpZipLib.Zip.FastZip
$zip.ExtractZip("C:\temp\temp.zip", "C:\temp\" + [DateTime]::Now.ToString("yyyyMMdd"), "")

Zipファイルを解凍する方法は、COMを通してエクスプローラの機能を使うとか、コマンドラインで解凍ソフトを呼び出すとか色々あるみたいだけど、今回は、ICSharpCode.SharpZipLib.dllを使ってみました。PowerShell上で、外部アセンブリのクラスを使用したい場合は、リフレクションを使ってアセンブリをロードしておく必要があるみたいなので最初にロードしてます。[System.Reflection.Assembly]::LoadFileみたいな呼び方してるけど、静的なメンバを呼び出す時はこうしないといけないらしいです。

次にWebClientのインスタンス化、New-Objectコマンドでインスタンス作成です。そのインスタンスのDownloadFileメソッドを使用して、ファイルを同期的に取得しています。

最後に、ICSharpCode.SharpZipLib.dllのFastZipクラスを使用して解凍。解凍したファイルは、日付ごとのフォルダに格納してます。

とまあ、こんな感じで結構簡単にできました（￣∇￣）でも、いざ実行してみるとエラーが・・・（￣□ ￣ || 　どうやら、PowerShellではデフォルトの実行ポリシーが「Restricted」になっていて全てのスクリプトの実行が禁止されているとのこと。実行ポリシーは他に「AllSigned、RemoteSigned、Unrestricted」があるそうですが、今回はインターネット上のスクリプトのみ署名を求める「RemoteSigned」にポリシー変更してみました。

Set-ExecutionPolicy RemoteSigned

これをPowerShellのプロンプト上で実行してやれば動くようになりました（＾＾）

なんとかこのブログも、PebbleからBlogEngine.NETへ移行できました。

もちろん、Linux Mono上で動いているのですが、その設定を書いてみます。バージョンは、Monoが1.9.1、BlogEngine.NETが1.5.0です。

ホントはもっとバージョンが新しいMonoを使おうかと思ってたのですが、実は、クリエモンが、Mono1.9.1以下のバージョンでしか動かなかったんです(_ _ ||　Mono2.4は、MonoRailの、URL Routingがうまく動きませんでした。どうやら、System.Web.HttpApplicationクラスで、web.configから設定を取得するコードが2.4から修正されて、Routingの設定が読めなかったみたいです。Mono2.2と2.0では、正規表現のオプションRegexOptions.ReferenceIgnoreCaseがサポートされてないようで、正規表現でURL Routingを割り当てる部分でエラーがでました。ブログをホストするマシンをクリエモンと別にするという手もあったんですが、ブログのためにマシンを追加するのも億劫だったので（￣∇￣）

さあ、設定の手順ですが、実は結構簡単です。ここにたどり着くまでは、すごく大変だったんですけどね（￣□ ￣||

１、ドキュメントルートに、BlogEngine.NETを設置

BlogEngine.NETを本家からダウンロード・解凍すると、「BlogEngine.Web」というディレクトリが出来るのでドキュメントルートにコピーします。

２、Web.Configの修正

まず、Web.Configを小文字のweb.configに修正します。これをやっとかないと動かないページがありました。次に、web.configを開いて、System.Managementのアセンブリを読み込んでいる部分をコメントアウトします。これは、DBを使う場合で使用されるようなので、デフォルトのまま、データをXMLに保存する場合はコメントアウトしても問題ありません。たぶん・・・。

３、Tag Cloud Widgetの修正

Tag Cloudのコントロールが、そのままでは動かないので、「BlogEngine.Web/widgets/Tag cloud/edit.ascx」のReferenceディレクティブを修正します。

<%@ Reference VirtualPath="~/widgets/Tag cloud/widget.ascx" %>
↓
<%@ Reference Control="~/widgets/Tag cloud/widget.ascx" %>

たぶん、WindowsならVirtualPathで動くんでしょうねぇ。

これで一応動きますが、実はブログのインポートにハマりどころがありました（￣□ ￣||　BlogEngine.NETのインポートは、インポートツールを使用して行うんですが、これがどうやらアプリ内部で設定しているURLが全て小文字になっていて、大文字小文字を区別するLinuxだと動かないようです。ちょっと調べてみるとCodePlexにBlog Importerっていうプロジェクトがあって、これがBlogEngine.NETのインポートツールかなと思ったらビンゴだったので、ソースを見てみたのですが、あまりの酷さに愕然・・・。

• URLが全て小文字で記述されていて、Linuxのサービスにアクセスできない
• URLの最後に"/"をつける、CleanPath関数があるんだけど、それをインポートするRSSにも適用してる。だから、「http://○○/rss.xml/」みたいなURLにアクセスしにいく・・・orz
• コンテンツのフィルタ部分にバグがある

まあ、こんなところです。コメントが移行できなかったのが少し残念ですがとりあえず、おｋということで、やっとクリエモンの続きに入れるかな。

BlogEngine.NETをMonoで動かすのは、やはりムズイです。環境は故合って、Mono 1.2.4 ＆ BlogEngine.NET 1.4.5 でやってますが、うまく動いてくれません（￣□ ￣||

BlogEngine.NET Modifications for Mono/Linuxを参考に、以下やったこと、binのリネーム以外は全てWeb.Configの修正です。

System.Managementの読み込みを削除

Mono 1.2.4では使えないNamespaceのようで、かつDBを使用せずXMLでやれば不要そうだったので削除。

Description属性を４つ削除

Web.Configのprovider定義タグではdescription属性が使えないらしいので削除。

DBBlogProviderタグ削除
SqlMembershipProvider削除
DbMembershipProvider削除
SqlRoleProvider削除
DbRoleProvider削除

XMLでやれば不要そうで、かつ動作不良の原因ぽかったので削除。

Compression HttpModuleを削除

ページに「？」が表示されるらしいので削除。

Binディレクトリをbinにリネーム

Linuxのファイル名が大文字、小文字を区別するので変更。

httpRuntimeを削除

クリエモンと同居させてるからか、Machine.Configで、httpRuntimeを読む時エラーになったのでWeb.Configのを削除したらなぜか直ったｗ。

StrageLocationを仮想パスでなく絶対パスで書く

Web.Configに「StorageLocation="~/App_Data/"」とあって、これを絶対パスで書かないとエラーになる部分があったので変更。しかし、絶対パスにしてもエラーになった・・・orz

public static string MapPath (string virtualPath)
{
 if (virtualPath == null || virtualPath == "")
  throw new ArgumentNullException ("virtualPath");

 if (UrlUtils.IsRelativeUrl (virtualPath)) {
  string msg = String.Format ("The relative virtual path '{0}', is not allowed here.", virtualPath);
  throw new ArgumentException (msg);
 }

 HttpContext context = HttpContext.Current;
 if (context == null)
  return null;

 return context.Request.MapPath (virtualPath);
}

というわけで、Mono 2.4も出てるらしいので、もうちょっとバージョンが上がったMonoVMで動かしてみようと思います。でも前、クリエモンを乗せたらうまく動かなかったんだよな～（￣～￣）

あと、タイミングのいいことに、昨日、BlogEngine.NETが9ヶ月ぶりにバージョンアップして1.5になったそうなので、そっちも試してみようと思います。昨日、インストールがうまくいってたら、即、アップデートが必要だったと思えば失敗してよかったのかな（＾＾）

近々、ブログエンジンの移行を計画しています。

このブログは自宅サーバで運営してますが、CPUがPentium3というのもそろそろ限界かと思い始めて、先日NTT-X Storeで、HPのML115を買いました。年度末セールで、2台で21500円で買えて、ウホウホ言って喜んでたら、2日後に19500円になってました・・・orz

まあ、そんなわけでこの機会に、アプリも含めたサーバの再構築をしてみようと思ったわけです。最近は、Linux Monoでクリエモンとか動かしてるし、Monoで動くいいブログエンジンないかなーと探してたら、めっさいいのがありました。

BlogEngine.NET

BlogEngine.NETは、.netのブログエンジンを代表するようなプロダクトですが、Mono対応が売りのひとつになっています。いや素晴らしい（＾＾）

とりあえず、これでいってみようと思います。

いつの間にか、Mono2.0がリリースしてました。Monoトップページも大幅リニューアルしてます。

今回のリリースの最大の売りは、やはりLINQやラムダ式などのC#3.0の機能がつかえることみたいです。他にもバグフィックスや、パフォーマンスアップなど目白押しのようです。今作ってるサービスを、Mono2.0向けに作り直したくなってきました（まあ、しませんが）。

より詳しい情報は、Mono 2.0 Release Notesをご覧ください。

ここからは、宣伝です。今作っているセカンドライフ向けサービスの完成がいよいよ近づいてきました。つきましては、10月18日から2週間開催されるLSL Convention 2008で、お試し版をリリースする予定です。興味のある方（いるのか？）は、ぜひご来場ください。

複数のエラーが複雑に絡み合って大変でしたが、とりあえずDBからデータをとってきて、それをページに表示するところまで来ました。まだ、画像が一部表示されなかったり、おかしな部分もありますが、まあなんとかなるかな。

とりあえず、ハマッタ部分を列挙しときます。

1.AspView上でのViewComponent

MonorailのViewEngineの一つ、AspViewを使っているのですが、このエンジン上でViewComponentを使う時は引き渡す値がNullだといけないようです。たまたまNullを渡してしまうロジックがあったので、空のオブジェクトをデフォルトで生成しておくよう修正しました。

2.MysqlDataReader.GetValueの仕様

MysqlDataReader.GetValueで、DBの値をオブジェクトとして取得したものを、リフレクションでオブジェクトのフィールドにセットしていたのですが、その際実行される暗黙的キャスト処理が、Windows上では動作するがMono上では動作せず「Unknown target conversion type」とエラーが出ていました。これはメチャクチャ嵌ったんですが、MysqlDataReaderのドキュメントを見ると、以下のような文が書いてありました。

For optimal performance, MySqlDataReader avoids creating unnecessary objects or making unnecessary copies of data. As a result, multiple calls to methods such as GetValue(Int32) return a reference to the same object. Use caution if you are modifying the underlying value of the objects returned by methods such as GetValue.

どうやら、DBから同じ値を取得した場合、2回目は前回取得した値の参照を返すようで、おそらくこれのせいでキャストが失敗したのではないかと考えています（あくまで予想です）。対策として、データを取得する際、明示的にGetStringやGetInt32などを使用することで回避できました。

3.Enumのフィールドにリフレクションで値セット時の挙動

前述のとおり、DBからとってきたデータは、リフレクションでオブジェクトのフィールドにマッピングしています。Enumフィールドに対してDBの数値型のカラムから取得した値をセットした場合、Windowsでは問題なくキャストしてくれるのですが、Monoではエラーになっていました。Enum.ToObjectを使用してリフレクションの前にEnumオブジェクトに変換しておくと、うまく動作しました。まあEnumに数値を割り当てる時は通常はキャストが必要なのでこれは仕方ないかもしれません。

4.フォルダ名の大文字、小文字

Windows上で正しく動作しているからフォルダ名の大文字、小文字は気にしてなかったのですが、Linuxでは当然これらを区別するので、プログラムから指定するパスと実際のディレクトリが正確に一致していないと、ファイルが見つからないことになります。javascriptが入っているフォルダが見つからないなーと思ったらこれが原因でした。

5.AspViewのディレクトリ区切り文字列

ViewEngineのAspViewがSubViewのあるディレクトリを探す際に、環境に合わせた区切り文字を取得できるPath.DirectorySeparatorCharを使わず、"\"をディレクトリ区切り文字列として使用していました。これでは当然Windowsでしか動きません（￣□ ￣ || 作者のブログに慣れない英語でコメントしてみたのですが、Mono環境を持ってないのでテストできないそうです。逆によかったらパッチを送ってくれと頼まれたのですが、Sabroが使っているのはMonorail-RC3に会わせた少し古いバージョンでTrunkとはかなりクラス構成が変わっています。一応Trunkのものを持ってきて動かそうと試みてみたのですが、別のエラーが出て動作するところまでいきませんでした。そこで、申し訳ないですがパッチは送らずに、ローカルでソースを修正して使うことにしました。作者さんすいません m(_ _)m

やっぱ、まだMonoは色々問題あるなぁ。まあ半年の努力が無駄にならなくてよかったよかった（・∀・）

monorailで作ってるセカンドライフ向けのWebサービスだけど、当然WindowsServerなんか使うお金はないので、Linuxサーバのmono上で動作させる予定だったのです。

まあ、.NETは中間言語にコンパイルされるし、VisualStudioで開発したものも、どうせ動くっしょとタカをくくって今まで動作確認してませんでした。しかし、開発も終盤にさしかかったので、昨日ホイッとmono1.2.4上にデプロイしてみたら、なんとエラーでまくりでした （￣□ ￣ ||

まず、変数をキャストする際に、Unknown target conversion type というエラーが出てたのですが、これはMySQLのドライバ（connector/NET）が新しすぎたことが原因だったみたいでした。5.1系だったのを、1.0系にしてやれば、それは直りました。（追記：これは勘違いだったみたいで、MySqlDataReader.GetValueを使用していたのがダメだったようです。型を判別してGetStringとかを使えば直りました。ドライバも5.1系でOKでした）

次は、CreateSemaphore という処理で謎のエラーが・・・。これは、Bug #33682を見ると、なんとコネクションプーリング用のセマフォを取得するのに、Win32APIを直接叩いているとのこと。なんだその作りは orz
パッチがあるようですが、とりあえずPoolingをオフにして先に進むことにしました。

そして、ようやくMySQLドライバがらみのエラーは消えたようですが、今度はエラーになってもスタックトレースが表示されず、ApacheのInternal Server Errorの画面しか返ってこなくなりました。とりあえず疲れたので続きは明日。

これで動かなかったら、これまで半年開発してきた努力が全て無駄になってしまうのだが・・・大丈夫なのか （-_ - ||