トップページ⇒software
108コメント32KB

.NET Frameworkが必要なソフトについて

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。04/04/08 08:54ID:QWdCqTPW
Webアプリケーションだけでなくオンラインソフト開発のフレームワークとしても
非常に魅力的である.NET Framework(C♯)について、主にユーザー側の視点で
語るスレです。

.NET Frameworkとは

（開発サイドの）メリット
・VB並みのシンプルなコードと強力なＧＵＩ開発環境で
かつ、C++並みかそれ以上の見通しが良いロジックが組める

（ユーザーサイドの）デメリット
・作成したアプリケーションがとにかくメモリを食う
　（最低でも１５ＭＢぐらい持ってかれる）
・それに伴って特に起動がWin32ネイティブアプリケーションに比べて遅くなり、
　また全体的な動作の反応も悪くなる

というように、次世代（数年後？）のWindowsアプリケーション開発のデファクトスタンダードと
なりえる将来性がありつつも、現在は普及帯のPCスペックが追いついておらず、また
Longhorn発売〜普及以前の過渡期で微妙な位置にあります。
そんな.NET Frameworkについて主にユーザーサイドから語りましょう。
例：今使っているオンラインソフトが.NET Frameworkされたらどうするか
　　　.NET Frameworkの動作の遅さをある程度許容できるか　など

