C#, C♯, C＃相談室 Part93©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/
■コードを貼る場合はこちら
http://ideone.com/
■前スレ
C#, C♯, C＃相談室 Part92
http://echo.2ch.net/test/read.cgi/tech/1485589613/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>694
あれ、C#って、マルチプラットフォームじゃなかったの？
Java は、Windows, Mac, Linux, iOS, Android, Chrome, Firefox, IE, どれでも
動いたよね、昔は。 Javaもクライアントアプリ分野から撤退したから今はクロスプラットフォーム度でいえばC#のほうが上なくらい(あくまでカタログスペック上は)
C#はWebかコンソールアプリなら.NET Core使えばLinuxやMacで動く
スマホやMac向けのGUIアプリならXamarinだな 普及度とかマルチプラットフォームとかどうでもいいけど
Windows使っていて個人的に何かちょっと作ろうと思ったときに、もうC#以外考えられない体になってしまった おれはpythonかなー
スクリプト言語はほんま楽やで
客先でインスト制限きつい時はC#とPowerShell
Microsoftさんは早くVSCodeとdotnet cliをWindows標準にしてPowerShellを強制アプデすべき >>727
個人で使ったけど、これを社内外で使わせるにはMVVMきっちり教えないと破綻確実だから諦めた >>726
確かに楽だな。 < python
Web API を叩くプログラムをこれで書いたけど、学習まで含めてすぐ出来た。w
VS 上でも書けるのが楽さに拍車を掛けてる。
>>727
うん。でも最近はやってないな。そーいえば。 >>727
使ってる。
チームとして採用するのは難しいかもね。 そうです。
XAMLとか慣れるまで大変だし、やっぱり簡単なFORMになるんじゃないかな。 レイアウトはFormよりWPFの方が楽だと思うんだけどな
Formばかりやってたチームだと学習コストが高くて難しいのはある XAMLはVS補佐がまだまだ足りない
昔の落ちまくりよりは格段に進歩はしたが formは過去の遺産だから、これからやるならWPFが正統だ。 >>735
Blendを使ってください、ってことなんだろうけどなぁ WPF自体は終わってるよね
次の本命が無いから使うしか無いだけで MSのイチオシはUWPだしコントロールは充実しているんだけどね
TreeViewは完成したし、後はDataGridの完成を待つだけだ 最近のMSはだいたい未完成
ちょうどGithubもやらかしたし、Azureのサービスなんかガチで世に出しちゃいけないレベルのものが大半 未完成の物をとりあえず出して、
バージョンアップで完成させてくのが昔からのビジネスモデルやろｗ >>747
どういうこともクソもWPFは5年くらい前にとっくに開発終了してメンテナンスモードだよ >>748
ソースは？
.NET Core3.0知らないの？ >>749
ソースは.NET 4.5以降のリリースノートだよ
何か気になる新機能はありましたか？ >>750
で、「終わってる」だなんてMicrosoftはリリースノートに書いてるのかい？
しかも.NET Coreは都合が悪いから無視ときたもんだ… Core3.0まで出てるんだ
なんか使いやすくなった？ WPFが終わってるならFormは死んでる。
しかし、ゾンビ技術者がウヨウヨいるから需要はあるのかも。 >>751
CoreのWPF対応ってWPFをCore向けにビルドしてNuGetで入れられるようにするだけだぞ？
WPF自体の新機能ではないよ >>754
必死に調べて理解したのはそれだけ？
「終わっている」プロジェクトに対してそんなことしないだろ 平日に役に立たない言い争いしている奴らが終わってる WPFの機能追加は終わってる
なら正しいかもしれない >>752
せっかく切ったWPFとFormアプリ復活・・・ 業務系ならありがたいね
ランタイム依存なしでForms使えるんだろ
ブラウザ要らないじゃん >>759
デプロイどうすんの？アップデートの度に君が出向いて客のPCでZip解凍して回るの？
それが面倒だからWebなのに、それが.NET Coreになったところで何も解決しないよ
というかClick Onceが無くなる分だけ状況は悪くなるな >>760
>Click Onceが無くなる
ソース出してみ >>762
悪魔の証明を求められても困る
.NET CoreでClick Onceが使えるソースを出すのは君の仕事だ
当たり前だけど、FullFWのClick Onceを使うという本末転倒な方法は無しで頼むぞ >>763
断定してたからそんなアナウンスもうされたのかと思ったのに…思い込みが激しいと周りが苦労するね WPFが.net coreに対応したといってもlinaxで動くわけではないんだよね？
じゃあなんの意味があるの？ 同じプログラムを2台のPCで動かしたら、スペックのいい方が断トツ実行速度が遅いんだけど、何かチューニングするとこある？ 特に怪しいものなんか動いてないと思うんだけどなぁ
アンチウイルスの保護停止しても変わらない
こんなときに効果的なログの張り方ってある？
一部がネックなのではなく、もう全部が緩慢な感じ 例えばウィンドウズサーチとか重たいよね
リソース逼迫してないなら
ディスクI/OやネットワークI/Oや
ネットワーク構成が違うとかかね
全体的に緩慢となるとなあ
ヒント欲しいならもっと情報ださないとダメよ タスクマネージャーあけてぼーっと眺めておくとひょっとしたらと。
で、スペックはどんなもんなの？ debugとreleaseてそんなに違うの？おれのfizzbuzz100までどっちも一瞬だったよ スレチかもしれんけど、まだサポートしてないバージョンのアセンブリで定義されてるクラスをリフレクションでもいいから使う方法ってないかな。
具体的にはフレームワークのバージョンが2.0しか許可されない職場でxdocumentを使う方法…
dllを隣に持ってきて参照しても、型自体を認識してくれない >>784
100万データ処理してから物言いなさい 64bitアプリから32bitアプリへ効率よく通信したいのですが、良い方法ありますか？
今はPostMessageを考えてますが型が合ってないので違う方法を探してます。 UWPだとreleaseとdebugでちがいそうだけど。デフォルトだとreleaseは.net nativeでコンパイル。debugは違う >>788
TCP使えば？
直接叩くのが嫌ならgRPCとか使えばいい
WCFや.NET Remotingという手もあるけど、どちらもレガシー扱いで.NET Coreからは廃止されたから新規に使うのはお勧めしないな Core世代のWCFや.NET Remotingの代替って何があるんだろ 普通にRESTか、クラウドプラットフォームが提供するメッセージキュー(SQSとか)などの外部サービスだよ
余計な囲い込みを廃して今時のWebシステムの構成要素として組み入れやすくするというのがCoreなんだから、今更.NET固有のRPCなんか要らん dllを修正する際にどの程度までの修正であれば問題ないかまとめてある
サイトってありますか？
dllのクラスの派生元に一つクラスを挟んだ修正では問題なく動いている
ようだったので・・・。 >>795
逆に使えなくなる場合は(マネージドdllで）厳密な名前付きアセンブリとして作ってある物が名前などが変わってしまった場合
厳密な名前付きアセンブリ
https://docs.microsoft.com/ja-jp/dotnet/framework/app-domains/strong-named-assemblies
>厳密な名前付きのアセンブリを参照すると、バージョン管理や名前の一意性を保護できるなどの利点を期待できます
それ以外は変更のないクラスやフィールドにアクセスする分には問題にならないはず >>797
情報ありがとう。
あまり厳密にはしたくないのですがリンク先を
よく読んでみます。 Monoの互換性についてなのですが、
Visual studio2017でWindowsクラシックデスクトップのWindowsフォームアプリケーション(.Net Framework)で書いたコードは
そのままMonoでコンパイルできるという認識であってますか？ >>799
できるし、VisualStudioでコンパイルしたものをMonoでコンパイル直す必要すらない建前なんだけど・・・・
実際には対応状況にかなりの差があってGUIアプリケーションやら暗号やらが絡むものについてはうまくいかない事が多い >>800
そうだったんですね
ありがとうございます >>802
最近は条件付きでできるよ
C# in 引数 Javaのリモートデバッグは
1. 起動オプションでデバッグ用のリモートポートを指定
2. デバッガで同じポートを指定してアタッチ
でできますが
C#(DotNet Core 2.1)では同じような事は出来ませんか？
運用環境でしか発生しないバグのデバッグってどうやればいいんでしょうか？ >>804
リモート側にリモートデバッガ入れるとか
運用環境ということだからそもそもデバッグビルド入れられるか知らんが
まぁ、ログ仕込め 同じLAN内ならプロセスアタッチで行けそうだが
試してないから知らん Unity って、Wikipedia によれば、600,000 (60万人) も、登録ユーザーがいて、
従業員が、2,000人以上、年間利上げが、100億円を超えるほどあるとされる。
ゲームエンジン Unity の使用料は、
・1,000万円までの売り上げなら、無料。
・2,000万円までの売り上げなら、年間5万円ほど。
・それ以上の売り上げなら、で年間18万円ほど。
とある。
でも、Wikipediaに載ってる Unity を使ったゲームのリストは、
100本あるかどうか程度しかない。
これだと、Unityには、年間2,000万円程度の収入にしかならないのでは
ないかと思う。
それに、アメリカですらプロのプログラマは、30万人くらいしかいない
とされることとも辻褄が合わないように思える。
なんかおかしくない？ 基準がwikipediaなのが謎だけど
steamとか見てみなよ
それに×人数だから実際はもっと高い >>808
>それに×人数だから実際はもっと高い
探したけど出てこなかった。どこに書いてある？ そもそもUntiyはプログラマ以外も使うから小さい会社でもアカウントはそこそこもってるようなこともあるよ 最近スマホアプリのtop100くらいまでの使用エンジン調査した記事あった気がしたんだけど見つからんかった
たぶん半分くらいがunity製だった気がする
PCでもUnity製増えてきてるしswitchにもそこそこ出てる
日々山ほどのゲームがリリースされてるのにwikipediaで全てを網羅できるわけないと思うんだけど、なんで自分がおかしいと思わなかったの？ >>811
訪れる？利用するんじゃないの？
ディレクタやプランナがUnity上でプレイすることもあるし、CGデザイナやUIデザイナがUnity上で作業することもある
もちろん3Dモデリングなんかは専用のツールのほうが作業はしやすいけどね っていうか普通の企業なら間違いなく年間売上2000万なんて超えるよ？
安く済ませられるのなんて個人事業主か同人サークルだけ
社員が5人でもいたらまず年間売上で引っかかるんだから
大きい企業なら普通に100単位でアカウント持ってるし、小さいところでも10以上持ってるとこなんて山ほどある アカウントって、1つのゲームに対して、ひとつだけじゃないの？
開発者の人数分？？？ >>815
開発者分必要
ライセンス読んで
あとここUntyスレじゃないよ 年間売上2000万じゃ底辺3人雇うのが精一杯だな。 背理法で証明して見せたかっただけだよ。
つまり、矛盾を示す事で、間違い/捏造であることを証明する手法。
だから、ありえないような結論が出たということは、正しく証明できた
事になる。 ■ このスレッドは過去ログ倉庫に格納されています
