■ Index ■ ■ ■ ■

• 64ビットOS使用時の2008のスプラッシュ画面に表示される登録ユーザーをMicrosoft様から変更する
• TFSのビルドサーバーとか使わずにVisual Studio だけでProjectの参照設定をReleaseとDebugで変えてみる
• Partial class
• Vistaのアクセス・キー
• 2008で久々のDLLバージョン違い
• Atlasこと「ASP.NET AJAX 1.0」と「AJAX Control Toolkit」を食してみる
• ListViewをアレコレ(LargeIconな画像ビューアでドラッグ＆ドロップしてついでに自動スクロール)使ってみる
• 2005どこまで進化？
• mainMenu恐るべし
• まだまだシャチ君現役
• Resource使うとき、いつもアイタタタ...
• 開発者のグラフィックツール
• System.CodeDom は誰のため(予定)
• インストールシールド談

64ビットOS使用時の2008のスプラッシュ画面に表示される登録ユーザーをMicrosoft様から変更する ■ ■ ■ ■

RosarioことVisual Studio 2010の発売を来月に控えていまだ2008ネタです。

いつのころよりかVisual Studio 2008のスプラッシュ画面に表示される登録ユーザーと組織がなぜか「Microsoft」様に。なんかぁゃしぃ製品使ってるぽくて気持ちは悪かったんですけど、まぁたいして実害もないからいいかとほっておいたんです。 が、AssemblyInfo.csのAssemblyCompanyとAssemblyCopyrightのデフォルトがスプラッシュ画面に表示される登録組織なんで毎回毎回書き換えるのに疲れちゃいました。イヤ正確にはそのうちAssemblyInfoの書き換え忘れてビルドしたバイナリをリリースしそうで...

重い腰を上げていつからこうなったのか、なんでこうなったのか調べてみることに。確かこの類の情報って使用OSセットアップ時の登録情報をそのまま使っているか、製品セットアップ時に使用OSセットアップ時のソレをデフォルトで表示して修正・登録されていたような、ないような。記憶をたどれば、そういや、そもそも最近のOSはセットアップ時に登録ユーザーを入力する画面が表示されていないような...

そこでXPまでさかのぼってOSセットアップ時とVisual Studio 2008セットアップ時の登録ユーザーと組織を確認。(自社の製品セットアップ用に構築してあったHyper-Vの各OS環境でまさか「Microsoft」様のセットアップテストする羽目になろうとはトホホ)

結局よくわからん結果となりぐぐって見るとChanging the Visual Studio Splash Screen Registered Userという記事が...

まぁレジストリの情報表示してんだろなとは思っていましたし、HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersionあたりは怪しいと思っていたんですけど、Wow6432Nodeですか

で、本日のまとめ

64ビットOS使用してるときにはVisual Studio 2008の登録組織(ユーザー)はHKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows NT/CurrentVersion/RegisteredOrganization(RegisteredOwner)を変更する ってことで...

(2010.02.20 M記)

TFSのビルドサーバーとか使わずにVisual Studio だけでProjectの参照設定をReleaseとDebugで変えてみる ■ ■ ■ ■

Solution内のProjectに設定されている参照設定をReleaseとDebugで変えたいのだけど...と相談を受けました。

一般的には、だったら関係するProjectをすべてSolution内に追加し、参照設定を「プロジェクト」にすればいいじゃない。ということになるんでしょうけど、大規模な開発で参加する人・組織が複雑だったり、これまでの資産として培ってきたDLL、クラスが多かったり、C#、C++/CLI、VB.NETと利用する言語がさまざまな理由から混在していたり、動的なDLLのLoadをしているのでアセンブリ間のつながりが直接なかったり、なかなか同一Solutionの中に利用しているすべてをProjectとして取り込むことが難しい状況があります。

ちょっと前置きが長くなりましたが、様々な理由からProjectの参照設定をReleaseとDebugで変えたいなと考えても、出力先(ビルド先)は簡単に変えられるのに参照設定を変える方法はVisual Studioにはありません。

そこでちょっと調べてみるとSebastian Good さんという方のブログにDifferent References between Debug and Release Builds in Visual Studio 2005というタイトルが...