なお、ユーザーが対応アプリケーションを実行するのに必要な.NET Framework ランタイムは
２４ＭＢほどあるのですが、最近の(2002年秋以降？）メーカー製PCでWindowsXP SP1を
搭載したものには標準で組み込まれているようなので、ランタイムインストールの手間の
問題も時間が解決してくれるようです。

関連リンク

IT用語辞典 e-Words : .NET Framework
http://e-words.jp/w/.NET20Framework.html
0002名無しさん＠お腹いっぱい。04/04/08 08:58ID:E5HhgcpK
2ゲトー
AudioEncoderは便利だね。
0003名無しさん＠お腹いっぱい。04/04/08 09:08ID:f0v7TzVJ
Alpha2（P2P掲示板）
http://kyouzin2ch.hp.infoseek.co.jp/p2p/
0004名無しさん＠お腹いっぱい。04/04/08 10:55ID:8b+JDc0O
>1
板違い
0005名無しさん＠お腹いっぱい。04/04/08 17:12ID:QWdCqTPW
age
0006名無しさん＠お腹いっぱい。04/04/08 19:34ID:QWdCqTPW
age
0007名無しさん＠お腹いっぱい。04/04/08 19:53ID:u113bPZw
ム板池
0008名無しさん＠お腹いっぱい。04/04/08 20:04ID:QWdCqTPW
>>7
>>1嫁
0009名無しさん＠お腹いっぱい。04/04/08 21:15ID:2Ku7phy0
（・３・）　エェー
強いて言うならVBでできてるのよりはましかなとか
0010名無しさん＠お腹いっぱい。04/04/08 21:34ID:+jSu5LIY
ツインテ−ルつかっているよ。
0011名無しさん＠お腹いっぱい。04/04/08 21:36ID:MkIW45Qm
見通しが良いロジックが組めるかどうかは、そいつの技術力しだいかと
0012名無しさん＠お腹いっぱい。04/04/08 21:37ID:1aPeB5L9
カステラ
0013名無しさん＠お腹いっぱい。04/04/08 21:46ID:QWdCqTPW
＞見通しが良いロジックが組めるかどうかは、そいつの技術力しだいかと

たしかにそうだけど、便利な機能がはじめからまとまったライブラリとして
提供されている方を使った方が、同じ技術力でもより少ない労力で
目的のものが作れる。
0014名無しさん＠お腹いっぱい。04/04/08 21:49ID:QWdCqTPW
age
0015名無しさん＠お腹いっぱい。04/04/09 00:30ID:pC/MK/rR
>>1
ユーザーサイドのメリットは皆無だと仰るのですね。
僕もそう思います。
0016名無しさん＠お腹いっぱい。04/04/10 01:01ID:Ou7cUt1Y
age
0017名無しさん＠お腹いっぱい。04/04/14 18:37ID:EVxLf+QT
age
0018名無しさん＠お腹いっぱい。04/04/15 09:40ID:IaCoySpD
age
0019名無しさん＠お腹いっぱい。04/04/15 15:40ID:1B29bvHS
PCのパワー向上でパフォーマンスの問題が本当に解決するのか？
同じように中間コードを使うJavaは何年たっても遅いままなんだけど。

すごい基本的な質問なんだけどマネージドコードになるとMSはなんで嬉しいの？
x86(intel)依存を抜け出すためだけ？
0020名無しさん＠お腹いっぱい。04/04/15 23:43ID:KY0JuclN
Delphi8で作ったものにも .Net Framework　は必要？
0021名無しさん＠お腹いっぱい。04/04/16 10:05ID:KthQyhPB
>>20
同梱のDelphi7で作れば不要
0022名無しさん＠お腹いっぱい。04/04/18 10:46ID:UXY9mbQE
メモリ馬鹿食いするので糞
0023名無しさん＠お腹いっぱい。04/04/29 11:53ID:TkDKKcG1
VBのランタイムをVectorなんかから
落とすのを考えれば、大きいけどWinUp
でMSが配布しているだけマシかな？
0024名無しさん＠お腹いっぱい。04/05/02 19:02ID:AYZp9/Jh
age
0025名無しさん＠お腹いっぱい。04/05/02 19:36ID:hlxH5P+F
>次世代（数年後？）のWindowsアプリケーション開発のデファクトスタンダードと
デファクトじゃないだろ
0026名無しさん＠お腹いっぱい。04/05/02 20:12ID:AYZp9/Jh
確かに＊現段階では＊デファクトスタンダードではないね
ただこの先そうなる可能性はかなり高い
0027名無しさん＠お腹いっぱい。04/05/02 20:16ID:hlxH5P+F
そうならないだろ。
MSが他に選択肢を提供しないんだから
デファクトスタンダードではなくスタンダードだ。
Win32APIをデファクトとは呼ばないだろ。
0028名無しさん＠お腹いっぱい。04/05/02 20:17ID:CVXYRWLL
WinFXに依存すると旧来のWindowsで動かなくなるんだろ？
こりゃLonghorn出てからもWin32が主流で有り続けるような気がすんね。
0029名無しさん＠お腹いっぱい。04/05/02 20:26ID:AYZp9/Jh
正直、あの拡張を続けて醜く膨れ上がったWin32APIやMFCを今更いじりたいとは思わん
あれらは今後消えていくテクノロジーだろ
一旦.NET Frameworkのコーディングの楽さに慣れたらもう後戻りは出来んよ
0030名無しさん＠お腹いっぱい。04/05/02 20:52ID:5oXyjHg1
まぁ問題があったらその辺はMSがうまくやってくれるだろ
0031名無しさん＠お腹いっぱい。04/05/03 16:32ID:loaRGD/h
Win32に依存すると旧来のWin16/DOSで動かなくなるんだろ？
こりゃWindows95出てからもWin3.1やDOSが主流で有り続けるような気がすんね。
0032名無しさん＠お腹いっぱい。04/05/03 23:13ID:fdjgj8RQ
でも、.NETに移行してもユーザーは何一つメリットないよな。
.NETじゃなきゃできないこととか、.NETだとすごく便利なものってあるの？
0033名無しさん＠お腹いっぱい。04/05/03 23:17ID:eDahR8Hp
特にないよ。
0034名無しさん＠お腹いっぱい。04/05/04 23:19ID:hvFWIQqb
>>32
>.NETじゃなきゃできないこととか、.NETだとすごく便利なものってあるの？
Longhornの新機能すべて
0035名無しさん＠お腹いっぱい。04/05/04 23:24ID:IcfFTPVo
>34
おまえつまんね
0036名無しさん＠お腹いっぱい。04/05/04 23:35ID:FzQlPfZ7
ぶっちゃけめんどい　いらん
0037名無しさん＠お腹いっぱい。04/05/04 23:35ID:IS/c9qVf
>>35
IDがFTP
0038名無しさん＠お腹いっぱい。04/05/04 23:41ID:hvFWIQqb
>>35
つまんなくたってそれが事実何だからしょうがないだろ。

現時点で.NET Frameworkでソフトを開発したり使ったりするメリットは皆無。
Win32APIの機能を網羅していないので機能も劣るし
内部でWin32APIを呼んでいるので速度的にも遅く、
Framework(≒DLL)をアプリ起動時にロードするので起動も遅い。

LHが出るまではユーザーレベルで論ずる価値はない。
0039名無しさん＠お腹いっぱい。04/05/04 23:48ID:jKmHKrYz
>>38
＞現時点で.NET Frameworkでソフトを開発したり使ったりするメリットは皆無。

開発サイドとしてのメリットはあると思うぞ
Win32APIのように個別の関数になっているより、.NET Frameworkのような
きちんと設計されたクラスライブラリの方が断然使いやすいし。
Win32APIである程度の規模のものを作ろうと思ったら、開発効率の面から
どのみちラッパークラスは必要になってくると思う。
0040名無しさん＠お腹いっぱい。04/05/04 23:51ID:IcfFTPVo
>>38
そうだね。
おまえがつまんないのは事実だからしょうがないね。
0041名無しさん＠お腹いっぱい。04/05/04 23:53ID:hvFWIQqb
>>39
お前ほんとに.NET FW SDK使ってるのか？
>きちんと設計されたクラスライブラリの方が断然使いやすいし。
すでに実装されてる機能はそのとおりだが機能足りなさ杉。
何かやるたびに結局Win32API叩きまくりだろ。

>開発効率の面からどのみちラッパークラスは必要になってくると思う。
もうすでにMFCやVCLやその周辺の自作・他作のクラスライブラリが完備されてるだろ。
それを使うだけの話。
0042名無しさん＠お腹いっぱい。04/05/05 00:05ID:fru+1SIr
>>41
機能が足りないというが、たしかに開発するプログラムの内容にもよるだろうけど、
俺は.NET Frameworkに今のところ機能の不足を感じたことは無い。
そして特にフォームを軸としたGUI構築の簡便さは秀逸。
3ペインウィンドウなど、ある程度複雑なGUIを構築する必要がある場合、
VCと比べて必要なコード量が全然違う。
逆に言うとWin32SDKの代わりに使うメリットはこのぐらいか。
この辺りはVCでどんなクラスライブラリを使っても真似できないだろう。

ところでWin32SDKと比べたとき.NET Framework不足している機能って
いったい何よ？
0043名無しさん＠お腹いっぱい。04/05/05 00:12ID:84TV0TCB
>そして特にフォームを軸としたGUI構築の簡便さは秀逸。
特にフォームを軸としたGUI構築部分がVBやDelphiと比べて激しく貧弱なわけだが。

>ところでWin32SDKと比べたとき.NET Framework不足している機能って
>いったい何よ？
知りたきゃム板逝け
0044名無しさん＠お腹いっぱい。04/05/05 00:24ID:fru+1SIr
＞特にフォームを軸としたGUI構築部分がVBやDelphiと比べて激しく貧弱なわけだが。

そうなのか？？特に不満を感じたことはないけど。
VBは使ったことがあるが、あれにあって現在の.NET Frameworkに無い機能って
いまいち思いつかん。
よっぽど高度なGUIを設計してるのか、機能があるのにその存在に気づいてないのか。
どっちだ？？
前者ならまあ、特殊な事例ということだね。

＞知りたきゃム板逝け

変なところで不親切なんだな。
まあそんなにどうしても知りたい内容でもないからいいけど。
0045名無しさん＠お腹いっぱい。04/05/05 00:34ID:wluFGLV/
.Netはマイクロソフトが今後の自社製ソフトを
開発しやすくするためのフレームワークでーす。

メリットはセキュリティがデフォルトで強化されることでーす。
0046名無しさん＠お腹いっぱい。04/05/05 00:43ID:84TV0TCB
>>44
>いまいち思いつかん。
知らないだけだろ。
しかしノーストレスで.NETアプリ開発ができるのはある意味幸せだな。
0047名無しさん＠お腹いっぱい。04/05/05 00:59ID:fru+1SIr
>>46
＞知らないだけだろ。

たしかに、どのみち使わない機能を知る必要はないな

機能が足りない足りないというが、お前が開発するものが特殊なだけだろ
そうやって過去の遺産になりつつあるものに縛られなければならないのは大変だな
0048名無しさん＠お腹いっぱい。04/05/05 01:40ID:84TV0TCB
ﾜﾛﾀ
まぁ足りない機能は順次VS.NETがサポートしていくだろうから
それにあわせてステップアップしていきなよ。
今の.NETの標準コンポーネントだけでアプリ作っても
目の肥えたWin32API製アプリのユーザーには見向きもよれないよ。
0049名無しさん＠お腹いっぱい。04/05/05 01:43ID:7NXP+dLk
よれないですぅ
0050名無しさん＠お腹いっぱい。04/05/05 01:51ID:wluFGLV/
>>48
実はいい奴だな
0051名無しさん＠お腹いっぱい。04/05/05 20:58ID:KfZyHhHk
それこそ、どういう使用環境を想定したアプリを作るかによるような。
0052名無しさん＠お腹いっぱい。04/05/05 20:59ID:KfZyHhHk
ああ、ageてしまった。申し訳ないです。
0053名無しさん＠お腹いっぱい。04/05/05 21:19ID:LJ2IXb8t
　　 ∩＿＿＿∩　　　　　　
　　 | ノ　　　　　 ヽ/⌒)　縛られなければならないのは大変だな
　 /⌒) (ﾟ)　　　(ﾟ)　|　.| 　
　/　/　 　( _●_)　 ミ/　　　∩―−、
.（　　ヽ　　|∪|　　／ 　　　／　(ﾟ)　､_ ｀ヽ
　＼　　　 ヽノ　/ 　　　 　/　　(　●　 (ﾟ) |つ
　 /　　　　　　/　　 　　　|　／(入__ノ 　 ミ　　　よれないよ。
　|　　　　　　 / 　　 　　　､　(＿／　　　 ノ　　
　|　　／＼　＼ 　　 　　　＼＿＿＿　ノﾞ ─ｰ
　|　/　　　 )　 )　　　　　　　＼ 　　　　　　＿　　　　　
　∪　　　 （　 ＼　　　　　　　　＼　　　　　＼
　　　　　　 ＼＿)
0054名無しさん＠お腹いっぱい。04/05/07 16:52ID:pPQj6LGA
少なくとも２ｃｈブラウザみたいなGUIリッチなアプリは
余裕で作れないよ＞.NET標準
0055名無しさん＠お腹いっぱい。04/05/07 23:26ID:5frJ5ltr
http://www.geocities.co.jp/SiliconValley-Sunnyvale/9453/

