Programming

.Net Framework で作成した Windows Service Installer に独自の設定を追加する方法

ちゃっぴ (tyappi@wankuma.com) — Thu, 23 Sep 2010 17:58:00 GMT

.NET Framework を利用して作成した Windows Service を install する場合、installutil.exe を利用して install します。

Install 時に行う Service の基本的な設定は wizard で自動的に作成される ServiceInstaller と ServiceProcessInstaller の property を設定することで行えます。

ただ、Installer で proprty で定義されていない設定を追加したい場合も多いでしょう。その場合どうしたらよいか？

答えは簡単 System.Configuration.Install.Installer class の Install, Uninstall method を override する。

namespace SampleService
{
  [RunInstaller(true)]
  public partial class ProjectInstaller : Installer
  {
    public ProjectInstaller()
    {
      InitializeComponent();
    }
    
    // 追加
    public override void Install(IDictionary stateSaver)
    {
      base.Install(stateSaver);
      // 追加する設定を登録
    }
    
    // 追加
    public override void Uninstall(IDictionary savedState)
    {
      base.Uninstall(savedState);
      // 追加する設定を削除
    }
  }
}

こんな感じで簡単にできます。

安全でないライブラリのロードにより、リモートでコードが実行される

ちゃっぴ (tyappi@wankuma.com) — Wed, 25 Aug 2010 05:28:00 GMT

安全でないライブラリのロードにより、リモートでコードが実行されるという seurity advisory が出ています。まあ、ここ読んでいるような人にとってはすでに知っていることだと思いますが。

ちょっと興味があったので、いろいろ情報あさっていましたが、正確なところはわかりませんがどうやら下記のようなことじゃないかと。

LoadLibrary や LoadLibraryEx 等を利用して DLL を動的に load する場合、絶対 path を指定しないと Dynamic-Link Library Search Order の順序に従って DLL が検索されます。

この検索先の中に current directory が含まれるのがミソで、load する予定の DLL と名前が完全に一致する DLL が存在するとそいつが読み込まれてしまう。

直接呼ばれる関数に攻撃 code を仕込んでおけばいいわけですが、Win32 DLL には DllMain という DLL を load されるときに自動的に実行される entry point があるので、こいつを使えばもっとお手軽。

ここまでは全然新しくない話なんですが、今回出てきたのは current directory が remote (SMB や WebDav) 上だった場合、remote に file を配置しておくだけで攻撃が可能ということ。

個人的には application が file を開くときに current directory を変更して開くなんて考えずらいと思っていましたが、この攻撃が可能な application は 40 以上存在するとのことなので。

Update: 40 Windows apps contain critical bug, says researcher

この問題への対応としては、Dynamic-Link Library Security にまとめられています。

LoadLibrary, LoadLibraryEx, CreateProcess, ShellExecute を呼び出すときは可能な限り fully qualified path を利用する。
Dynamic-Link Library Redirection, Manifests を利用し正しい DLL を呼び出すことを強制する。
Registry HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode を変更し DLL の検索順序を変更する。
DLL を呼び出す前に SetDllDirectory に "" を指定して current directory の path を除去する。 (Multi thread, process 間での競合注意)
Safe process search mode が有効になっていないときは SearchPath を利用しない。SearchPath をどうしても利用する必要があるときは先に SetSearchPathMode に BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE を指定して呼び出した後に利用する。Current directory は最後に回されるが除去はされないので注意が必要。
LoadLibrary?が検索する DLL の検索順序は OS によって異なるので、推測だけで行わない。ちゃんと OS version 確認しましょう。

基本的な対応としては application code の修正です。ということで、DLL を dynamic load している application の開発者はについて既存の code に問題が無いかご確認ください。

なお、DLL の検索対象から current directory を除去する方法については WebDav や SMB のみ除去するといった設定が可能になる patch が提供されています。

