C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[11]: デブロイメントプロジェクトの流用について


(過去ログ 17 を表示中)

[トピック内 12 記事 (1 - 12 表示)]  << 0 >>

■6507 / inTopicNo.1)  デブロイメントプロジェクトの流用について
  
□投稿者/ zono (7回)-(2007/08/16(Thu) 16:40:24)

分類:[VB.NET/VB2005] 

あるプログラムをデブロイメントプロジェクトを使用しインストーラーを作成して提供していましたが、
さらにもう一つのプログラムも別にデブロイメントプロジェクトを使用してインストーラーを作成しようとしています。

既存のデブロイメントプロジェクトをコピーして、ファイルの名称や展開するディレクトリの名称等を変更し、
インストーラーを作成しました。

同一のマシンに作成した2つのプログラムをインストールしたところ、同じインストーラーとして認識されて
両方をインストールすることができませんでした。

デブロイメントプロジェクトをコピーして使用する場合、どこを変更すれば別のインストーラーとして
認識されるのでしょうか?それとも新規で作成しないといけないのでしょうか?


引用返信 編集キー/
■6508 / inTopicNo.2)  Re[1]: デブロイメントプロジェクトの流用について
□投稿者/ IIJIMAS (15回)-(2007/08/16(Thu) 16:47:18)
No6507 (zono さん) に返信

まったく別アプリであるなら
UpgradeCode プロパティ
http://msdn2.microsoft.com/ja-jp/library/465253cd(VS.80).aspx
を変えてみるとどうでしょうか。
引用返信 編集キー/
■6510 / inTopicNo.3)  Re[2]: デブロイメントプロジェクトの流用について
□投稿者/ zono (8回)-(2007/08/16(Thu) 17:42:11)
No6508 (IIJIMAS さん) に返信
> ■No6507 (zono さん) に返信
>
> まったく別アプリであるなら
> UpgradeCode プロパティ
> http://msdn2.microsoft.com/ja-jp/library/465253cd(VS.80).aspx
> を変えてみるとどうでしょうか。

返信ありがとうございます。
調べてみたところUpgradeCodeプロパティの値が一致していたので同一マシンにインストールできなかったのだと
思います。
ちなみにUpgradeCodeプロパティを変更するとDetectNewerInstalledVersion プロパティと RemovePreviousVersions プロパティが
正しく機能しなくなるとありますが、簡単にUpgradeCodeプロパティを変更していいのでしょうか?
UpgradeCodeプロパティは初期バージョンの時のみ設定すると記述されていたので・・・
DetectNewerInstalledVersion プロパティと RemovePreviousVersions プロパティを全てFalseに設定しないと
動作保証できないという意味なのでしょうか??
引用返信 編集キー/
■6512 / inTopicNo.4)  Re[3]: デブロイメントプロジェクトの流用について
□投稿者/ IIJIMAS (16回)-(2007/08/16(Thu) 18:16:59)
No6510 (zono さん) に返信
> ちなみにUpgradeCodeプロパティを変更するとDetectNewerInstalledVersion プロパティと RemovePreviousVersions プロパティが
> 正しく機能しなくなるとありますが、簡単にUpgradeCodeプロパティを変更していいのでしょうか?
> UpgradeCodeプロパティは初期バージョンの時のみ設定すると記述されていたので・・・

同じアプリのアップグレード版のインストーラ作成の場合は
UpgradeCodeは変えずに
ProductCode プロパティ
http://msdn2.microsoft.com/ja-jp/library/aafz9hx4(VS.80).aspx
を変更するようにということが記述されているのだと思います。
WindowsInstallerは同じUpgradeCodeで違うProductCodeで前のバージョンあるかどうかを識別しているので。
アップグレード版のインストーラ作成の場合はUpgradeCodeまで変えてしまうとまったく別のアプリケーションってことになってしまいます。
引用返信 編集キー/
■6522 / inTopicNo.5)  Re[4]: デブロイメントプロジェクトの流用について
□投稿者/ とっちゃん (182回)-(2007/08/17(Fri) 02:02:13)
とっちゃん さんの Web サイト
#うー。このネタ今度のセッションのおかずにしちまってもいいですかね?
#まさに、一番おいしいところだ...

さて、本題です。

インストーラプロジェクトをバージョンアップ以外の理由でコピーするのは、非常に危険どころか
インストール後の情報を内部崩壊させる可能性があります。

単にファイルをコピーするだけに見えますが、内部ではかなり複雑なデータ管理を行っているため、
ProductCodeやUpgradeCodeが違えばOKというような単純なものではありません。
見えない情報を多数持っておりそれらが実際のインストール情報管理を行う部分に
直接的に影響する部分となっています。

そのため、VSセットアップに限らず、インストール情報をデッドコピーするというのは
非常に危険な作業であるといえます。

実際、十分経験を積んだセットアップ作成担当の人であってもちょっとしたミスや
変更漏れは発生しますので、機械的にアップデートできるような仕組みがないかと
日夜苦労しているというくらい危険な作業だといえます。

確かにコピーすることでほとんど構成がおなじプロジェクトを作ることができるのですが
VSセットアップでできる程度の作業であれば、改めて設定しなおしても
それほど苦労することはないと思います。

もっとも、本当にダメかどうかは、msiを作ってみてどうなっているかを
確認してみないことにはわからないんですけどね。