作れないことはない

使ったことないがな
0056名無しさん＠お腹いっぱい。04/05/08 00:22ID:ARrbq4GO
>>55
ReBarは標準に無いよ。
もめてる原因の一番のネタはReBarが無いことだと思うが、違うかな？
0057名無しさん＠お腹いっぱい。04/05/08 01:07ID:RozMG8x7
なるほど。確かにそういったGUI部品は少ないな。
Forms2.0を待つしかないか。
0058名無しさん＠お腹いっぱい。04/05/08 23:00ID:NLlTFGuz
Actionがないのも致命的だな。
メニュー・ショートカットキー・
コンテキストメニュー（右クリックで出るやつ）・ツールバーを
統一的に扱えるもの。
つか個別にリストアップしていったって意味ないよ。
欠けてるもの多すぎだし。
0059名無しさん＠お腹いっぱい。04/05/15 01:10ID:wGQbcfW+
http://www.hamar.sk/sphere/
0060名無しさん＠お腹いっぱい。04/05/18 18:26ID:XFi+EqdD
>>54
次のバージョンでかなり楽になる。
http://windowsforms.com/WhidbeyFeatures/
0061名無しさん＠お腹いっぱい。04/06/07 01:17ID:ZWOyz/4F
>>54
確かに。

だが、VISUAL BASIC6より何倍もマシだろう。
0062名無しさん＠お腹いっぱい。04/07/08 12:47ID:KTksbgQG
.NET Framework 2.0になったら結構クライアントアプリ増えるかもしれんね。
0063名無しさん＠お腹いっぱい。04/07/08 16:57ID:x7WboOrF
>>61
純粋に現時点で比較するならVB6のがよっぽどまし。
それくらい完成度は低い。
0064名無しさん＠お腹いっぱい。04/07/15 06:20ID:N2cdHitK
UTF8対応ターミナルソフト
http://www.routrek.co.jp/product/varaterm/
0065名無しさん＠お腹いっぱい。04/07/15 23:21ID:JGjsO4Qo
将来はOfficeとかも.NET Frameworkで作成されるようになる？
あとＣ＃とVB.NETはポジション的にどう違うの？
0066名無しさん＠お腹いっぱい。04/07/16 00:04ID:pUtTSSvN
>>65
Officeは当然.NETで書き換えられるだろうけど
そこらへんははっきりとMSからは聞いたこと無いな。
逆にOfficeごときを.NETに乗せられないようじゃ.NETヤバイだろうね。

C#はMS一押しの主要開発言語。
VB.NETはVB開発者を.NETに移行させるためのレガシー釣り言語。
しかしなぜかC#にはない独自の機能がボコボコ追加されつつある。
けど積極的に選ぶメリットはあまり無い。
0067名無しさん＠お腹いっぱい。04/07/18 02:11ID:pXJVMi5G
たぶん、Office12は.Netではないと思う。
0068名無しさん＠お腹いっぱい。04/07/18 09:12ID:pLUigitG
いま使っているVBAで書いたコードはいつまで使えるんだろうか
0069名無しさん＠お腹いっぱい。04/07/19 13:17ID:krnzeNa/
Officeを全て.NETで書き換えなんて出来るの？
すっごい無駄だと思うんだけど。
0070名無しさん＠お腹いっぱい。04/07/20 01:23ID:45WASw6T
>>68
かなり広まったし互換性から考えても残さざるを得ない。
0071名無しさん＠お腹いっぱい。04/07/20 02:50ID:ZZSAG22p
>>69
なんで無駄だと思うの？
0072名無しさん＠お腹いっぱい。04/07/20 08:05ID:IEZyDXxR
>>69
Officeは(EXCELなど単体の製品だったけど）過去にプラットフォームをMS-DOSから
Win32に移行しているわけで。
0073名無しさん＠お腹いっぱい。04/07/20 08:39ID:s9n1av8j
Win32と比べて、.NETはメリットが見えないのが問題なんだけど。
0074名無しさん＠お腹いっぱい。04/07/20 22:46ID:45WASw6T
>>72
MS-DOS版のOfficeなんて出なかっただろ？
Word1.0からWin16ベースだったはず。
0075名無しさん＠お腹いっぱい。04/07/21 12:40ID:uo+YYGSR
>>74
ttp://excimer.hp.infoseek.co.jp/HP-History/

DOSのエクセルは・・・・まるうちぷらん
0076名無しさん＠お腹いっぱい。04/07/21 21:35ID:NYjGRVtr
>>73
Win32APIに比べて設計がきれいなので、コーディングが楽
0077名無しさん＠お腹いっぱい。04/07/21 22:43ID:53H6yv9k
>>76
Win32用のクラスライブラリなんて、今まで山ほど蓄積されてきてるわけだが。
.NETは将来はともかく現状そのうちのひとつにしか見えない(つーか今のところホントにWin32の単なるラッパー)
くせして弊害も色々あるからこんなスレがたつわけで。
0078名無しさん＠お腹いっぱい。04/07/21 23:26ID:4Opj98wb
>Win32用のクラスライブラリなんて、今まで山ほど蓄積されてきてるわけだが。
言語ごとクラスライブラリごとにばらばらに実装してたら効率悪いだろ。
.NETFWはWin32の関数＋構造体の使い回しからクラスの使い回しへの自然な拡張で
さらにJavaのメリットも取り入れていてものすごい無難な進化だよ。
これを受け入れられない奴はよっぽど頭固いか世事に疎いかPCのスペックが低いかのどれかだな。
0079名無しさん＠お腹いっぱい。04/07/21 23:32ID:uo+YYGSR
俺は受け入れられん。低スペックだからな。
面白そうなソフトを見つけても.netだとパスしてます。

作る人じゃないからね〜
0080名無しさん＠お腹いっぱい。04/07/21 23:43ID:4Opj98wb
>>79
そんな事わざわざ宣言するまでもなく
誰がどのAPIセットで構築されたどんなアプリを使うかは完全に自由だし。
0081名無しさん＠お腹いっぱい。04/07/21 23:47ID:YliD49Sy
79みたいなやつは
賛同してもらいたいのかな？
0082名無しさん＠お腹いっぱい。04/07/21 23:48ID:53H6yv9k
>.NETFWはWin32の関数＋構造体の使い回しからクラスの使い回しへの自然な拡張で
>さらにJavaのメリットも取り入れていてものすごい無難な進化だよ。

言っちゃなんだが、その程度の事を実現するためだけに、>>1に書かれたデメリットがついてくるなら
まだ「関数＋構造体の使い回し」でいいよ…と思ってしまうのが、.NET最大の欠点じゃないかと…

ついでに、言語ごと〜と言っても、言語の方に.NETに合わせた拡張が必要なので
事実上C#とVB.NETという新しい言語用の新しいライブラリができただけ

で、今は今として、将来これがWin標準になるのかっつーと、
64ビットプロセッサが乱立してたら、プロセッサ非依存の共通バイナリは必須だったが、
IntelがAMD互換を打ち出したので、怪しくなってきた
0083名無しさん＠お腹いっぱい。04/07/22 00:21ID:OLy0ntV3
普通に水掛け論になるからもうやめとくけど
AthlonXP3000+&1GBのメモリ積んでるマシン使ってると
>>1のデメリットは特にデメリットとは感じられないし、
作る側からすれば>>80のメリットは非常に魅力的だよ。
UTF8、XMLへの対応度も上がるし。
現時点でそれらへ対応するメリットが薄いフリーウェアが
無理に.NETに乗る必要性は薄いけどね。

将来性という意味ではWin32/64の延長でこれからの
10年をやっていけるとはとても思えないよ。
0084名無しさん＠お腹いっぱい。04/07/22 00:28ID:y3ItmO1W
エェー .NET が10年も持つとでも？
0085名無しさん＠お腹いっぱい。04/07/22 09:12ID:E2+oEao7
俺も以前までJavaも.NET FrameworkもVBも重いからｲﾗﾈ派だったけど、
EclipseとかSkunkDAVみたいな他に代替するものがない高性能なアプリを
使って考えが変わったね。
重いっていってもそれは起動時だけの話だし、すぐそこにすばらしいアプリが
あるのにそういう些細なことで使わないのはもったいないと思うよ。
今日日PCのリソースは余りまくってるんだから、こういうところで活用しないと。

作る側としてもWin32に固執する人って昔に例えれば、

Cがパフォーマンスの面でちょっと劣るからといってアセンブラでコーディングする

みたいなもんだろ。まあアセンブラに慣れてるなら止めんが、周りの人間としては
効率悪いことしてるようにしか思えないわけで。
0086名無しさん＠お腹いっぱい。04/07/22 11:17ID:jqEs2LJx
>>85
他に代替するものが無いならそれを使うのは素晴らしくも当たり前じゃないか？
EclipseなんかJava開発環境としては代替はいっぱいあるが、PureなSwing製(JBuilderとか)よりも
軽快なEclipseを好んでるんでしょ？

それと…この手のたとえ話にはつきものだけれども、
Cとアセンブラの差と、既存言語と.NETの差が、同じぐらいだとでも？
0087名無しさん＠お腹いっぱい。04/07/24 14:51ID:TFEpMbKe
2.0を待つべし
0088名無しさん＠お腹いっぱい。04/07/30 11:45ID:YIw9eBQC
起動しちまえば、.NETがレガシーより高速になることはありえるよ。
仮想マシンJAVAとの大きな違いだね。
0089名無しさん＠お腹いっぱい。04/07/30 20:44ID:nXCBh7rA
>>88
JAVAにもJITで書かれているものがあるのを知らない香具師。
0090名無しさん＠お腹いっぱい。04/07/30 22:17ID:CXFSyWO4
次期Office Systemが.NETで置き換えられるってどっかに書いてた気がする
0091名無しさん＠お腹いっぱい。04/07/30 23:02ID:qR8IZ5dq
>>89
JITで書くってどういう意味？
0092名無しさん＠お腹いっぱい。04/07/31 01:01ID:ASIAqaTs
>>88
The Java Faster than C++ Benchmark
http://www.kano.net/javabench/
0093名無しさん＠お腹いっぱい。04/08/01 12:27ID:xTHd0GTo
.NET Framework依存のアプリをインストールするとき、同バージョンでも
.NET Framework自体そのインストールCD-ROMから丸ごと送り込まれてる気が
するのですが、アプリの新旧によってはまずい事が起こるような気がします。
（こういう「構成部品」の細かいバージョン違いによる不具合って、結局OSの
　名称が変わるほどの変化にともなう「総入れ替え」によってでしか解消され
　ないような・・・）
0094名無しさん＠お腹いっぱい。04/08/10 17:36ID:CQTvWdX4
age
0095名無しさん＠お腹いっぱい。04/08/30 11:27ID:mTzqwmKR
V2i Protectorをインスコ使用としたら、.Net Framework入れろっつーんで入れたら
Opteron250で起動に3分かかるよう

実クロック高いIntel系の方が有利なのかよう
0096名無しさん＠お腹いっぱい。04/08/31 14:47ID:DACe3i7C
1.1SP1が出たようで、ってなんで今さら。2.0が出るというのに。
内容的にはセキュリティのfixみたいだけど
0097名無しさん＠お腹いっぱい。04/08/31 17:05ID:izxkHMp9
>>96
2.0って、まだまだ先じゃないの？
0098名無しさん＠お腹いっぱい。04/08/31 21:39ID:L7wohyeE
>>96
.NETからの更新では反応しないね。なんだろこれ
0099名無しさん＠お腹いっぱい。04/09/01 17:40ID:ir6uEiCm
>>96
side-by-side があるから、
古いバージョンも保守する必要があるのでは。

アセンブリとバージョン管理
ttp://www.atmarkit.co.jp/fdotnet/technology/idnfw11_04/idnfw11_04_01.html
0100名無しさん＠お腹いっぱい。04/09/05 09:05ID:C2sL8Mqo
100(σ・∀・)σ ｹﾞｯﾂ !!
0101名無しさん＠お腹いっぱい。04/11/04 16:26:12ID:UTbAAoeh
メモリ喰いすぎ
起動遅すぎ
■ このスレッドは過去ログ倉庫に格納されています