DLL 検索パスアルゴリズムを制御する新しい CWDIllegalInDllSearch レジストリエントリについて

WebDav のみ SMB のみ不可といった制限も可能なので patch を適用した上で設定を変更しておいたほうがよいでしょう。WebDav, SMB 不可程度であればほぼ影響は無いでしょうから。

Excel Workbook を扱う方法いろいろ (Excel 2003 以前)

ちゃっぴ (tyappi@wankuma.com) — Sun, 27 Jun 2010 18:37:00 GMT

Excel Workbook を読み込む方法はいろいろ存在します。Excel 2003 までだとこんなのがありました。

Microsoft Excel Object Model (Automation) を利用
Microsoft JET を利用
Excel binary file format を直接扱う

Microsoft Excel Object Model (Automation) を利用

Automation (COM) を利用する方法はあまりにも有名なので、あえて説明する必要すらありませんね。これを利用すれば Microsoft Excel の全機能を制限なく扱うことができます。ただし、Microsoft Excel を利用するので Microsoft Excel が install されている環境でないと利用できません。また、server-side での実行も support されていません。詳しくは下記参照。

Office のサーバーサイドオートメーションについて

Excel binary file format を直接扱う

Binary format を直接扱う方法はおそらくやる人いないでしょう。昔は仕様が公開されていませんでしたが、現在は公開されています。まあ、やるのであれば頑張ってくださいとしか。。。

[MS-XLS]: Excel Binary File Format (.xls) Structure Specification

Microsoft JET を利用

Microsoft JET を利用する方法は知らない人結構いるんじゃないでしょうか？ Microsoft JET とはもともと Microsoft Access DB engine に接続するための data access provider ですが、その他の data source を扱うための Excel driver や Text File Driver を同梱しています。

これらの driver は当初 MDAC として別の component として提供されていましたが、Windows 2000 から OS に同梱されるようになり、Windows XP 以降では別の component として提供されることは無くなりました。なお、JET は MDAC 2.7 以降で MDAC から削除されていますが、Windows 2000 以降の OS では標準で Microsoft JET (version が古い可能性はある) が含まれているため、そのまま利用できます。

具体的な利用方法は下記を参照してください。

詳細の公式 reference は ODBC のものしかないですねぇ。

Microsoft Excel Driver Programming Considerations

まあ、この公式情報の少なさが積極的に利用されない理由だったりすると思うんですが。もっともあまりにも簡単に扱えると Microsoft Excel の売り上げに響く可能性がありますからねぇ。。。

Excel を必要とせず Excel Workbook を扱える Microsoft JET ですが、いくつか制限があります。代表的なものとしては下記。

1 cell で扱える文字長は 255 (Unicode 510 bytes) まで
Password 保護された workbook は扱えない (IRM 保護されたのももちろんダメ)
Cell の data しか扱えない (AutoShape や Graph は扱えない)

これらの制限がありますが、それなりに利用価値はあるでしょう。Server-Side でも support されていますので。

あと、Microsoft Excel 2002 から利用可能になった、XML format (Office Open XML とは異なる) がありますが、ここでは扱いませんのであしからず。

AssemblyFileVersion

ちゃっぴ (tyappi@wankuma.com) — Sat, 26 Jun 2010 18:37:00 GMT

先日、version 管理を自動化しようとしてやってしまった失敗。

アプリケーションのバージョンの管理

上記に記述があるように AssemblyVersionAttribute に "1.0.*" を指定して compile したわけだけど、その時 AssemblyFileVersionAttribute にも "1.0.*" を指定してしまった。

Unit test 通った後でちょっと忙しかったこともあり、他の人に compile お願いといって test までお願いすることに。その後、test で log 出力がうまくいかないと連絡が。。。

Log 出力は FileLogTraceListener を利用しているんですけど、その初期化時に System.ConfigurationException「パスに無効な文字が含まれます。」で落ちる。正確にはSystem.Security.Permissions.FileIOPermission.HasIllegalCharacters(String[] str) でね。Configuration file がおかしいのかな？と思っていくら変更してもダメ。

しゃー無いので build し直してみる。すると下記警告が。。。

アセンブリの生成 -- 'ファイルバージョン' に指定されたバージョン '1.0.*' は正常な 'major.minor.build.revision' フォーマットではありません。

とりあえず修正してみた。。。結果、正常に動作した！これかよ！

Assembly vesion と file version は一致させたかったので、AssemblyFileVersionAttribute を comment out して解決。

ちゃんと reference 読んでみると AssemblyVersionAttribute には "*" の説明載っているけど AssemblyFileVersionAttribute には載っていない。あ～そのなのね。確認すると build された assembly の file version には "1.0.*" がそのまま入っていました。

でも、「パスに無効な文字が含まれます。」この message は無いな～。そもそも path の問題じゃないし。もう少し、わかりやすい message 返してよ。

ってゆうか compile 時に警告ではなく error にしてよ。動かないのあるのなら。

VS2010 Unit Testing で XML の test data を project root 以外に配置すると。。。

ちゃっぴ (tyappi@wankuma.com) — Mon, 03 May 2010 17:59:00 GMT

VS2010 で Data-Driven Unit Testing を行うため、wizard にしたがって XML file を DataSource に設定すると下記のような attributes がつきます。

[DeploymentItem("TyappiTest\\TestData.xml")]
[DataSource(
    "Microsoft.VisualStudio.TestTools.DataSource.XML"
  , "|DataDirectory|\\TestData.xml"
  , "case"
  , DataAccessMethod.Sequential)]
[TestMethod()]


XML file が project の root に配置されている場合には問題ありませんが、sub folder を配下に格納した場合にはうまく動作しません。"TestData" という sub folder に配置した場合、 wizard で自動生成される attributes は下記になります。
[DeploymentItem("TyappiTest\\TestData\\TestData.xml")]
[DataSource(
    "Microsoft.VisualStudio.TestTools.DataSource.XML"
  , "|DataDirectory|\\TestData.xml"
  , "case"
  , DataAccessMethod.Sequential)]