引用返信 編集キー/
■6523 / inTopicNo.6)  Re[5]: デブロイメントプロジェクトの流用について
□投稿者/ 渋木宏明(ひどり) (299回)-(2007/08/17(Fri) 03:04:45)
渋木宏明(ひどり) さんの Web サイト
> インストーラプロジェクトをバージョンアップ以外の理由でコピーするのは、非常に危険どころか
> インストール後の情報を内部崩壊させる可能性があります。

そんなに危なかったっけ?

1ファイルで1コンポーネントだし、PackageCode や ComponentID, FileID はビルド毎の生成なんで、崩壊するような情報なんか持ってないような。

引用返信 編集キー/
■6524 / inTopicNo.7)  Re[6]: デブロイメントプロジェクトの流用について
□投稿者/ とっちゃん (183回)-(2007/08/17(Fri) 09:55:04)
とっちゃん さんの Web サイト
No6523 (渋木宏明(ひどり) さん) に返信

> そんなに危なかったっけ?
>
> 1ファイルで1コンポーネントだし、PackageCode や ComponentID, FileID はビルド毎の生成なんで、崩壊するような情報なんか持ってないような。
>
あれ?ComponentId ってビルドごとに変わりましたっけ?
変わらないんだ...って思った記憶があるんですが?

ComponentId さえ、代わってくれればほかは問題ないです。
どっちにしても、あんまりお勧めはできないですがね。

引用返信 編集キー/
■6526 / inTopicNo.8)  Re[7]: デブロイメントプロジェクトの流用について
□投稿者/ 渋木宏明(ひどり) (300回)-(2007/08/17(Fri) 10:33:03)
渋木宏明(ひどり) さんの Web サイト
> あれ?ComponentId ってビルドごとに変わりましたっけ?
> 変わらないんだ...って思った記憶があるんですが?

げ、ComponentId, FileId ともにビルドしただけでは変わらないですね>今確認した人
変わると思ってた…

ファイルをプロジェクトに登録した時に生成してるんかな?
(の割にはビルドが遅いような)

> ComponentId さえ、代わってくれればほかは問題ないです。

ComponentId, FileId は .msi 内でユニークであれば問題ないんじゃなかたっけ?

引用返信 編集キー/
■6528 / inTopicNo.9)  Re[8]: デブロイメントプロジェクトの流用について
□投稿者/ とっちゃん (184回)-(2007/08/17(Fri) 12:20:33)
とっちゃん さんの Web サイト
No6526 (渋木宏明(ひどり) さん) に返信

> げ、ComponentId, FileId ともにビルドしただけでは変わらないですね>今確認した人
> 変わると思ってた…
>
やっぱり。

> ファイルをプロジェクトに登録した時に生成してるんかな?
> (の割にはビルドが遅いような)
>
ビルドは、なんか妙に時間かかるんですよね。たぶんチェックとか圧縮とかで
タコなコードがあるんだと...w
#ま、ISよりは早い気もしますがwww

> ComponentId, FileId は .msi 内でユニークであれば問題ないんじゃなかたっけ?
>
ComponentId は外部識別子なので、グローバルユニークになっていないとだめです。
なので、同じフォルダに入れる同じファイルは同じ識別子でなければならない。
もちろん、同じファイルでも別のフォルダにインストールされる場合は別の値。

それ以外でも、GUIDを与えられている識別子は原則外部識別子です。
それ以外の文字列キーは内部識別子なので、中で整合性が取れていれば
別のmsiで別物に同名でも問題はありません。



引用返信 編集キー/
■6530 / inTopicNo.10)  Re[9]: デブロイメントプロジェクトの流用について
□投稿者/ 渋木宏明(ひどり) (302回)-(2007/08/17(Fri) 13:15:57)
渋木宏明(ひどり) さんの Web サイト
> ComponentId は外部識別子なので、グローバルユニークになっていないとだめです。

プロダクト横断でチェックはしてなさそーな気がするけど、Office みたいに複雑な製品体系の時はしくじるパターンがありそうっすね。

引用返信 編集キー/
■6551 / inTopicNo.11)  Re[10]: デブロイメントプロジェクトの流用について
□投稿者/ とっちゃん (185回)-(2007/08/17(Fri) 17:39:10)
とっちゃん さんの Web サイト
No6530 (渋木宏明(ひどり) さん) に返信

> プロダクト横断でチェックはしてなさそーな気がするけど

普通はバージョンアップなんかだと、デッドコピー->各種設定更新->非共有コンポーネントのId更新
なんですけどね...

>Office みたいに複雑な製品体系の時はしくじるパターンがありそうっすね。
ま、忘れたり忘れたり忘れたり...orz

引用返信 編集キー/
■6711 / inTopicNo.12)  Re[11]: デブロイメントプロジェクトの流用について
□投稿者/ zono (9回)-(2007/08/22(Wed) 17:06:31)
No6551 (とっちゃん さん) に返信
> ■No6530 (渋木宏明(ひどり) さん) に返信
>
>>プロダクト横断でチェックはしてなさそーな気がするけど
>
> 普通はバージョンアップなんかだと、デッドコピー->各種設定更新->非共有コンポーネントのId更新
> なんですけどね...
>
> >Office みたいに複雑な製品体系の時はしくじるパターンがありそうっすね。
> ま、忘れたり忘れたり忘れたり...orz
>

返事がおそくなりまして申し訳ございません。
色々と勉強させてもらいました。

実際に検証したところ、2つのプログラムをインストールしてみたところ
正常にはできました。

ただ皆さんがコメントしてくれているように、危険であるならば、今後のことを
考えて最初から作り直そうかと思っています。

色々とありがとうございました。
解決済み
引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -