C#, C♯, C＃相談室 Part59

1 名前：デフォルトの名無しさん [2010/05/16(日) 23:13:52 ] (#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。 前スレ  C#, C♯, C＃相談室 Part58 pc12.2ch.net/test/read.cgi/tech/1269261310/ Visual C# 2008 Express Edition 日本語版 www.microsoft.com/japan/msdn/vstudio/express/vcsharp/ その他テンプレ>>1-5くらい 610 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 22:00:41 ] 特定のスレッドを特定のCPUコアで動かすのってどうやるんだっけ？ 611 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 22:07:31 ] そんなこと考えてる前にlockしちゃうなぁ。 var obj = new Object(); としといて lock (obj) { s_x = 1; s_ya = s_y; } と lock (obj) { s_y = 1; s_xa = s_x; } で、俺的には万事解決。 色々深遠な問題もあるだろうけど、そんなこと知ったこっちゃねー♪ 612 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 22:18:21 ] まあそもそもこんな処理は普通は出てこないからなー。 これはあくまで予想と異なる結果になることがあるのを示しているだけで。 ただ、こういうコードを、無意識のうちに、動作を無意識に期待して書いてしまう可能性はあるかもしれない。 まあ普通はマルチスレッドで何かを書く場合は常に同期のタイミングは考慮しながら書くから、 多分めったなことはないとは思うけどね。 613 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 22:24:25 ] でもいるんだよ。 既存の処理をなんにも考えずにマルチスレッドにしちゃうのが・・・ 614 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 22:52:56 ] >>604 参照順は変更されるんじゃないの？ volatile読み込みは他の読み込みよりも早く行われるんでしょ？ 615 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 22:56:00 ] >>614 まあね。orz 616 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:00:46 ] >>614 変更されないよ。 ＞volatile読み込みは他の読み込みよりも早く行われるんでしょ？ そうじゃない。 volatile読み取りよりも後ろにある読み取りが、 volatile読み取りよりも前に移動されるような最適化は行われない ってこと。 617 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:07:25 ] >>616 あぁー、そう読むのかぁ。 もっと精進します。 618 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:10:04 ] そもそもvolatileの順序保障をどういう風に使うかというと、 例えば int data1; int data2; volatile bool completed; みたいな変数定義を行って、 スレッドAで、 data1 = 1 data2 = 2 completed = true; みたいなことをして、 スレッドBで、 if (completed) { //data1とdata2を読み取り } みたいにしたとき、data1とdata2の読み取りで、 確実にスレッドAで更新された結果にアクセスできる。 これは、 volatile書き込みより前の書き込みは必ずvolatile書き込みより前に行われ、 volatile読み取りより後の読み取りは、必ずvolatile読み取りより後に行われることが保証されてるから。 619 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:12:58 ] もしこの保証がないと、スレッドBでの読み取りで、 data1とdata2が、スレッドAが書き込んだ結果であることを保証できない。 620 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:14:24 ] >>618 > volatile書き込みより前の書き込みは必ずvolatile書き込みより前に行われ、 > volatile読み取りより後の読み取りは、必ずvolatile読み取りより後に行われる リンク先にも確かにかいてあるけれど、これに当てはまらないものはすべて保障されていないと考えるべきなのかな。 volatile書き込みより後ろの書き込みが、volatile書き込みより前に行われる可能性とかそういうの。 621 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:24:01 ] C#の言語仕様では保証されてないはず。 ECMAのCLIのメモリモデルでも、 ・読み取りと書き込みは、volatile の読み取り前に移動することができない。 ・読み取りと書き込みは、volatile の書き込み後に移動することができない。 というルールしかないので保証されない。 ただし、CLR2.0のメモリモデルではもう少し保証が強い。 詳しくは ttp://www.microsoft.com/japan/msdn/msdnmag/issues/05/10/MemoryModels/default.aspx#S3 なんだけど、分かりにくいなｗ 少なくとも書き込み順序は変更されないはず。 なぜなら、CLR2.0では実質書き込みは全て「解放形式」になっているらしいので。 622 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:26:36 ] おっと、そこのリンクの ４．書き込みは、同一スレッドからの別の書き込みを超えて移動することができない。 があるので、書き込み順序はたとえvolatileでなくとも、変更されることはないな。 623 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:42:25 ] 順序がどうとか、なんでそういう話になるのか意味がわからんよ。 volatileの意味は文字通りその変数を非同期的に変更されうるものとして 扱うという意味以上でも以下でもないはずだと思うんだけど.... 624 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:48:23 ] >>623 俺もそれだけの意味だと思っていたんだけど、C#では違うということを恥ずかしながら今日知りました。 625 名前：デフォルトの名無しさん mailto:sage [2010/06/17(木) 23:52:24 ] なんだよ、結局またわかってないヤツが暴れてただけかよｗ 626 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 00:02:39 ] 俺は暴れてはいないつもりなので、他にも分かってない人がいたのでしょう。 627 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 00:04:30 ] >>626 お前だろ 628 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 00:08:54 ] 俺のようなヘボプログラマにとっての結論は、 マルチスレッドではvolatileに頼るなということだな。 629 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 00:08:57 ] そんな、高速だけど分かってる奴でもとっちらかって間違いかねない仕掛けで書くより、 遅くても排他処理でガチガチ泥臭く書いたほうがメンテナンスとか考えると現実的じゃね？ 忘れた頃に見直す度に一々頭の中で再検証すんのかよ、って話。 630 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 00:10:43 ] だね。メモリバリアメソッドも用がなさそうだし、当面lockステートメントでいいやって思った。 ちゃんと理解できたら正しく速く動作するライブラリを書きたいものです。 631 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 00:13:12 ] >>627 なんだ、暴れたのがいまさら恥ずかしくなったか？ 632 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 01:05:25 ] >>623 こいつがどこまでもバカなだけ。 633 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 01:07:47 ] >>630 基本的には正しい判断だと思うよ。 lockだって別にそんなに重いわけじゃない（状況によるが）。 634 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 01:09:53 ] >>623 言語仕様からMSDNマガジンの詳細な記事から 何から何まで何度も示されてるのに意味が分からないなら お前は本当に頭が悪いんだろう。 635 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 01:57:39 ] >>553のって s_x = 1; s_ya = s_y; の部分について、s_yの読み取りが先に行われて、 s_xの書き込み、s_yaの書き込みが行われたってことになるの？ 636 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 05:13:58 ] どうなの？ 637 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 06:28:32 ] >>629 鉄板でしょう。 638 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 08:58:25 ] C#の言語仕様のダウンロードURI教えてください。 639 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 09:10:49 ] VS2010のフォルダ内にありましたorz 640 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 09:58:10 ] object[] a = string[]{"a"}; string[] b = a as string[]; この処理は純粋にaへの代入とbへのキャストが行われているだけで、 List<object>とList<string>を型変換するときのようなインスタンス の新規作成はされないと考えてよいのでしょうか？ 641 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 13:53:30 ] ちょっとした疑問 class A { object lockobj = new object; string _a; public a { get { lock(lockobj){ return _a; } } set { lock(lockobj){ _a = value; } } } これって、ちゃんとロック掛かるんだろうか？ 642 名前：デフォルトの名無しさん [2010/06/18(金) 13:54:34 ] て 643 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 13:56:56 ] >>641 はい 644 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 15:16:12 ] >>641 いいえ、コンパイルすらできません 645 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 15:25:20 ] >>635ってどうなの？ なんで頭いい人たちみんなスルーなの 646 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 15:31:28 ] OoOについてggrks 647 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 16:28:23 ] >>644 型がないからってか？ 質問の意図はそうじゃないだろ・・・ 648 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 17:16:46 ] >>641 質問のポイントはLockのスコープからのreturnだろ？ ロックはreturnステートメントの実行直後にはずれるから普通に使える。 649 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 18:46:23 ] >>635 >>553の件少し判った気がする。 環境依存があるようだからここにいる人たちも確認してもらえると助かる。 Releaseモードでも確認できるように修正。コンソールに出力させるようにする。 ＞Debug.Assert(s_xa == 1 || s_ya == 1); if (!(s_xa == 1 || s_ya == 1)) Console.WriteLine("* {0}, {1}", s_xa, s_ya);  こちらの環境で確認できたこと。 マルチCPU、マルチコア、ハイパースレッディングでも起きる。 シングルCPU環境では起きない。 Relaseビルド、Debugビルドはどちらでも良い。 Debug実行時に起きる。Debugなしで実行では起きない。 結論 予想が当たってればOoOとか高尚な問題でなく、IDEのデバッガのバグの可能性がある。 650 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 19:06:46 ] >>646 すっこんでろ 651 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 20:41:20 ] >>649 俺の環境では、デバッグなし実行でも起こってる。 652 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 20:43:41 ] >>641 ちゃんとロックかかるってのはどういう意味で言ってる？ ロック自体はもちろん期待通り普通にかかるが、 objA.A = objA.A + "hoge"; なんてのをアトミックに実行することは当然ながらできない。 653 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 20:44:30 ] 改行入った… objA.A = objA.A + "hoge"; な。 654 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:15:29 ] >>618 なんか違わないか？ その例だと、スレッドBでdata1,data2が「正しく」読める保証は何もないのでは？ でなきゃ、そもそもvolatileって何だって話になる。 655 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:26:12 ] >>654 ＞でなきゃ、そもそもvolatileって何だって話になる。 どういう意味？？ 何言ってるのかわからない。 そりゃまあ>>618には実際にはいろいろ前提があるのは確かだが、 文脈で言いたい事柄の意図は通じると思うが。 656 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:29:24 ] >>654の指摘が何を言おうとしてるのかわからないので、そうだな、 ＞その例だと、スレッドBでdata1,data2が「正しく」読める保証は何もないのでは？ なぜ保証がないのかを具体的に書けばそちらの意図はわかるかもしれん。 657 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:33:09 ] 無意味な実装検証してもしょうがないような 658 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:35:39 ] >>656 そもそもその保証がない（コンパイラの最適化によって変数そのものには アクセスしない可能性がある）から、そういう可能性を排除するためのvolatileの はずなんだけど.... どうもこのスレ、分かってるのか分かってないのかよく分からん人が多いよな 659 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:38:32 ] volatileの使い方？を勘違いしてる 660 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:42:04 ] ひょっとして>>590の後半に書いてるような、よくある誤解をしてるクチかな？ 661 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:43:49 ] よくある誤解、ねえ.... 662 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:44:48 ] >>658 それがよくある誤解。そんなことは起こらない。 何度も何度も何度も出してるけど ttp://www.microsoft.com/japan/msdn/msdnmag/issues/05/10/MemoryModels/default.aspx でも読んでみ。 ※今はC#のvolatileの話だぜ 663 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:49:59 ] volatileの意味を誤読してるとか 664 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:51:18 ] >>658 メモリモデルの意味を全く理解してないな。 だったら、例えばもしlockで排他制御してた場合に、 他スレッドで更新した変数をlock内できちんと読めるのはなぜか考えてみな。 最適化で削除されるならそれすら保証されなくなる。 lock内では削除したらダメってコンパイラにはわかってるだろとか考えなしなこと言うなよ。 lock内から呼び出される普通のメソッドだってあるんだからな。 コンパイル時にそこがlock内かどうかなんて判断は無意味なこと。 665 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:53:01 ] >>662 だからvolatileの話じゃないし。 その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」 とは書いてないように思うが。 666 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:58:40 ] メモリモデルのルールをよく読め。 ------ 読み取りが、同一スレッドから同一ロケーションに対する別の読み取りに隣接している場合、その読み取りは削除のみ可能。 書き込みが、同一スレッドから同一ロケーションに対する別の書き込みに隣接している場合、その書き込みは削除のみ可能。 規則 5 により、複数の読み取りまたは書き込みを隣接させてから、本規則を適用することが可能です。 ------ 667 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 22:01:01 ] ＞その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」 ＞とは書いてないように思うが。 あのな、volatile読み取りより後の読み取りは必ずvolatile読み取りより後で実行されるってのは、 CPUのキャッシュ制御を含んだ話だよ。 >>618 ではvolatile読み取りの後に変数にアクセスしてるだろうが。 だから必ずキャッシュではなく（別スレッドで更新された）最新の値が読み取られる。 っていうかそのためのvolatileだって話。 668 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 22:02:41 ] どれとも ＞その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」 ＞とは書いてないように思うが。 これはCPUキャッシュじゃなくて、レジスタにキャッシュするとか、そういう意味で書いてるのか？ それなら、それこそ>>666の話だ。 隣接する同一ロケーションからの読み取り以外で、読み取りが最適化によって削除されることはない。 669 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 22:10:40 ] >>666 「ケースAの場合、readのみが削除可能」という文章は、 「readが削除されるのはケースAの場合のみである」という意味ではない。 大丈夫？ >>667 どう読んでも君が思ってるような意味には解釈できないと思うが... 「処理Aと処理Bはシーケンシャルに実行されます」の意味は、 処理Aに続いて行われる処理Bに対して最適化が行われない、などということを意味しない。 670 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 23:40:03 ] ふえ？ 671 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:00:00 ] ＞「ケースAの場合、readのみが削除可能」という文章は、 ＞「readが削除されるのはケースAの場合のみである」という意味ではない。 ＞大丈夫？ あほくさいこと言う前にそのページ全体をよく読んでみろよ。 メモリモデルをどのように定義してるか書いてあるから。 「メモリ モデルは、順次一貫性モデル (最も制限的かつ厳密なモデル) をベースとし、」ってとこらへんな。 だいたいそんなこと言ったら書いてないことだらけなんだから、そういう読み方じゃおかしいことくらいわかろうに。 ＞「処理Aと処理Bはシーケンシャルに実行されます」の意味は、 ＞処理Aに続いて行われる処理Bに対して最適化が行われない、などということを意味しない。 どこの記述のことを言ってるのかわからんがな、処理Bの最適かって具体的に何のことを言ってる？ 読み取りの最適化なら、前に読んだ値をキャッシュしておくくらいしかないだろ。 メモリモデルでは、そういうのを読み取りを前に移動するという風に定義してるんだよ、上のページにちゃんと書いてある。 そして読み取りはvolatile読み取りより前に移動できない、 つまり、volatile読み取りより前に読み取りをキャッシュしておくという最適化は許されない。 全部書いてある。 672 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:04:49 ] もういちいち説明するのめんどくさい、勝手に自分流解釈しとけ。 メモリモデルのこととかある程度わかってる人間ならすぐに理解できる話だ。 volatile絡みのルールの話も、マルチスレッドでのメモリモデルの一般的な話を理解してるなら はっきり言って常識レベルの話（ごくごく一般的なルール、javaのメモリモデルも同じようなルール）。 一回マルチスレッドのメモリモデルや順序について詳しく調べてみ。 673 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:17:33 ] >>658 お前が分かってないことははっきりしてる。 674 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:27:55 ] >>658 ＞そもそもその保証がない（コンパイラの最適化によって変数そのものには ＞アクセスしない可能性がある）から、そういう可能性を排除するためのvolatileの ＞はずなんだけど.... ttp://msdn.microsoft.com/ja-jp/library/aa691105.aspx Cとかの感覚で言ってるのかもしれないが、今どきのマルチスレッドを前提とした havaやC#のような言語では、そう簡単にアクセスそのものが消されることはないよ。 マルチスレッドで正常な動作を保証するために（保証するようなコーディングができるようにするために）、 メモリモデルというものを定義して、そのルール内で最適化を行うようになってる。 だからlockやvolatileなどをルールに従って使用して、正常に動作することが保証できるコーディングを行える。 675 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:36:38 ] Wordドキュメントになってるc#言語仕様の、10.5.3 Volatile フィールドの説明でも、 >>618のような動作を正常に行えるようにvolatileを使う例が書いてあるな。 まあ日本語がおかしくて意味不明な感じに読めてしまうけどな。 言ってることはまさに>>618と同じ。 676 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:38:40 ] using System; using System.Threading; class Test { public static int result; public static volatile bool finished; static void Thread2() { result = 143; finished = true; } static void Main() { finished = false; // Run Thread2() in a new thread new Thread(new ThreadStart(Thread2)).Start(); // Wait for Thread2 to signal that it has a result by setting // finished to true. for (;;) { if (finished) { Console.WriteLine("result = {0}", result); return; } } } } この例では、次のように出力されます。 result = 143 この例では、Main メソッドが Thread2 メソッドを実行する新しいスレッドを開始します。このメソッドは、値を result という非 volatile フィールドに格納し、 次に volatile フィールド finished に true を格納します。メイン スレッドは、フィールド finished が true に設定された時点で、フィールド result を読み込みます。 finished は volatile として宣言されているため、メイン スレッドはフィールド result から値 143 を読み込む必要があります。 フィールド finished が volatile として宣言されていない場合は、finished への格納後に result への格納がメイン スレッドから参照可能になります。 その結果、メイン スレッドがフィールド result から読み込む値は 0 になります。finished を volatile フィールドとして宣言すると、このような矛盾を回避できます。 677 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:46:04 ] あっそ 678 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 13:25:41 ] >>658 かたくなにそう信じてるやつがいるんだな… 元々意味のない参照ならそうなる場合はあるが、 普通ほとんどの場合は違うのに。 679 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 13:38:21 ] >>669 ｷﾘｯ ついていけないならくだらんケチつけなきゃいいのに 680 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 16:08:49 ] また同じヤツが暴れてるのかｗ お前はもうマルチスレッドとか無理だからあきらめろｗ 681 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 18:18:54 ] クラスアセンブリ(dll)を許可するプロジェクトだけに読み込ませるにはどうすればいいのん？ 682 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 18:31:32 ] >>681 コールしているアセンブリの署名を調べる。 683 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 18:41:02 ] >>682 ｋｗｓｋ！ ちなみにクラスアセンブリは自前のソース月の物でありまする＞＜ 684 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:09:18 ] 署名は改ざん検知出来るだけ DLLのアクセス制限云々の機能ではない 685 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:29:04 ] やっぱりそうなんですね がっくし・・・・ ProjectA ---{OK}--- A.dll 第三者のProject ---{NG}--- A.dll みたいな事をやりたい時はみんなどうしてるのん？ 686 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:32:12 ] そんなことをやりたいと思ったことがない。 687 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:35:14 ] えー社内ライブラリとかどう管理してるのー？ 不正リンクされて盗まれても「でへへっ！」とか言うだけ？ うそーん＞＜ 688 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:38:50 ] >>685 ＤＬＬのファイルかフォルダにNTFSのアクセス権つければよくね？ 689 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:47:26 ] 制限出来れば リフレクション使ってクラス調査→不正リンク→(ﾟ∀ﾟ )ｱﾋｬﾋｬ という.net固有の糞みたいな問題が解決するけど 未だに対策は難読化しかない。 690 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:53:51 ] 別になぁ。そもそもアセンブリじゃないDLLなら呼び放題だし。 売り物ならライセンス処理つけるだろうし。 お買い上げありがとうございました。だろ？ 691 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:55:50 ] オープンソース時代だから別にいいじゃんｗ 盗まれたら裁判すればいいし(ｷﾘｯ 692 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:58:48 ] >>691 盗んだほうはC++で書きましたってオチだ 693 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:08:44 ] .NETでなくても、製品の実行ファイルや図版を勝手に使われたらどうするんだよ。 そういうときは法務部門や顧問弁護士の出番。 694 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:18:14 ] まっ、やり放題な業種だからどうしようもないってこった 裁判なんざ普通は起こせないしそもそも把握すること事態が不可能 695 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:47:43 ] ヤリ放題な業種だと自分に言い聞かせてるのか？こっちまで巻き込むなよ。 696 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:50:51 ] 巻き込むも何も対策方法が何もない現状 自作パッカー作ったところで焼け石に水 理想は寝て言え 697 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:50:51 ] >>683 どのアセンブリからコールされているかはわかるだろ。 そして、そのアセンブリがどのような署名されているかを調べる。 逆コンパイル防止はそれ以前の問題。 698 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:05:35 ] 毎回、毎回、クラス毎に調べるのか？ 手間かかりすぎだろ 699 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:07:48 ] いたるところで StrongNameIdentityPermission でDemandでもしとけ。 まあ改ざんされたらもうだめだけどな。 700 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:45:18 ] 単純に public class MyLicence : License { public override void Dispose() {} public override string LicenseKey { get { return ""; } } } public class MyLicenceProvider : LicenseProvider { public override License GetLicense(LicenseContext context, Type type, object instance, bool allowExceptions) { if (allowExceptions) { string exename = Path.GetFileName(Assembly.GetEntryAssembly().Location); if (! exename.Equals("MyLicenceTest.exe")) { throw new LicenseException(type, instance, "do't licenced"); } } return new MyLicence(); } } [LicenseProvider(typeof(MyLicenceProvider))] public class TestClass { License license; public TestClass() { license = LicenseManager.Validate(typeof(TestClass), this); } } とかでもいいんじゃね？呼び出し元exe名縛り。 701 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:54:35 ] こんな抽象クラスあったのか。 中々面白いアプローチだと思う。 702 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:59:05 ] ほぉ、これはなかなか… 703 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:05:48 ] >>701-702 そりゃどうも。えっへん！ 704 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:06:08 ] Licenseは破棄が必要だぜ… 705 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:07:59 ] と思ったけど必要なければ別に実害はないのか… 706 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:10:53 ] リソース持ってないし、いいかな？と省略したけど、実装する際は通常通り Dispose()しといたほうがいいだろね。 707 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:14:16 ] リソースというか取得したライセンスを開放する処理を好きに定義するだけでしょ 同時利用数をデクリメントするとか 空でも全く問題ない 708 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:20:59 ] ってことみたいね。 709 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:48:04 ] というか、キモはexeのファイル名を確認するところなんだから、実装の仕方は人それぞれでしょう。 710 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 23:10:48 ] ってことみたいね。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef