NAnt＋InstallShield活用でビルド・インストーラ作成の自動化を行う：CodeZine
はじめに InstallShieldとは、インストーラを作成するためのアプリケーションです。従来、製品の新規バージョンのリリースに際しては、インストーラ作成の基となる情報が記述されているInstallShieldのプロパティファイルを手動で編集し、ビルド・インストーラ作成を行う必要がありました。この手の編集作業は、修正もれによるインストーラの作成ミスや工数の増加などを引き起こします。このような作業を自動化することによって、作業の戻りを防ぎ、確実な製品リリースを行うことができます。 本稿ではNAntおよび、NAntContribのタスクを利用して、Visual Source Safe（以下、VSS）からのファイル取得、Visual Studio.NET 2003（以下、VS 2003）ソリューションのビルド、InstallShieldプロパティファイルの編集、InstallShieldによる
WiXではじめるWindows Installer作成入門 第3回：CodeZine
今回の記事は、このうち最初の2個を使ってインストーラを作ってみたいと思います。これにより、表記文字列の問題を除いて、かなりの種類のインストーラをフォローできるのではないかと思います。インストールデータの修正 前回までのものは、できるだけ一つのブロックにまとめるように階層化した構造にしていたため、構成ごとのまとまりが見づらいものとなっていました。構造的にダメということではありませんが、インストーラの規模が大きくなってくると、所属構成ごとにグループ化した方が全体が見やすく（分割しやすく）なります。プログラムで言うところの構造化をほんの少し進めることで、かなり見やすくなります。 あくまでも一例ですが、前回の「STEdit3.wxs」の構成をまとめなおしたものを掲載しておきますので、参考にしてください（今回の記事はすべてSTEdit3をベースにしています）。 <?xml version="1.0"
正直、J2EEってやばくね？
昔、jarファイルでアプリケーションデプロイをしなきゃいけないことに対して効率が悪い！と疑問を呈したら、Javaに詳しい人が、「なんとかlet」（コードの集まり）で、デプロイ管理が確実になるからこれで良いんだって言ってた。 確かにjarファイルでまとまった形でデプロイすることは、バージョン管理の面からは信頼性が高くなる。しかし、WEBというのは更新してナンボなので、一々、jar単位で更新してたら面倒で仕方ない。やはり一度、コードがfixしたら、次回の受注まで更新は滅多にやらない「Webアプリケーション」のためのJ2EEなのだなぁと強く思ったものだ。（それならそうと教えてくれればWebサイトになんか使わなかったのにさ。） HOT deploy完成 HOT deployとは何か。アプリケーションサーバを稼動させたまま､クラスを追加､変更しても､アプリケーションのリロードは不要で､その変更が即座
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WiXではじめるWindows Installer作成入門 第6回：CodeZine
