ふらっと C#,C♯,C＃（初心者用） Part143

2019/05/16(木) 19:28:06.27

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■関連スレ
C#, C♯, C＃相談室 Part93
http://mevius.5ch.net/test/read.cgi/tech/1492818720/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part142
https://mevius.5ch.net/test/read.cgi/tech/1551908141/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
-
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2019/06/11(火) 02:19:21.88

お前みたいな馬鹿が尻の穴嘗めてくれるからウハウハだぞバカ

2019/06/11(火) 02:28:30.43

多分、日本はwindowsで作った資産があるけど
そうでない国はお金がないからわざわざWindowsを使わない
そんな状態が続いたもんだからlinuxの資産が貯まってしまって
お金を持っても今度はWindowsには移行できない
そんな事情のある最近のlinuxに寄り添ってる理由だろ
昔はその作りやすさから王者だったけど
最近そーでもねーのが致命的になってんじゃねーのか？と

2019/06/11(火) 02:33:30.92

クソ長文書いてねえで寝ろクズ

2019/06/11(火) 03:14:41.06

HTML のボタンには、disabled 属性もある

2019/06/11(火) 07:09:30.30

もうwebオンリーで行くかなと思ったけどバーコード使いたいと言われるとFormeアプリ使わんとダメだよね
XAMLは流行る予感がしないから触る事ないな

2019/06/11(火) 08:52:13.44

Webでバーコード扱えるけど

**デフォルトの名無しさん** (ｽﾌｯ Sdd7-aKta) · 2019/06/11(火) 10:34:45.11

Shape Detection APIな。
PCのChromeでも動けば動作検証楽なのになぁ、あれ。

2019/06/11(火) 14:05:54.20

リーダーをUSBに差せばWebでも使えるやで

2019/06/11(火) 14:08:24.54

ふぅーDataGridViewのボタンの非活性できた。

MSはその程度実装しておけよ

2019/06/11(火) 14:27:25.63

CheckBox も同様だけど、Visible と Enable くらいは実装しとけよ、って思うよなぁ
WinForms に対しては全くやる気ないみたいだけど

2019/06/11(火) 14:41:17.27

>>414
実装もそこまで時間かかるとは思えないんだよな
なんか詰めが甘いというか・・・

しかもVS２０１７になっても未実装って

2019/06/11(火) 15:25:57.49

x64 のときは Form_Load の中での例外はスルーするバグも絶賛放置
（x86 だったら、ちゃんと例外を捕捉する）

2019/06/11(火) 15:57:17.26

Windows Formなんてとっくに見捨てられてるからね。メンテナンスフェーズかも知れん。WPFですら10年前だし。ということでUPF使え。
…ってMSは思ってるかもだが、Formなにかと楽なんだよなあ

2019/06/11(火) 16:23:20.80

俺がゲイツなら首にするわ

2019/06/11(火) 18:42:14.00

.NET Core3.0リリース後にちゃちゃっとPR書けば？そんなに簡単なら

2019/06/11(火) 20:32:19.05

悪いけど、FullFx版のWinFormsとの互換性を損なうようなコミットは全部リジェクトだと思うよ
forkして弄るのは勝手だけど

2019/06/11(火) 20:58:05.88

>>420
.NET Core3.0後にどうなるかはまだ不透明
現状はそうだけどね

2019/06/11(火) 21:10:59.72

どのみちMS自身が今後WinFormsに機能追加をすることはありえないんだから、縛りのきつい公式リポジトリに拘る意味がないでしょ
WinFormsをクロスプラットフォーム化するコミュニティプロジェクトは必ず立ち上がるから、それに参加したらいい

2019/06/11(火) 21:15:40.32

>>422
WinFormsのクソな部分がそのまま移植されるとは思わないから別物になると思う

汎用的な部分だけ移植なら整合性が合わなくなるからそもそも新しいの作るだろ

2019/06/11(火) 21:40:49.66

>>423
残念ながらベタ移植だよ
ほとんどのソースはオリジナルからコピーしてきてヘッダコメントを変えただけ
WinFormsをCoreでビルドできるように手直ししただけの代物だ
WPFなんかC++/CLIにべったり依存してるからもっと酷くて、
WPFをビルドするためだけにVCのコンパイラに限定的なCoreサポートを追加して無理矢理ビルドしてる
そんな不毛なことするくらいならネイティブ部分を書き直せと批判されてしばしばissueが炎上してるが、MSはガン無視

2019/06/12(水) 09:44:54.85

DataGridView_hoge.AllowUserToResizeColumns = false;

列幅変更出来ない様にしたつもりですが、普通にドラッグしてサイズ変更出来てしまいます。
何が原因でしょうか？？？

2019/06/12(水) 10:24:07.46

行ヘッダ列はAllowUserToResizeColumnsじゃなくてRowHeadersWidthSizeModeで設定しないといけないけど
それ以外の列ってことなら何か変なことやってるんじゃないのとしか言えないなぁ

2019/06/12(水) 10:29:24.57

>>426
RowHeadersWidthSizeMode
ためしてみます。

2019/06/12(水) 21:10:32.82

なんかWindowsアップデートで動かなくなったりするから
Windowsやめようぜって方向になってるぞ

2019/06/12(水) 21:27:03.90

どうぞ

2019/06/12(水) 23:03:21.43

どうぞどうぞ

**デフォルトの名無しさん** (ｽﾌｯ Sdd7-tCrF) · 2019/06/12(水) 23:30:47.47

バイバーイ(^.^)/~~~

2019/06/13(木) 12:45:58.94

WPFの将来性ってどうですか？
今から勉強する価値ありますかね

2019/06/13(木) 15:02:14.86

>>432
将来性はない
勉強する価値もない

2019/06/13(木) 17:22:47.41

たぶん現状のまま放置されるって意味では将来性ないけど
Silverlightみたいに事実上使えなくなることは恐らくないから
勉強して無駄になることもないと思うよ

そいうや、何年か前にWin32を廃止する計画を読んだ記憶があるけど
例によって軌道に乗ってるように思えんねw

2019/06/13(木) 18:14:02.25

>>434
win32廃止したら、Windowsじゃ無くなるじゃん

**デフォルトの名無しさん** (ｽﾌｯ Sdba-UiF5) · 2019/06/13(木) 22:23:06.18

>>435
win64 APIのみにするってことでしょ

2019/06/13(木) 22:27:30.58

ARM使い「そうか」

2019/06/14(金) 09:46:05.42

>>436
Windowsから互換性取ったらMacとの優位性が崩れてしまうわ。

2019/06/14(金) 10:19:55.42

う互換性

2019/06/14(金) 13:28:36.75

GDIとかいつまで残ってんだろ

2019/06/14(金) 13:36:31.53

APIとしてはWindowsがある限り残るだろ
内部的に別の仕組みの描画フレームワークに渡すだけになる将来はあるかもしれんが

2019/06/14(金) 19:05:00.84

独自OSはやめてLinux M$ディストリになったら最高なんだけどね

2019/06/15(土) 00:33:09.29

while(i<=1000000)
{
i++;
}

こういうお手製のループって結局invokeと同じ機能なんですかね？
待つという意味では

2019/06/15(土) 02:59:58.42

質問です。
JSONシリアライズなんですけど
{ "foo": "bar" }
としたいのに、DataContractJsonSerializerに
Dictionaryをシリアライズさせると
{ "key": "foo", "value":"bar" }
となってしまいます。
何かいい方法ないですか？
どういうキーワードでググればいいかも分からなくて。

2019/06/15(土) 06:29:12.34

>>443
何のinvokeの話なのか知らないけど
ほとんどのInvokeメソッドとは全く違うんじゃないかな

>444
DataContractJsonSerializerSettings.UseSimpleDictionaryFormat

2019/06/15(土) 07:12:02.05

ConcurrentDictionary<Guid, ConcurrentDictionary<int, string>>
のようなデータ構造で、Value部の付け外しにlock機構って必要ですか？？

var cd = new ConcurrentDictionary<Guid, ConcurrentDictionary<int, string>>();

lock(_lockObj)
{
　if(!cd.TryGetValue ・・・)
　{
　　var child = ConcurrentDictionary<int, string>();
　　cd.TryAdd(Guid.NewGuid(), child);
　}
}

2つのスレッドがほぼ同時にアクセスしたとき、
最初に追加したValue部（ConcurrentDictionary<int, string>）を潰したくないです。

lock使うなら、普通にDictionaryでいいんですかね・・ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)

2019/06/15(土) 07:35:12.58

getとaddが不可分操作じゃないから要る

2019/06/15(土) 09:17:07.61

>>446
TryAddがfalseを返したら処理を最初からやり直せばいい
それならロックは不要
楽観的排他制御ってやつだ

2019/06/15(土) 14:37:59.48

HttpClientもWebClientもHttpWebRequestもまともじゃないのは一体なんなんだ

2019/06/15(土) 14:47:05.46

>>449
具体的には？

2019/06/15(土) 14:49:08.14

>>449
HttpClientはstaticなインスタンスでセッション使い回し。
このくらいの注意点は知ってるけどどう駄目なのか参考に教えてよ

2019/06/15(土) 15:37:24.10

>>449
KWSK

2019/06/15(土) 15:42:35.91

>>445
ありがとうございます！

2019/06/15(土) 18:51:55.25

>>449
これを使っている限りバグが出る可能性が排除できない
まともな設計で作り直してほしい

2019/06/15(土) 19:28:03.88

>>454
具体的には？

2019/06/15(土) 19:39:46.98

具体的なことは言えないレベルでなんとなく否定してるに1票

2019/06/15(土) 20:17:44.79

まあHttpClientFactory使えってなるよね、最近は

2019/06/15(土) 20:49:10.87

HttpWebRequestやWebClientは確実にゴミ

例えば非同期でいろんなサイトからダウンロードするアプリを作ろうとしても
実インスタンスが一つなので各サイトに合わせて設定できない

HttpClientはまともにusingできない使いまわし前提で管理が面倒でバグりやすい

2019/06/15(土) 21:25:13.03

>>458
>>457

2019/06/15(土) 21:28:36.81

いや知ってりゃ使えるだろってのはわかるんだが
なんでどれもこれも罠が満載なの？　っていう話ね

2019/06/15(土) 23:31:09.76

>>457
なにこれ？ナウなやつ？？

2019/06/15(土) 23:31:12.45

MacのCore2.1でデリゲートのシリアライズを試してるんだけどさあ、これって動くプラットフォームもあるってことなの？
class Program
{
static void Main(string[] args)
{
Func<int, int> A = i => i + 1;
BinaryFormatter formatter = new BinaryFormatter();
var tempStream = new MemoryStream();
formatter.Serialize(tempStream, A);
//System.Runtime.Serialization.SerializationException がスローされました
//"Serializing delegates is not supported on this platform."
}
}
レファレンスだとMacで動かないとか特に書いてはいなさそうだけど、どこを見たらそういう情報ってわかるんだぜ？
https://docs.microsoft.com/ja-jp/dotnet/api/system.runtime.serialization.formatters.binary.binaryformatter.serialize?view=netframework-4.8

2019/06/15(土) 23:37:24.81

>>462
ないでしょ
だってそれ、変数を一切キャプチャしないラムダ式以外では問題が起こるんじゃない？

2019/06/15(土) 23:54:10.26

デリゲートをシリアライズするっていう発想がそもそもなかったわ

2019/06/16(日) 00:04:36.79

ダメか、ありがとう

2019/06/16(日) 00:06:06.77

デリゲートのシリアライズはFullFWなら可能
.NET Remotingで通信先からRPCするために使う機能だ
.NET Coreでは.NET Remotingが廃止されたから、.NET Coreで使えないのは当然
そもそもBinaryFormatterはそれ自体が廃止された.NET Remotingの一部であり、互換性のためだけに残されてる遺物
今更新規に使っちゃダメ

2019/06/16(日) 00:12:52.39

>>461
うん、HttpClientのイケてないとこをラップして使いやすく（間違いを犯しにくいように）したやつ

2019/06/16(日) 00:22:01.61

>>466
正直、これが出来るとリモートプロシージャコールの受け側がif/switch羅列になるのを避けられると思っていました
しかし、これはもろに時代に逆行していたんですね・・・・
廃れたと言うことは今流のやり方もあるんですか？

2019/06/16(日) 00:27:11.51

.NET CoreでRPCしたいならRESTかgRPC使えとMS様は仰ってるね

2019/06/16(日) 01:01:25.28

gRPCを使用する場合でも、サーバからグローバルIPを持たないクライアントのメソッドを呼びたい場合にデリゲートシリアライズ化は有用なように思えてしまいます
接続を切らずにStreamで独自形式の命令を送り続けることになり、クライアント側では送られてきた命令を解析するためのswitch/if文だらけのコードになってしまうからです
でもif文羅列で正しいのかな・・・・どうなんだろう・・・・

2019/06/16(日) 01:18:24.92

プログラミング未経験からC#を勉強して1週間程の者です
疑問に思うことがふたつあるのでよかったら教えてください
ひとつめは配列の宣言について、宣言は省略せずにきちんとしたほうがいいのでしょうか？
また宣言する場合に
string[] array = new string[3];
と変数名を最初にstringで指定しているはずなのに、配列の数をstringで再び書くのはなぜでしょうか？

ふたつめは、
Console.Write("a は {0}, b は {1}", a, b);
と書くのは
Console.Write("a は " + a + ", bは " + b);
と書くより見やすいためでしょうか？

2019/06/16(日) 01:25:53.37

>>471
ひとつめ：varが使える場所ならvarを使った方がいい
ふたつめ：前者だと、文字列をconstやリソースファイルで保持してパラメーターだけ入れ替えられる（=使いまわしできる）。
ただ、最近はよほどパフォーマンスにシビアだったりリソースを再利用したい箇所でなければstring interpolationを使うことの方が多い（圧倒的に見やすいしバグも発生しにくいから）。

2019/06/16(日) 01:27:37.22

Console.Write($"a は {a}, b は {b}");
こうすると読みやすいしパラメーターの位置を間違える可能性が減る

2019/06/16(日) 01:52:02.63

C# は、面倒だな

Ruby の式展開(interpolation)では、
ダブルクォート文字列内に、#{式} で書くと、式の結果を文字列に変換してくれる

puts "a は #{ a }, b は #{ b }"

2019/06/16(日) 02:00:09.86

>>474
C#にもあるだろ。直ぐ上でも出てる。
$"a は {a}, b は {b}"

2019/06/16(日) 02:05:52.16

1つ上のレスくらい読んでくれよ…

2019/06/16(日) 02:12:46.91

string interpolationは参考にしておいたサイトでは見たことがなく初めて知りました
確かに圧倒的に見やすいですね
varを使うことで必然的に型を指定して初期化することになるので、その辺りの宣言はしっかりしようと思います
ありがとうございました

2019/06/16(日) 02:40:38.10

Rubyの人おかえりはこちらです

2019/06/16(日) 02:49:49.58

>>467
いいね！使ってみる。

2019/06/16(日) 05:00:17.20

interpolation 略して inpo

2019/06/16(日) 08:33:51.55

>>470
WebSocketとかSignalRとか使ったらサーバーからの通知対してにライブラリが適切なメソッドを呼んでくれるのでは

2019/06/16(日) 08:38:40.27

>>458
httpClientをusingする方が間違いでは？

接続先ごとに作るもんだと思ってた。ヘッダとか共通にしたい粒度と同じ粒度で。

2019/06/16(日) 09:55:00.36

>>482
だから…
usingするのは間違いだがじゃあどうやって使いまわすかでバグりやすい

使いまわすのをどこかに任せて使う側は自由に使えるようにしてないと
本当に使いにくい

2019/06/16(日) 12:12:22.08

>>480
+1

2019/06/16(日) 12:20:15.94

>>483
そう？APIアクセスにはこのHttpClient、リソースにはこのHttpClientって別けてると結構便利だけど。
デフォルトヘッダーつけたり、デフォルトのタイムアウトとかをそれ用に設定したりして。

URIなんかで適当に使い回されるのはちょっと使いづらくなるな。

2019/06/16(日) 12:29:55.12

staticなインスタンスを持つという行為がオブジェクト指向にそぐわないのだろう

2019/06/16(日) 12:35:21.44

じゃあDIによるシングルトンで

2019/06/16(日) 16:29:01.69

>>486
それも変な話だけどなー。
staticなインスタンスなわけではなくて、環境に対してインスタンスがあるんじゃないのかな。
使い回すって、もしかして何もかものHttpClientを1つのインスタンスや、いくつか作って適当に余ってるインスタンスで賄ってるの？
少なくとも1ホスト1HttpClientで扱わないとよろしくなかったはず。

そういう意味では、完全にstaticな訳ではなくて、多分MVCならコントローラごとに、宛先ホストやデフォルトヘッダー別のHttpClientを持てば充分なので、特に長寿命になる訳でも、広範囲に露出する訳でも無いんじゃないかな。

毎回作るようなusingで囲む事をするのはよろしくないだけであって、適宜作ってDisposeする分には問題ないっしょ。

だからデストラクタでDisposeできるようにIDisposableなんじゃ？

2019/06/16(日) 17:56:30.01

Disposeは要らんかった
惑わされる

2019/06/16(日) 17:59:45.19

デリゲートのシリアライズについて色々試したところ、WindowsやUbuntuのCore.2.2ではデリゲートのシリアライズは可能でした
まさかMac版だけ違うとは・・・・

>>481
WebSocketについては全くわからないのですみませんが、Signalrは良さそうですね

2019/06/16(日) 18:56:40.91

>>488
絶対に一つのホストに対して非同期で複数接続しない？
変だろそれは？
普通に非同期処理やマルチスレッドなどを多用したところで複数接続することがあるだろ
ちゃんと管理しないとおかしなことになる

2019/06/16(日) 19:03:24.48

>>491
xxxxAsyncはだいたいスレッドセーフだよ。

2019/06/16(日) 19:13:58.14

httpClientの設計がまずいのは周知の事実だろ
オプションとしてならいいけどさ
まともな通信用のクラスをなぜ作れんのだ

2019/06/16(日) 19:20:45.53

んー、なんか俺の返事がズレてる気がする。
1つのホストの1つ用途に対して使い回すのは良いんだけど、
別のホストや別の用途に対して使い回すのは良くないんじゃないかな、って話で、

1つのホストの1つの用途に対して複数のHttpClientを使うのも、悪かないんじゃないの？限度があるけど。
そもそもHttpClientを毎回作ってはいけない理由が、インスタンスを立てるとソケットをopenしに行って、CloseしてもTIME_WAIT以降を待ってソケットがcloseするから、パフォーマンス的にもまずいしソケットが枯渇するって問題なんだし、
捨てないとDNSの変更が反映されない問題も避けれないんだから、LBとか考えると同一ホスト対象でもずっと使い回すより、処理粒度に合わせてインスタンス持つようにした方がいいんでないの、って要旨だった。

2019/06/16(日) 19:22:37.45

>>493
結構まともな設計だと思うけどなぁ。
MSDN読んでない奴が安易にusingしたり、安易にずっと使い回すからいかんのでは？
そんなどうhttp接続を使うかみたいなビジネスロジック層の問題をフレームワークに求めるのは酷じゃ無いかな。
あくまでWindowsのソケットの実装としてはね。

2019/06/16(日) 19:24:29.05

その管理を誰がやるのか？
低級プログラマがそれを考えて使えるのか？

使えないなら管理をどこかでちゃんとやる仕組みを作れ

2019/06/16(日) 19:27:19.28

そもそもの仕組みは簡素なつもりなんだろうけど
結局考えてコーディングしなければバグってしまってアプリを使ってる人にはその理由がわからない

2019/06/16(日) 19:36:40.16

>>496
だからHttpClientFactoryなんだろ何回も言わせんな…

2019/06/16(日) 19:51:24.02

.NET Frameworkは？

2019/06/16(日) 19:58:59.39

>>496
そんな字が書けなくても小説が書けるノートを寄越せみたいな事言って何になるの？

2019/06/16(日) 20:01:51.47

.net core 3.0でWPFサポートはいるけど
それまではWPFなどで作る場合.NET Frameworkだろ
ずっと放置しといて.net coreで入ったからいいなんて思うなよ

2019/06/16(日) 20:02:01.46

>>497
簡単な事だと思うんだけど、考えてコーディングすれば良いだけでは？
考えずにコーディングする方がどうかしてるんじゃないの？
くもんのドリルとか、早指しの将棋じゃねえんだから。

2019/06/16(日) 20:24:08.68

>>490
へー
もちろん、ラムダ式で変数キャプチャーやメソッドやプロパティーにアクセスしたり、
そもそもデリゲートがメソッドを参照してる場合はNGだよね？

2019/06/16(日) 21:07:08.31

まず通信のためのインスタンスを保持しておく必要があるって点が意味不明
なんで一通信毎に一インスタンスを使い捨てさせてくれないんだ？