おぉこれこそまさに望むタイトル。(in Visual Studio 2005ってなってるけど、Visual Studio 2005と2008は出来の悪い双子のようにそっくりだし :-p)

ただ、このサイトのコメント欄にも書かれているように、ソリューション エクスプローラーに同じ名前の参照設定が2つ現れるし、Activeなビルドでないほうは黄色の!マーク付いてるし...

でもちょっと待て、そもそも「Condition」って拡張タグは「ItemGroup」だけじゃなくて、その下の階層の「Reference」の「HintPath」にだって効き目あるんじゃないの?...

ビンゴ!でした。

で本日のまとめ。Visual Studio だけでProjectの参照設定をReleaseとDebugで変えるには

1. プロジェクトファイル(.csprojとか.vbprojとか)をテキストエディタで編集する。
2. 修正内容は各「Reference」の配下の「HintPath」に「Condition」拡張タグを付加する。
3. 「HintPath」はReleaseとDebug用にそれぞれ1つずつ作る。(たぶんこれまで1つだったハズだからもう一つ追加))

以下のような感じです。

<ItemGroup>

<Reference Include="ClassLibrary1, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">

<SpecificVersion>False</SpecificVersion>

<HintPath Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU'">..\ClassLibrary1\ClassLibrary1\bin\Release\ClassLibrary1.dll</HintPath>

<HintPath Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">..\ClassLibrary1\ClassLibrary1\bin\Debug\ClassLibrary1.dll</HintPath>

</Reference>

若干気になるのがActiveなビルドを変えてもリアルタイムで該当の参照設定プロパティに表示されたパスは変わらない点ですけど、ソリューションエクスプローラの「最新の情報に更新」をクリックすると反映されます。

「最新の情報に更新」をクリックせずに、表示上のパスが変わらなくてもローカルコピーなどは、ビルド時にActiveなビルドで指定した正しいパスの参照設定のDLLを使用しているようです。

(2009.06.08 M記)

Partial class ■ ■ ■ ■

Partial class使ってます?確かに1つのクラスで実装したいんだけどコードでかいし、ソースファイルとしては分割したくね? とかってケースないですか?ないですか。そーですか。でかいのはクラス設計が悪いせい。たぶん、そーでしょう。

いや、他と共用できそうな機能をベースクラスにしてそこから継承して...まぁそんな感じが正当なんでしょうけど。どーも、こいつの継承元、誰?みたいなのが苦手でなんでもかんでも1クラス化してしまう初心者です。

クラス設計の妙味はさておき、どうしてもPartial classを使いたいあなた。今回のTipsはそんなあなたへ...

Visual Studioで自動生成されたFormのPartial class(既定で「Form1.Designer.cs」とか)はソリューション エクスプローラで表示すると良い風にネストされているのに自前のPartial classはなんでならないの?

答えはプロジェクトファイル(.csprojとか.vbprojとか)にありました。プロジェクトファイルの<SubType>タグを消して<DependentUpon>タグと値(上の場合だと<DependentUpon>Form1.cs</DependentUpon>)を書けばおk。

得意になって皆に教えたら既に紹介されているのね。

(2009.02.19 M記)

Vistaのアクセス・キー ■ ■ ■ ■

気づけばこの前の更新から1年以上...(これ3つ下のTipsに書いた！ - 2年間で記事4つ)しかもTipsの対象がアクセス・キー...もはや開発Tipsと言って良いんだか orz

いや、なんかVistaってアクセス・キー設定してもアンダーラインでないよね？とは思っていたんです。そんなもんだからVistaはアクセス・キー設定の表示(アンダーライン)確認とかできないから実際キーボードから操作しないとアクセス・キー設定されたかわからないよね？って思い込んでました。

先日より新製品の開発が始まりまして(詳しい話はWeblogのほうでやるようです)メニュー作ってるときにふと気づいたんです。Altキーだけを押すとアンダーライン出るやんか!で詳しく調べると...Vistaオプションだったんですね。という訳でVistaでアクセス・キーにアンダーライン表示する方法２つ

• とりあえずAltキーだけ押してみる。
• [コントロール パネル]、[コンピュータの簡単操作]、[コンピュータの簡単操作センター]、[キーボードを使いやすくする][ショートカット キーとアクセス キーに下線を表示する。]にチェック

「キーボードを使いやすくする」ってどうなの？始めから使いやすくしちゃいけないの？

業務連絡です。

以前多言語対応の製品を一緒に開発していた皆さん。日本語の「ファイル(F)」は英語版じゃ「File(F)」じゃなくて「File」が正解です。伝えるの忘れてました。海外版出す前に修正お願いします。

(2009.02.09 M記)

2008で久々のDLLバージョン違い ■ ■ ■ ■

流行りものに弱い性格も災いして「なんかイタイことなりそうだなぁ」と思いつつも2008を実務で使うことを強力にプッシュ中。

皆「なぜ2005じゃないんだ」なんですけど新しい製品のライフサイクルを考えれば3〜4年も一世代古いIDEなんて使いたくないぃぃぃ

「最近のMS製品は新しいからって致命的なバグが出たとも聞かないし(ホントは知らないだけかも)」と説得する側でガンバろうと出張用ノート(Vista)に2005と2008をインストール。

イタイです。2008でFormのデザイナが、あがりません。「サービス Microsoft.VisualStudio.Shell.Interop.ISelectionContainerは既にサービス コンテナに存在します。パラメータ名：serviceType」なんだそうで...

まだ店頭に製品並んでないし、引っかからないだろうなと思いつつググるとありました。MSDNフォーラム。この人はExpress版だけど製品版だってなるよぉ

結局MSDNフォーラムには決め手となる解決方法はなかったんだけど、そこにあるリンク先のフィードバックの回避策に、「this problem has been solved.VS 2008 installer does not install updates from this folder by default」とある。

実はこの前の出張の時(12月)にも2008を入れてたがその時はキチンと2008が動いていた記憶が...

その後フォーマットして再インストールして現在に至る訳だけど、あの時は確かVS2008より先に.NET Framework 3.5だけWindows Updateで入れていたような...

泣く泣く再フォーマットしてVS2008より先にWindows Updateで.NET Framework 3.5だけインストール。無事動きました。フィードバックの回避策では「System.dll」と「system.design.dll」のバージョン確認しろとか、 Vista SP1(RC)入れたら直ったとか手動でGAC登録し直せとか、久々にMSらしい事になってます。

さて、無事に解決はしたものの「最近のMS製品は新しいからって致命的なバグが出たとも聞かないし」なんて口が裂けても言えんです。

(2008.01.30 M記)

Atlasこと「ASP.NET AJAX 1.0」と「AJAX Control Toolkit」を食してみる ■ ■ ■ ■

流行りものに弱い性格も災いして「なんかイタイことなりそうだなぁ」と思いつつも「ASP.NET AJAX 1.0」を実務で使うことに

UpdatePanelの幅が指定できなくてさっそく困ったことに...当然そういうことはググっても見当たらない。

なんかちょっと触ってみました的な記事はヒットするが「本当にアレ(UpdatePanelの幅が指定できない事)でみんな困ってないの?」

仕方ないので、検索オプションを「ウェブ全体から検索」にすると、いたいた。相変わらず外人さんは正直なようでここで「できないyo」と言ってる人発見。 しかしそのリプライが「Its not so easy to do... 」とまた冷たい。

結局htmlで悪しき習慣と言われる「レイアウトのためのtableタグ」をUpdatePanelの中に入れ子にして<table style="width: 999px;">みたいに指定すると指定幅になるようで。ただこれも<table style="width: 100%;">だとダメなのね。

もとがWindows Applicationな私にはいつまでたっても「レイアウトのためのtableタグ」は馴染みません(最近じゃWindows Application用のTableLayoutPanelなんてものまであるけど)。あとWebな人ってデザインモード時のレイアウトと実行時のレイアウトが異なることはあんまり気にならないのかな?不思議

(2007.11.29 M記)

ListViewをアレコレ(LargeIconな画像ビューアでドラッグ＆ドロップしてついでに自動スクロール)使ってみる ■ ■ ■ ■

気づけばこの前の更新から1年以上...しかもTipsの対象がListView orz

そう、「あの」ListViewです。正直ナメてました。Tipsなんちゅう程のこともなく皆さん使いこなせてることと思いますが、普段あまり使わない事にはMSDNにもネットにもなかなか見つからない「技」があるようで。

事の発端はさる業務アプリケーションに簡単な画像ビューアと表示された画像の並び替えをドラッグ＆ドロップでやりたいというまぁ良くある仕様なのですがなにしろ画像関係のアプリケーション専門というわけでもないのでExplorerだってListViewで画像ビューアまがいのことしてるし、いけるんじゃね？と簡単に考えていたのが間違いでした。

1. ViewをLargeIconにして画像ビューアなど作ってみる。

   基本的な実装はアットマーク・アイティのこのTipsのようにListViewの画像の源となるImageListにサムネールを作ればおｋな訳で、強いていえばキモはListViewのItemRectの大きさを決めるのがListViewではなくImageList.ImageSizeである事くらい。

2. ドラッグ＆ドロップなど実装してみる

   「Microsoft ListView ドラッグ」でググると(Micorosftを頭に付けたのは願わくばMSのKBにヒットしますようにという願望)コレがHit。てかソレTreeViewじゃん。イヤイヤTreeViewとListViewは出来の悪い双子のようにそっくりだ。TreeView独自のプロパティだけListView用に変えればイケルはず。と考えたのが浅はかでした。その後ほかのサイトも見たけど コレとかコレ(ってTreeViewだけど)

   要は

   • AllowDropをtrueにする
   • ItemDragイベントでDoDragDrop メソッドを呼びドラッグ＆ドロップを開始
   • DragEnterイベント、DragOver・DragLeaveイベントなどにドラッグ＆ドロップ可不可のための処理をごにょごにょ
   • DragDropイベントでListViewのitem入替え(MOVE)だったり挿入(COPY)だったり
   という流れ。完成です。ってどこにドラッグしても対象itemが一番最後にしか移動(コピー)しないじゃん。なんで？？
3. LargeIconは別なのさ...

   TreeViewやListViewでもこの流れでうまくドラッグ＆ドロップ出来るものもある。(上記の参考にしたサイトのは皆動作してる)何が違うの？半日かかりました。どうもViewがLargeIconだとダメなようです。

   でまたググると...ありました。ここでは「バグじゃね？」と血圧上がってます。オオッ、この人「バグのようだ。だが、しかし対応はイージーよ」と言っている。

   どうもAlignmentを「リセット」(一度Defaultセットして再度お好みのAlignmentをセットしなおす)すれば良いと。本当だ。ドロップした位置に再表示される！

4. スクロールする位Item多いとダメダメじゃん

   うまくいったと思ったこの方法、Item数増やしてスクロールする位になるとサムネール(ことLarge Icon)は意図した並びになるけど再描されてListViewの位置が先頭に戻る。

5. InsertionMark(ドロップ先を示す挿入マーク)を実装してみる

   ドロップ後の再描問題はおいといて、ドラッグ中にドロップ先を示す挿入マーク(InsertionMark)を実装することに。これはMSDNにそのものズバリ「方法 : Windows フォーム ListView コントロールに挿入マークを表示する 」があった。キモはNearestIndexを使うことか。なるほど

6. なぜindex順に並べ替える「ListViewItemSorter」をわざわざ準備する？ハッもしかして

   ところで上のMSDNのソース、よく見るとなんか変だ。ListViewItemSorterを使ってる。ソレは良いとしてListViewItemSorterって言うのは普通にIndex順に並べられない順序でソートしましょうって時に使うものでしょ？その中でなんでindex順並び替えのためのCompare実装してるの？訳わかんない？はっ...

7. ListViewでViewがLargeIconの時はListViewItemSorterを準備してindex順を保たせる

   そうです。このListViewItemSorterはLargeIconでソートがうまく行われないのをカバーするためだったんですね...やるなMS。結局LargeIconでソートを「わざわざ」してないのは「グラフィックベースのLargeIconでindex順ソート毎回かけるとキツかんべ、どうしてもっちゅうならListViewItemSorterでやってね」というMSの親心？でしょうか？

8. Auto Scrollなど実装してみる

   なんどかドラッグ&ドロップ出来るようになったものの、自動スクロールしないので表示されているより下 or 上にはドラッグできない！またまたググると...ありましたズバリ「ListView Drag & Drop With Auto Scrolling in .NET」んがしかし、なんか動きが悪い。正直思ったようにスクロールしない。でまたまたTreeViewなんだけど「Dragging tree nodes in C#」でも、自動スクロールしてる。TreeViewとListViewは出来の悪い双子のようにそっくりだ(まだ懲りてない)。TreeView独自のプロパティだけListView用に変えればイケルはず。なるほどTimerつかってTreeView矩形の上30、下30に近づいたらEnsureVisibleで、もちょっと下(or上)のindex指定すれば勝手にスクロールするハズと...後はその、もちょっと下のindexとか、もちょっと上のindexをListView独自の方法に置き換えて指定すれば良いっと...

9. 完成、んが、しかし

   今度こそ完成。そういえば別のFormでも同じサムネール表示をListViewでする設計でしたな。ならば画像源のImageListを2度構築するのもなんだから共通に持てるインスタンスとしてpublicかなんかで持っとこ。

   エエッー

10. ImageListのインスタンスはForm間で引き継げない。継承もできない。

    「Sharing and inheriting ImageLists across multiple forms and controls」にあるようにどうもForm間ではImageList引き継げないようです。結局今回はこのCodeProjectのTipsは使わず、Formでなく2つのUserControlとすることで逃げました。

オレ様メモ用にサンプルコード置いておきました。よろしければお持ち帰りください。

(2007.02.27 M記)

2005どこまで進化？ ■ ■ ■ ■

2006年も始まったのに未だ製品版としては登場しないVisual Studio 2005。MSDN会員はダウンロードできるということで早速評価を始めました。気になるのは下で紹介した「不具合」

1. mainMenuがあるとレイアウトが崩れる（ことがある）

   オオッ、見事修正されているじゃありませんか。

2. セットアッププロジェクトでは「SendTo(送る)」ショートカットが作れない

   ありゃりゃ、コレはまだのようで。

(2006.01.06 M記)

mainMenu恐るべし ■ ■ ■ ■

mainMenuコントロール でやられました。

mainMenuコントロールをFormに貼り付け、フォームデザイナではいい感じにコントロールを配置、余白を調整してイザ実行...勝手に下余白が広くなる。