[TestMethod()]
この状態で unit test を実行すると下記 error が発生します。
単体テスト アダプターがデータ ソースに接続できなかったか、データを読み込めませんでした。このエラーのトラブルシューティングの詳細については、MSDN ライブラリの「Troubleshooting Data-Driven Unit Tests」(http://go.microsoft.com/fwlink/?LinkId=62412) を参照してください。エラーの詳細: オブジェクト参照がオブジェクト インスタンスに設定されていません。
この問題を修正するためには下記のように attributes を修正します。
[DeploymentItem("TyappiTest\\TestData\\TestData.xml")]
[DataSource(
    "Microsoft.VisualStudio.TestTools.DataSource.XML"
  , "|DataDirectory|\\TestData\\TestData.xml"
  , "case"
  , DataAccessMethod.Sequential)]
[TestMethod()]
上記のように DataSourceAttribute constructor の第二引数に与えられている path を手動で修正する必要があります。
なお、対象の XML file の property "出力ディレクトリにコピー" が「コピーしない」になっている場合も同様の error が発生しますので、「新しい場合にはコピーする」もしくは「常にコピーする」に設定するのをお忘れずに。
というか、wizard だけで問題なく動くようにしてくれないかなぁ。。。

異なる Encoding で利用できない文字を検出する Class 改

ちゃっぴ (tyappi@wankuma.com) — Mon, 03 May 2010 17:37:00 GMT

以前作ったものを extension method に変更してみた。

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Globalization;
using System.Text;
namespace Tyappi.Text
{
  /// <summary>
  ///   Encoding class を拡張します。
  /// </summary>
  public static class EncodingExtention
  {
    #region Public Methods
    /// <summary>
    ///   変換できない文字列が含まれているか確認します。
    /// </summary>
    /// <param name="value">確認対象の文字列。</param>
    /// <returns>
    ///   変換できない文字列が含まれる場合には true を返します。
    ///   変換できない文字列が含まない場合には false を返します。
    /// </returns>
    public static Boolean IsCovertable(
        this Encoding encoding
      , String value)
    {
      Boolean result;
      if (value == null)
      {
        result = true;
      }
      else
      {
        String converted = EncodingExtention.CyclicConvert(encoding, value);
        result = value.Equals(converted, StringComparison.InvariantCulture);
      }
      return result;
    }
    /// <summary>
    ///   変換できない文字列を取得します。
    /// </summary>
    /// <param name="value">確認対象の文字列。</param>
    /// <returns>
    ///   変換できない文字の index と文字で構成される KeyValuePair の
    ///   ReadOnlyCollection を返します。
    ///   変換できない文字が存在しない場合には要素 0 の ReadOnlyCollection を返します。
    /// </returns>
    public static ReadOnlyCollection<KeyValuePair<Int32, String>> 
      GetInconvertableChars(this Encoding encoding, String value)
    {
      List<KeyValuePair<Int32, String>> result 
        = new List<KeyValuePair<Int32, String>>();
      if (value != null)
      {
        String destination = CyclicConvert(encoding, value);
        TextElementEnumerator enumerator 
          = StringInfo.GetTextElementEnumerator(value);
        while (enumerator.MoveNext())
        {
          String sourceChar = enumerator.Current.ToString();
          String destinationChar
            = destination.Substring(
                  enumerator.ElementIndex
                , sourceChar.Length);
          if (!sourceChar.Equals(destinationChar))
          {
            KeyValuePair<Int32, String> pair
              = new KeyValuePair<int, string>(enumerator.ElementIndex, sourceChar);
            result.Add(pair);
          }
        }
      }
      return result.AsReadOnly();
    }
    #endregion
    #region Private Methods
    /// <summary>
    ///   一度指定した encoding へ変換を行った後、元の encoding へ
    ///   再変換します。
    /// </summary>
    /// <param name="source">対象の文字列。</param>
    /// <param name="encoding">変換先の encoding。</param>
    /// <returns>再変換を行った文字列。</returns>
    private static String CyclicConvert(Encoding encoding, String source)
    {
      String result = null;
      if (source != null)
      {
        Byte[] encodedBytes = encoding.GetBytes(source);
        result = encoding.GetString(encodedBytes);
      }
      return result;
    }
    #endregion
  }
}

Extension method 良すぎ！ちょっと前から中毒状態です。

Visual Studio Unit Test では Unicode CSV は扱えない

ちゃっぴ (tyappi@wankuma.com) — Mon, 03 May 2010 16:57:00 GMT

Visual Studio で Unicode とか JISX0213 で拡張された文字を扱った unit test を作りたかったりするわけですが、Visual Studio Unit Test で扱える CSV の encoding は default ANSI code page のみです。UTF-8, UTF-16 で保存しても、文字化けしてまともに扱えません。

ではどうするべきか？

XML か DB 使うしかないですね。

ってか、Encoding ぐらい指定させてよ。

EventLogTraceListener の実装がひどい (Windows XP)

ちゃっぴ (tyappi@wankuma.com) — Sun, 11 Apr 2010 03:29:00 GMT

「EventLog.SourceExist method は例外を垂れ流す」の続き。

EventLog.SourceExist method がまずいことを書きましたが、EventLogTraceListener classs の Windows XP での実装がおそらくこれを利用しているために深刻な問題が。とりあえず、Windows XP で下記 code を実行してみてください。

using System;
using System.Diagnostics;

class Program
{
  static void Main(string[] args)
  {
    TraceSource traceSource = new TraceSource("TestTraceSource");
    traceSource.Switch.Level = SourceLevels.Error;
    traceSource.Listeners.Add(new EventLogTraceListener("TestApplication"));
    traceSource.TraceEvent(TraceEventType.Error, 1, "Test");
  }
}

結果

ハンドルされていない例外: System.Security.SecurityException: ソースが見つかりま
せんでしたが、いくつかまたはすべてのログを検索できませんでした。アクセス不可能な
ログ: Security
   場所 System.Diagnostics.EventLog.FindSourceRegistration(String source, String
 machineName, Boolean readOnly)
   場所 System.Diagnostics.EventLog.SourceExists(String source, String machineNa
me)
   場所 System.Diagnostics.EventLog.VerifyAndCreateSource(String sourceName, Str
ing currentMachineName)
   場所 System.Diagnostics.EventLog.WriteEvent(EventInstance instance, Byte[] da
ta, Object[] values)
   場所 System.Diagnostics.EventLog.WriteEvent(EventInstance instance, Object[]
values)
   場所 System.Diagnostics.EventLogTraceListener.TraceEvent(TraceEventCache even
tCache, String source, TraceEventType severity, Int32 id, String message)
   場所 System.Diagnostics.TraceSource.TraceEvent(TraceEventType eventType, Int3
2 id, String message)

この現象なんですけど、Windows Vista, Windows 7 環境では再現しないんですよね。正常終了します。内部の実装 OS によって違ってるとしか考えようがない。

2010/4/25 追記

.Net Framework 4.0 では Windows XP 環境でも例外発生しません。

EventLog.SourceExist method は例外を垂れ流す

ちゃっぴ (tyappi@wankuma.com) — Sun, 11 Apr 2010 03:04:00 GMT

EventLog.SourceExist method は check method なのに例外を垂れ流します。これで困るのが standard user で利用した場合。とりあえず、下記 code を実行してみてください。

using System;
using System.Diagnostics;

class Program
{
  static void Main(string[] args)
  {
    Console.WriteLine(EventLog.SourceExists("存在しない source"));
  }
}

下記例外が発生します。

ハンドルされていない例外: System.Security.SecurityException: ソースが見つかりませんでしたが、いくつかまたはすべてのログを検索できませんでした。アクセス不可能なログ: Security

直接の原因は下記 registry key の ACL。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security

Windows 7 の既定では下記のように ACL が構成されています。

Account	ACL
System	フルコントロール
Administrators	フルコントロール
eventlog	読み取り

ということで、standard users には権限が無いですね。

しかし、SecurityException とはいえ、check method で例外を垂れ流すのはひどいですね。読み取りの場合、権限無いものは無視するのが鉄則だと思うのですが。。。次の version でもいいのでぜひ修正して欲しいものですね。

既存との互換性を考慮して修正しない場合には下記 method を追加する手もあると思いますね。

EventLog.SourceExist(string source, string machineName, string logName)

最も利用される log は "Application" なので、多くの場合こちらを利用することで回避できるでしょう。

2010/4/25 追記

.NET Framework 4.0 でもこの問題は再現しますね。

Visual Studio の unit test framework は x64 で動作できない

ちゃっぴ (tyappi@wankuma.com) — Sun, 03 Jan 2010 19:23:00 GMT

C++/CLI で作った class の unit test を作成している時のこと。x86 なら動くのに x64 では動かない！

環境: Visual Studio 2008 Professional Edition SP1

C++/CLI で作った managed class に対する C++ test project を作成した場合、platform を x64 に切り替えても test 用の dll がなぜか x86 で compile されている現象を dumpbin.exe にて確認。

C++/CLI で作った managed class に対する C# test project を作成した場合、platform を x64 ると test 用の dll を読み込む段階で System.BadImageFormatException が発生。Host する "VSTestHost.exe" が x86 用 image なのでその影響でしょうね。

C++/CLI で projects を作っていると x64 でも unit test が必要になると思うのですが、この仕様？は何でしょうかね。なんとかしてくれ！