ふらっと C#,C♯,C＃（初心者用） Part139
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■関連スレ
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part138
https://mevius.5ch.net/test/read.cgi/tech/1528194762/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/ >>157
はい。
.frameworkがpoorなのでサポート出来ない事が私には理解できません。
こちらのurlの記事では普通にプロパティで取得出来ているように見えますが…
http://architect-wat.hatenablog.jp/entry/20130501/1367415654 c#アプリって簡単に逆コンパイルで簡単にソース見れちゃうじゃん？
例えばAPIキーとかハードコーディングしてもしてなくても抜き出せてしまうけどどうすんの？ >>160
リバースエンジニアリングはどのくらいの労力がかかるかだけの違いで解析できないものなんかないから諦めろ >>162
ハッシュからAPIキーは復元できないでしょ >>165
結論はどうなってるの？
どうしようもない？ >>159
問題はEFで匿名型が簡単に作られてしまうのが問題ですね。
結局expandoobjectに変換するか、ViewModelを毎回作るしか無さそうですね。 >>161
まあそうだけど
>>164
ふむふむ
>>170
まあそれだね
てかそれやってるんだけど超めんどい >>172
認証のパスワードなどの手続を登録した人に別途配布 サーバーから受け取るようにしたとしてもクライアントが丸見えなら同じ方法でサーバーからキー抜けるだろ
ちゃんとやるなら、開発者だけが知ってる秘密鍵でシリアルキー作ってクライアントごとに払い出すようにする
そしてサーバー側でシリアルキーに基づいてクライアントを識別し、クライアント単位でクォータや権限の制御をする
漏れる前提で他のクライアントに影響が出ないように設計するのが基本的な戦略だよ どうでもいいけど、もともとの質問の趣旨は
ネイティブコードと同程度の秘匿性でバイナリにデータを隠せるかじゃないの？
それは無理、で終わりだと思うけど。 APIキーって5chのAPIみたいなの想像してたけど違うの？
それだとクライアント毎に払い出しても誰か一人のがばれたら使用権貰えちゃうけど >>175
APIキーを抜くくらいならネイティブでも難しくないよ >>176
それで困るのは5chではなくブラウザの開発者だろ？
5chにとっては、特定のクライアント(この場合は開発者単位な)からの不正な大量投稿があれば、
そのクライアント(開発者)を丸ごとBANしてしまえばいい。他のクライアント(開発者)には影響しない。それを防ぐ責任はあくまでクライアントの開発者にある。
ユーザー単位で払い出すにしろ開発者単位て払い出すにしろ、個別に払い出すことで責任をAPIキーを払い出された側に転嫁できるんだよ。 ソースコード丸見えだから、APIキーがどこにあるかわかるよね
そうやって海賊版作れてしまうわけだ 流石にAPIキーを普通に文字列で書くアホはnativeでも居ないだろ。
難読化する。
ソースコードが丸見えだとしても問題無い気はする。どーせnativeでも逆アセンブルするんだし。
カジュアルな対策なら、c#には逆コンパイルされないILコード使って復号ロジック書くべきかと思うな。
ちゃんとやるならドングルかライセンスサーバのどっちかじゃねえかな。 nativeと同程度の隠匿で良いならそこだけnativeにすれば良いだけやん oauthのキーなら速攻でばれるし文字列でそのまま書くな。難読かしても意味ねぇし。やるだけ無駄。 DBのパスワードとかソースに直書きしてるわ
ハッシュにしてもどこで復号すればいいのか 自前でやるだけのセキュリティのスキルがあるとこは珍しい
素直にASP.NET Identity + IdentityServerでOIDC使っとくのが懸命な判断 こういう大事な部分を手軽で強固なセキュリティとしてなんでMSは用意しておかないんだ？ はい意味不明
OIDCってアプリ側がユーザーの認証認可をする仕組みだぞ？
それをどうクライアントアプリのAPIキーの隠蔽に使うのか教えてくれ >>186
もうすでにＣ＃関係なくなっているが手軽で強固なやり方ってどんなことよ？ >>186
本質的に不可能だからだよ
見られたくないならクライアントに埋め込まずにサーバーに持ってプロキシせよってこと >>172
マシンに固定したいならMACアドレスとかHDDのシリアル番号とかで特定
ユーザーに固定するなら登録されたパスワードを定期的に入力とか >>190
中間言語形式だけでなくスクリプト言語も否定する気かｗ >>187
チュートリアルもやったことないのかよ… >>193
だから何のことを言ってるんだ
アプリ本体がユーザーの手元にあるのに認証認可もクソもないわ >>192
サーバー型はビジネスロジックがサーバー内にあるからそこで防げるけど、c#アプリは無理じゃん >>196
UWPじゃなくFormアプリでおねがい >>196
これユーザーが入力した認証情報を安全に保持するのと、サーバー側のリソースに関するユーザーの認証認可をする話だよね
開発者の機密情報を安全にクライアントに持たせるのとは全く別の問題だよ(そしてそれは原理的に不可能) もちろんクライアント側で復号する必要がなくて、単にデータストアをクライアント側に置きたいだけなら、サーバー側で暗号化すればいいだけだよ
原理的に不可能なのはクライアント側でも機密情報を復号して使う必要がある場合の話ね Dapperを使用するにあたり、下記の「DAO」クラスの「SelectDAO」メソッドの
戻り値を抽象的に表現できれば、SQL与えるだけで共通に使えるのになと思っているのですが
戻り値を下記のList<IAB>のように書く方法はあるでしょうか？
interface IAB{ }
public class A : IAB { public string nen{ get; set; } }
public class B : IAB { public string nen{ get; set; } }
public class DAO
{
public List<IAB> SelectDAO(string sql)
{
System.Data.IDbConnection _con = new SqlConnection("接続文字列");
return (List<IAB>)_con.Query<IAB>(sql);//DynamicMethodに対する型オーナーが無効です。
と怒られます。
}
} >>202
いやSQLを隠蔽するのがDAOなのにSQL渡したらダメだろ… ようするにdaoなんか使わずに
odbc使いなさいということ >>202
戻す値をList<dynamics>にすることで解決します。
マジオススメ >>203
Dapperは緩いORMでクエリは書く必要あるんです
EntityFrameworkなら確かに悩む必要無い問題な気がします API抜かれるってどのシーンで警戒してるの？サーバー上でアプリ起動してるとき？ >>202
最終的にDapperも何らかのインスタンスをnewしないといけないのに
IABだけ渡されても何作ればいいのか分からないだろ
素直に
public List<T> SelectDAO<T>(string sql) where T : IAB
とかに
というかSelectDAOを呼び出した側はメンバの存在しないIABを使って何をすればいいのか >>207
いやそういう問題じゃなくて、SQLを書くんだったらDAOの中で書くんだよ
外からSelectクエリを文字列で受け取るってそれ使う側がDBのテーブル構造を知ってないとできないだろ
データストアの詳細を全く隠蔽できてない >>211
1知識1DAOクラスが本来の姿という事でしょうか?
実装レベルでもうちょっと抽象化できるかと思ったのですが設計レベルでは好ましく無いとなれば深追いは不要ですね VS2017WindowsFormsAppの実行ファイルを作成したのですが、
実行ファイルをzip圧縮するとサイズが10分の1以下になります
小さくなりすぎな気がするのですが正常の範囲で問題ありませんでしょうか？
または、実行ファイルが肥大？（余分な情報が含まれている等）していたりするのでしょうか？
なにかVS上で出来ることはありますか？ >>214
使用しないのならデバッグ情報とか埋め込まれるマニフェストとか外せるけどそれは肥大するほどでもない
どんな実行ファイルか見てみないと分からないし解凍しても動くのなら気にしなくてもいいのでは プログラミング初心者です
visual studio for mac2017をインストールしてC#を覚えたいんだけど、どうやって学習したらいいのか教えてください！
探してもなかなかいい日本語の学習動画やサイトがなくて、、、 >>215
ありがとうございます
1MBほどのファイルが80KBほどになるので、小さくなりすぎではないかと思いまして…
生成される実行ファイルが、プロジェクトのある時点から1MBほどに大きくなったような記憶もあります
読み込み差し替えした画像リソースが上手く外れていないのかなと想像したりしますが…
もうちょっと色々自分で調査してみます >>216
念のため書いておくけどMac版はWinフォームやWPF作れないからな
>>218
コード中心で1MBくらいになるのは数万行のものだから、そんな縮むのは間違いなく画像リソースだろうな
BMP形式で入っているとかアイコンが多いとかならZIPでもかなり縮む >>219
コードは5000行ほどですね。試しにプロジェクトを新規で作り直して中身を移し替えてみます
エクスポートインポート的なのがあれば良いのですがVS標準ではないみたいなので
大変ですが手動でやるしかないですが OSデフォルト環境だとsn.exeがインストールされてないのか
隔離環境で作ったアセンブリにストロングネームつけたい時ってみんなどうしてんだ？ >>217
>>222
未確認ってどちらかというと入門じゃなくて確認用途だと思うよ
あれを見て判る人はすでにjavaなどの他の言語を習得してる まあそうだね
C#でプログラミング入門って正直キツいと思うし、そういうコンセプトのところは
たぶんないんじゃないか >>225
俺は「C#の絵本」でプログラミング入門した。
つまり、C#でプログラミング入門した プログラミングはDelphi6からだったなー
\5,000でパッケージを買ったすぐ後に、無料版のDL提供が始まった思い出
高校生にとって\5,000は地味に痛かった…… >>225
何がそんなにキツい？
Windows Formsのぽとペタ以上に初心者に優しいのってなんだろ 英語得意ではなくてプログラミング言語の経験が全くないのなら
本を買う方がいいような気もする・・ 神サイトはどぼんでしょ
あのサイトのコピペがC＃する日本ITドカタを支えてる >>228
細かいことよくわかんないけどなんとなくコピペで動くからいいやとVB的に使うならそれでいいけど、
言語を一から体系的に習得しようとするとC#はかなり大変だよ
継続的に進化してるから実感がないかもしれないが、今のC#はもはやメジャーな言語の中ではC++に次いでトップクラスに複雑な部類 仕事でも趣味でも体系的に一から学ぶとかやっていたら何もできなくなる
自分の必要な部分以外勉強するのはもはや研究者 C#って、言語仕様で難し目なのはyield, dynamic, awaitくらいな気がする
複数ある実行環境や巨大なフレームワーク、コンパイル後のILの話まで含めたら複雑だと思う >>237
たとえば簡単なところでいうと、読み取り専用プロパティの定義には今何種類のバリエーションがあるか知ってる？
int Hoge { get { return 5; } }
int Hoge { get => 5; }
int Hoge => 5;
int Hoge { get; private set; } = 5;
int Hoge { get; } = 5;
これらにどういう違いがあってどういうときにどれを使うべきか初学者向けに説明できる？ >>238
どれでもいいじゃん
まずは動けばいいんだよ
バグる？そんなのバグったときに対応すればいい
どうせ世の中のほとんどのアプリがバグだらけなんだし
そしてそのバグ取り経験が学習にもなる C++やったことないから知らないどC++は基本的なことも複雑なイメージ
C#は極めるほど複雑なイメージ >>238の例なら初心者は一番上だけ知っとけばいい 複雑なことができると学習が困難
すべてを学習すること前提ならそうかもしれん >>236
>>125 でも質問させていただいたのですが、
yield, dynamic, await あたりは理解できているつもりであるものの
volatile の役割がどうしても理解できません。
慣れている方にとっては当たり前のことなのかもしれませんが、
volatile がある場合とない場合で動作が変わるコードの例だけでも
お教えいただけないでしょうか。
どうぞよろしくお願いいたします。 >>244
>volatile がある場合とない場合で動作が変わるコード
難しいんじゃないかなあ
(1) 実行儒所を入れ替える
(2) 変数（メモリ）に直接アクセスしない
みたいな最適化がどういうケースでコンパイラによって行われるか、たぶん誰もよく知らないw
だけでなく、古い記事だけど
http://www.itmedia.co.jp/enterprise/articles/0503/23/news086_4.html
↑にあるように、CPUレベルの最適化はCPUに依存する >>125
volitateは「この変数はマルチスレッドで使うよ」と明示することによってシングルスレッドの場合にしか効果的ではないような実行速度の最適化技術を使わせないようにするだけであって、排他制御を自動で行うものではないのでは？ >>245-247
皆さんレスどうもありがとうございます！
>>245
> >volatile がある場合とない場合で動作が変わるコード
> 難しいんじゃないかなあ
ありがとうございます。
ということは逆に言えば、volatile が無いことによって想定外の最適化が行われて
不具合につながること自体が起こりにくいものだと考えてもいいのでしょうか。
ただ仮にそうだとしても、お作法的には複数のスレッドからアクセスされる可能性のある
フィールドはすべてに volatile を付けるべきなのかなとも思うのですが、
CS0420 : volatile フィールドへの参照は、volatile として扱われません。
のような警告がうるさくてあまり volatile をつけたくないときもあるので悩んでしまいます。 >>246
参考ページのご紹介どうもありがとうございます。
実はそのページも読んでみたのですが
> ちなみに後者の記事では実際にvolatileをつけないと問題のあるコードが記載されている。
> 以下のコードをReleaseモードでビルドして、デバッグなしで実行すると終了しない。
> volatile をつける(static volatile bool complete = false;)と正しく終了する。
という記述に反して、私の環境（Win10, .NET Framework 4.7.1）では
volatile がなくても終了してしまうようです。
そもそも私にはそのページのコードと >>125 のコードが本質的に同じものに見えてしまい、
> volatileに対する理解がなんか違う気がする
とおっしゃることの真意が理解できていないのですが、
何かお気づきのことがあれば教えていただけないでしょうか。
>>247
レスありがとうございます。
つまり、volatite の有無で実行速度に差が出ることはあっても
計算結果が変わることはない、ということでしょうか。
そうであるなら気が楽なのですが、いくつかのページやここでの他の方のレスを読むと
どうしても確信が持てずにいます。 >>248
確実である保証がないものに確実性の保証を与えるvolatileを「お作法」
と思う発想は100%間違っています >>250
レスどうもありがとうございます。やはり、>>249 に書いたような
> volatite の有無で実行速度に差が出ることはあっても
> 計算結果が変わることはない
などということを期待してはいけないということでしょうか。
ただ、volatite が無いとどのような問題が起こるのかを理解していないと、
どのような場面で volatite を使えば確実性の保証が得られるのかも分からず、
結局は、なんとなく気分が悪いから volatite をつけておこう、
というレベルにとどまってしまうように思うのです。
確実である保証がないことを証明するというのは
一種の悪魔の証明なのかもしれませんが、
例えばオーバーフローの危険性を説明するなら
int x = int.MaxValue;
int y = 1;
int z = x + y;
のようなコードを見せればいいですし、
volatite についてもこのようなコードがないものかと期待して
質問させていただいた次第です。 volatie付けないとマルチスレッドだと遅くなるとかじゃないのか？
実行結果が変わるとか困るしそんなことになるならもっと知られてるはずなんだが >>251
最適化のオプション外してビルドしたら？
保険であるvolatiteが「どのようなときに必要か」はMSも公表していないんだからどうしようもない
volatiteを含んだ上で機能するコードをどうしても書きたいとかなら知らないけど 保障のようなものでしょ
今はどうか知らないけど
例えば
a=1;
a=1;
a=1;
a=1;
a=1;
みたいなコードがあっても最適化でa=1が一回しか実行されないようにならないで
ちゃんと回数分実行されることの保証 憶測で申し訳ないけど
a=calc0(a);
b=calc1(a);
が最終的にアセンブラレベルで
フィールドa = レジスタA
レジスタA =フィールドa
みたいなのが出てきた場合に
シングルスレッドであればあとのレジスタA=aの実行が無駄じゃないかと思って
実行しないとかありうるかもしれない
マルチスレッドならフィールドaが書き変わってる可能性あり >>255
コンパイラの最適化で削られるんじゃなく実行されないのか
どっちにしてもきりがない ■ このスレッドは過去ログ倉庫に格納されています