図 1. デザインモード時のFormとそれを実行したForm(C#で作成 高さの違いに注目)

上のスクリーンショットは実行(デバッグ開始)直後のもので特別、実行後にFormのサイズ変更をしている訳じゃありません。この後、ソリューションを閉じて開いたらデザインモードでもいつの間にかFormがこのサイズになっていました。

結局、Formのプロパティを以下の組み合わせにするとこの現象が発生することがわかりました。

1. FormにmainMenuがある
2. Form Size プロパティ = Form MinimumSize プロパティ
3. Form上のコントロールにAnchor = Bottom設定(上の図ではbutton1にAnchor = Bottom,Rightが設定されている)

Client RectのY座標の原点がMinimumSizeとコントロールのAnchorで違っている様な...

アッ、Tips的には上のような現象起こすのでForm Size = Form MinimumSize + mainMenuの高さ(20Size前後?)としましょう...と(2005.02.20 M記)

まだまだシャチ君現役 ■ ■ ■ ■

いるか君はいつの間にか見なくなったけどシャチ君は現役、Visual Studio .NET 2002・2003の「セットアップ/デプロイメント」プロジェクトの登場でORCA不要かと思ったけど、要るときゃ要る。

図 2. 某いるか君 プライバシー保護のため顔は伏せさせていただきました。

SendToショートカットのバグのせいでシャチ君大活躍。私も同様の現象で悩みました。

上のリンク、訳したものを載っけときます。

Jerry Houston

コマンドライン上のファイル・パスを受ける小さなユーティリィティを作成し、ユーザがエクスプローラー中のいくつかのファイルをSendToを使って選択することができるようにしたかった。

私が、my Documents and Settings\<username>\SendToフォルダーに手動でショートカットを作成すれば、その動作はすばらしいので、他の人もSendToをよく使用すると考えました。

そこで、私はセットアップ・プロジェクトの一部としてのそのショートカット作成を自動化したかった。ショートカットがセットアップによって作られることには問題はなかった。

しかし、SendToフォルダーにコピーされるショートカットはエクスプローラー・コンテキストメニューの中で現われません。(セットアップ・プロジェクトによって)作成されたショートカットは、私のXPマシン上のサイズは2Kです。その一方でそのフォルダーにもともと作成されたショートカットは、たった1Kです。

したがって、他の動作しているものとセットアップ・プロジェクトによって出来上がったものには違いが明確にあります。

XPがそれを認識し、そのSendToリストにアプリケーションを含んでいるように、installプロジェクトによって作成されたショートカットを修正するために、私は何をする必要がありますか。どんなアドバイスでも感謝します。

Todd Derksen [MSFT] (VIP)

Jerry、その現象はあなたのMSIファイルを若干修正する必要があります。その現象が起こっているのは、設定プロジェクトが「送る」フォルダーへ使用された時偶然働かないショートカットを作成するということです。

あなたのディプロイメント プロジェクトで標準のショートカットを作成するために、ORCAツールを使用する必要があるでしょう。

それは、ウィンドウズの「Windows installer SDK」に付属します。ここで入手可能

あなたが行わなければならないのは、orcaを使ってMSIを開き、ショートカット・テーブルに行くことです。ショートカット・テーブルでは、あなたのプロジェクトが作成するすべてのショートカットへのエントリーを見つけるでしょう。 「DEFAULTFEATURE」からたぶん、「[TARGETFOLDER]￥app名」にターゲットを変更しなさい。(訳注:[TARGETDIR]￥app名でした)

[TARGETFOLDER] はインストールされたフォルダーへ拡大するマクロです。Icon_columnは知らせられたショートカットに必要で削除される必要があります。(訳注:削除せずVS2003からアプリケーションのiconに先に変更しても問題ありません。)

あなたの手助けになればいいですね。

------

Todd Derksen - VBQA Deployment Testing

この投稿は「あるがまま」の状態で配信され如何なる権利もありません。

SendToショートカット作れなかったら、またあの「InstallShi■ld X(or 10.5)」使うのかと小一時間悩みました。

シャチ君とToddに感謝。(2005.01.14 M記)

図 3. orcaでSendToフォルダのショートカットを修正中

その後、上で紹介したリンクは.NET Monsterがオリジナルらしいです。(ここでは最後のレスでちゃんと「[TARGETFOLDER]￥app名」でなく「[TARGETDIR]￥app名」だったよ〜って書かれていますね。)

わざわざ海外のサイトを取り上げなくても同様の問題日本の掲示板でも取り上げられてるよと情報いただきました。 GotDotNet Japan 掲示板とVisual C++倶楽部 ツリー質問掲示板 ありがとうございます

Resource使うとき、いつもアイタタタ... ■ ■ ■ ■

何度やっても忘れる。(頭が悪い とも言う)「ん、リソース読み込まん」
コイツのせい

図 4. 「規定の名前空間」は新しいソースファイルを作った時使われるだけじゃありません

開発者のグラフィックツール ■ ■ ■ ■

もちろん、Adobe Photoshopとか使ってるんならそれで良し。MicrosoftだってプログラムのためのグラフィックにPhotoshopやMacromedia FreeHand、Adobe Illustratorを薦めているんだから...

図 5. Microsoft HTML Help Image Editor

System.CodeDom は誰のため(予定) ■ ■ ■ ■

ソース コード ドキュメントをプログラムでイジれると何がうれしいの？
そもそもSystem.CodeDomは動的にプログラムを生成しようとする偏執狂気味の開発者のため？ いやいや、カスタムコントロールを作ると、どうしてもCodeDomは必要なのだ。

' メモ : 以下のプロシージャは、Windows フォーム デザイナで必要です。

'Windows フォーム デザイナを使って変更してください。  

' コード エディタを使って変更しないでください。

<System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()

    components = New System.ComponentModel.Container()

というあの忌々しいコメントとCodeDomの関係(2004.11.24 M記)

インストールシールド談 ■ ■ ■ ■

記念すべき第一回、さぁ書くぞ！と意気込んだのはいいものの、プログラマ初心者の私が、そうそういいネタを思いつく物ではない。

そこでだ・・とびっきり凄いネタなんてのは当分は私には無理なような気がするので、同じ境遇の初心者の方にちょっとした情報提供みたいな感じで書いていけたらいいなぁ〜と思う次第である。

さて第一回のお話だがインストールシールドである。どんなソフトかと言うとソフトをPCにインストールする時に使われるインストール用のしかけ(通称インストーラー）を作るソフトである。

インストーラーに関してはおそらく使ったことの無い人はほとんどいないのではないか？思うのだが、「インストールシールド知ってる？」と聞くと「何それ？」と言う人が意外と多い・・・

それぐらい実は影が薄かったりする。何故かというと、名前の通りインストール時にしか使われない、つまり出番が少ないからだったりするからである（笑

そんなインストーラだけど、こいつがインストール時にへまやっちゃうと、その先全く進まなくなっちゃうので、実はとっても重要なウェイトを占めていたりする。

他にもソフトウェアのバージョンUPをする際にファイルの上書きの設定なんかもこいつで設定してたりするので、一歩間違えばとんでもない事態を引き起こすこともある。だから作業を行う際は凄い神経を使うことが多い・・というか神経を使う、神経使いすぎてミスをする事もあるが･･･（笑

まぁこんな感じである。今回はインストールシールドを使っていて私が「へぇ〜」と思った事を書こうと思う。

通常ソフトウェアをインストールする時ってのは「*setup.exe」なんてファイルをダブルクリックしてソフトウェアのインストールを行っていると思う。うん、これに関しては別に問題は無い。じゃぁアンインストールする時はどうだろう、もちろん「*uninstall.exe」ってファイルをダブルクリックして・・・なんて人はおそらくいないし、そんなファイル見たこと無い。

通常はコントロールパネルのアプリケーションの追加と削除からアンインストールを実行していると思う。アンインストールを実行するとインストール時と同じような画面が出てきて、ファイルがぽいぽい消されていくって感じだ。

そうアンインストーラが動いているのである、だけどそんなexeを見ることは少ないと思う、というか私は見たことはない。インストールシールドに限って言うと実はインストーラーとアンインストーラは一体になっているものが多いからだ。つまり「*setup.exe」が両方の機能を兼ね備えているって事だ。

だけどここであれ？って思う人も多いと思う。ソフトのインストールが終わったらsetup.exeは消しちまったぜ！ということは結構多い、特にexeをハードディスクに落としてからインストールするDLソフトなどはこうすることが多いと思う。

だけどアンインストールは正常に動く、う〜ん不思議！じゃなくて、理由は至って簡単で、実は「*setup.exe」がどこかにあるのである。

ちなみに「*setup.exe」は通常ソフトウェアをインストールするとどこかにコピーされるのである。そしてアンインストール時はコピーされた「*setup.exe」にアクセスして、ソフトが組み込まれている場合は「*setup.exe」がソフトウェアのアンインストール　or 追加と変更なんてのを実行する仕組みになっているのだ。

ちなみにどこに「*setup.exe」がコピーされるのかというとC:\Program Filesの中にInstallShield Installation Informationという隠しフォルダに中にセットアップを行ったソフトウェア事に「*setup.exe」が保存されているのだ。ふーんほんとうにそうなっているか実験を行って今日は終わりにしようと思う（ちょっと自分も不安だし・・）試しに簡単なインストーラを作ることにする。

セットアップを行った後にInstallShield Installation Information内にある「*setup.exe」を場所を変えるなり、名前を変えるなりして、コンパネからアンインストールを実行！エラーが出る　OR　反応無しなら成功だ。

さて、では今回はファイルの場所を変更して実験。　ファイル移動後コンパネからアンインストールを実行！　反応無し　今度はファイルを元の場所に戻して実行！アンインストール作動！うまくいったようだ。良かった良かった。

とまぁこんな些細な事ではあるが、自分がこれを知ったときは「おおぉ」と思ったものである。

というところで、今日は終わりにしたいと思う。(2003.09.13 N記)