.Net Core / Net ASP Core [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/06/30(木) 03:45:41.80

おらの群馬さにはIISなんてねえもんでりなっくすさ使ってしぃしゃーぷさ動かすべえな
こんなの動くなんておったまげえな時代だわな

んだいくべえ

**デフォルトの名無しさん** · 2017/12/10(日) 08:51:17.88

スクリプト書けばいいじゃん
なにを悩んでるんだ

**デフォルトの名無しさん** · 2017/12/10(日) 10:30:05.23

>>328
Entityに対応するViewModelとモデルファットってのがよくわからんが

**デフォルトの名無しさん** · 2017/12/10(日) 10:47:26.57

MVCモデルで書いててモデルファットが通じないってマジかよ
コンローラにロジック盛り盛りなの？

**デフォルトの名無しさん** · 2017/12/10(日) 11:14:17.45

システム運用開始後に運用者側でモデルを変更したいって話?

それは俺も今考えててデータはJSONで保存してビュー側でJSONのないようにて
動的にテンプレート変更するしかないのかな状態。

**デフォルトの名無しさん** · 2017/12/10(日) 11:16:34.18

fat modelを実装したい←意味わからん
設計ミスってfat modelになってしまった←意味わかる

失敗した結果をfat modelという
それをなんで実装したいの？

**デフォルトの名無しさん** · 2017/12/10(日) 15:56:56.62

ああ、なんかスマン、煽り気味に書いたのに割とマジな回答も貰っちまって微妙な気分。

LL言語系FWのMVCモデルでユニットテストを書きやすくするため、単純なInputに対して単純なOutputを返す"モデル"に実装を寄せる考え方をモデルファットって言うのね。
Rails系が流行ったあたりから今も変わらない、所謂Web系の皆さんの基本アプローチになってて。

ASP.Net MVCを触ってて、MS世界というかASPの思想上には無い概念だ、というのは分かった。
ただ俺の都合として、社内でRails系FWに慣れ親しんだ連中をこっちに誘導したいわけですわ。
よって昔ながらのFWにある機能は一通り用意した、ASP版FWを当てがってやるつもりでいる。

その一環でスキャッフォルド機能も実装中だった、というわけです。

**デフォルトの名無しさん** · 2017/12/10(日) 16:21:23.96

モデルファットじゃなくファットモデルな
ファットコントローラーを嫌ってモデルに処理を移動したのはいいが
単にモデルを巨大化させただけでファットコントローラーとやってること同じじゃんっていうやつね
ファットモデルになってしまったという事はあるけど狙ってファットモデルにするって事はありえないよ
なのでそれをサポートするフレームワークも当然ありえない

**デフォルトの名無しさん** · 2017/12/10(日) 17:07:27.42

Rails触ってれば幸せだと思うよ

**デフォルトの名無しさん** · 2017/12/10(日) 17:08:54.50

>>334
勝手に基本アプローチにすんなよw

**デフォルトの名無しさん** · 2017/12/10(日) 17:40:41.52

スキャフォールドはリバースエンジニアリングでもリファクタリングでもないだろう
スキャをどうこうじゃなくて、リファクタリング系の充実を望むって話じゃないか

**デフォルトの名無しさん** · 2017/12/10(日) 17:46:47.12

なんでそういう無意味なことをするのかが理解できん
頭悪そう

**デフォルトの名無しさん** · 2017/12/10(日) 18:23:41.80

なんのかの言うだけでネタはねーのかよショボチンやなー
結局ご本家ソース読んでたら出来ちまったわ

しっかし、モデルを太らず実装を拒絶するMVCerってのは正直生まれて初めて見たな...ちゃんとテスト書いてのかよｗ
太り過ぎたら分割すりゃいいし、分割するにもController分割よかずっと楽だろうに
Identityのソースでもやってる実装やし、別にフツーのことやぞ？

**デフォルトの名無しさん** · 2017/12/10(日) 18:41:31.13

>>340
君のなにが悪かったかっていうとモデルファットと言ってしまったことだよ

そもそもモデルファットじゃなくファットモデルというのは見逃すとしても
ファットモデルってのはファットコントローラーと同じアンチパターンのこと
それを当たり前の王道みたいな風に言ったからおかしなことになった

コントローラーから処理を抽出してモデル(サービス)に移動するのは当たり前の王道
ファットモデルはその王道をよく理解せずにコントローラーに無ければいいんだろ？と考えなしにモデルを拡張して破滅するアンチパターンのことを言う

**デフォルトの名無しさん** · 2018/01/20(土) 12:58:14.78

.net core 2 でSQLサーバとを連携させて、
スキャフォールディングなどを使ってみたいんですが、
対応しているSQLサーバのバージョンの制限などあるでしょうか。
今、たしかexpressの2010版が動いていると思います。

**デフォルトの名無しさん** · 2018/01/20(土) 13:20:46.75

>>342
たぶんEntityFramework Coreのことだよね？SQL Serverなら2008以降が対応してる

**デフォルトの名無しさん** · 2018/01/20(土) 22:30:41.03

>>343
レスいただきありがとうございます！
そうです。EFのことです。

ところで、EFはストアドプロシジャのモデルバインドに対応していないのは残念。

**デフォルトの名無しさん** · 2018/01/21(日) 02:02:53.48

>>344
Dapper使えば？
http://dapper-tutorial.net/execute

**デフォルトの名無しさん** · 2018/01/21(日) 10:37:20.74

>>345
そういうのもあるんですね。
自分は次の方法です。

DBContextの、FromSqlというメソッドで、
パラメーター付のストアドプロシジャ（SELECT文）も呼び出せるようです。

INSERT UPDATE DELETEは、
EXecuteSqlCommandAsync というメソッドを代わりに使えるようです。

Microsoft.EntityFrameworkCore.Relational パッケージを、導入している必要があるそうです。

どっちのパッケージがいいんでしょうか。

**デフォルトの名無しさん** · 2018/01/21(日) 10:57:34.80

>>346
それめっちゃ遅いから、ストアドプロシージャならDapperの方がいい

**デフォルトの名無しさん** · 2018/01/21(日) 23:20:22.28

>>347
アドバイスありがとうございます。
先輩に従わせていただきます！！

**デフォルトの名無しさん** · 2018/01/23(火) 03:24:09.32

Apologies for lack of ODP .NET Core status updates. Beta coming very soon.

https://twitter.com/OracleDOTNET/status/955487498922164224

**デフォルトの名無しさん** · 2018/01/23(火) 03:24:32.04

やっとくるか

**デフォルトの名無しさん** · 2018/01/24(水) 11:12:26.60

BootStrap 4が登場したらしいね

**デフォルトの名無しさん** · 2018/01/27(土) 11:54:23.36

odp.netね
もうポスグレに移行しちゃったよ
脱ORACLEかなり捗った

**デフォルトの名無しさん** · 2018/01/27(土) 12:17:19.30

びっくりするくらい遅いな

**デフォルトの名無しさん** · 2018/01/28(日) 00:21:12.53

Javaのretrofitみたいな感じでタイプセーフなrest api clientをビルドするためのdot net coreライブラリって無いの？

**デフォルトの名無しさん** · 2018/01/28(日) 02:51:56.28

>>354
ビルド？

**デフォルトの名無しさん** · 2018/01/30(火) 09:59:36.41

>>354
コードジェネレートの話をしています？

**デフォルトの名無しさん** · 2018/02/02(金) 18:51:27.51

モデルオブジェクトの定義で、

[Table("任意の日本語テーブル名")]属性
[Column("日本語の列名")]属性

は使えるでしょうか。

asp.netでは、説明がありますが、
core2ではどうなのかなと思って。

**デフォルトの名無しさん** · 2018/02/02(金) 19:03:37.12

>>357
EntityFramework Core2.0のことを言ってるんなら使えるよ

**デフォルトの名無しさん** · 2018/02/02(金) 19:53:34.57

>>358
わー、さっそくレス頂きありがとうございます
そうです。
EntityFramework Core2.0　のことです。

パッケージ導入して、環境を準備して、
やってみたいと思います。

EntityFramework Core2.0では、規約がものをいうので、日本語のテーブル名、列名を使っているデータベースでも大丈夫なのか不安なのでした。

ハローワールドは成功したので、dbcontext、エンティティ、そしてテストコードを書くところです。

EntityFramework Core2.0って、コードファーストや、データベースファーストを推してくるんですが、そういう自動生成機能って、使わないで、自分で両方の定義をしてもいいのですよね。

皆さんはどういう風にしているのだろうか。

**デフォルトの名無しさん** · 2018/02/02(金) 21:30:19.18

>>359
DBからコードファースト

**デフォルトの名無しさん** · 2018/02/02(金) 21:38:01.80

SQL-firstってのもある
http://www.thereformedprogrammer.net/ef-core-taking-full-control-of-the-database-schema/

Production環境でのMigrationを考えると、この辺が現実的かな

**デフォルトの名無しさん** · 2018/02/04(日) 08:29:27.62

>>360
日本語のテーブル名とか、列名つかってなかったの？
英語の複数形をテーブル名にしてたとか、ルールを意識して構築してたのかな。

**デフォルトの名無しさん** · 2018/02/04(日) 11:06:40.73

>>362
日本語なんて使うわけないけど、何をそんなに心配してんの？

**デフォルトの名無しさん** · 2018/02/04(日) 21:58:59.60

>>362
まさか複数形じゃないとテーブル名として使えないとでも思ってる？

**デフォルトの名無しさん** · 2018/02/04(日) 23:06:57.46

>>363
sql server 7.0の頃から構築したテーブルで、
日本語のテーブル名と列名が使われているんだよ。
そのままスキャフォールディングするのも心配。
日本語のクラス名とかプロパティーなんて見たくないし。

**デフォルトの名無しさん** · 2018/02/04(日) 23:07:57.43

>>364
いや、規約から外れていると何か不具合が発生しそうで。

**デフォルトの名無しさん** · 2018/02/04(日) 23:08:51.68

view使えば？

**デフォルトの名無しさん** · 2018/02/04(日) 23:10:53.16

>>366
ドキュメントよく読め

**デフォルトの名無しさん** · 2018/02/05(月) 07:55:09.71

>>368
水色の.net coreの参考書しか読んだことない。
あと、薄紫色のASP.NET MVCの書籍とか。
ドキュメントなんかあるんか？

**デフォルトの名無しさん** · 2018/02/05(月) 07:56:15.21

>>367
View？
htmlを描画するやつのことではないと思うけど。

**デフォルトの名無しさん** · 2018/02/05(月) 08:53:07.85

sqlのviewだと思うが、書き込みは普通にテーブル使うしか無い
どうしても避けたいのならWebAPIでも使うのが最善かも
DBがインストールされたサーバー内だけなら日本語テーブル名問題は起こらないだろうから
その後を全部英文字にすればトラブルフリーに出来るかもしれん

**デフォルトの名無しさん** · 2018/02/05(月) 09:02:42.42

>>369
公式の

本が欲しいんならこれとか
https://www.manning.com/books/entity-framework-core-in-action

この著者のブログも読んでみ

**デフォルトの名無しさん** · 2018/02/05(月) 18:16:52.57

>>367
まだ全然やで
https://github.com/aspnet/EntityFrameworkCore/issues/1679

**デフォルトの名無しさん** · 2018/02/06(火) 00:30:12.46

>>372
なんか宗教くさい

**デフォルトの名無しさん** · 2018/02/06(火) 00:31:20.97

>>374
表紙の話？

**デフォルトの名無しさん** · 2018/02/06(火) 02:09:36.97

>>375
うん、でも嫌いではないんだけどね、多分、カバーで隠して読むだろうね

**デフォルトの名無しさん** · 2018/02/06(火) 02:22:08.83

>>376
電子書籍だからカバーもクソもないと思うが

**デフォルトの名無しさん** · 2018/02/06(火) 22:06:09.44

>>377
アマゾンでは紙本だったよ

**デフォルトの名無しさん** · 2018/02/06(火) 22:07:06.60

>>378
ごめん

**デフォルトの名無しさん** · 2018/02/07(水) 03:10:06.91

ASP.NET MVC の　知識ってほとんどそのまま、.net core MVC で通用すると考えていいのかな？

**デフォルトの名無しさん** · 2018/02/07(水) 05:24:08.06

そのままではないけど、すぐになじむとは思うよ

**デフォルトの名無しさん** · 2018/02/07(水) 13:16:27.18

>>379
大丈夫

**デフォルトの名無しさん** · 2018/02/10(土) 00:32:08.18

スキャホールディングしなくても、それが出力するようなコードを、
モデルと、DbContextに自分で全部書き起こせば、
データベーステーブルでテーブルの結合したやつでも得られるんだろうか。

データベースでリレーションの設定をしていないので、スキャホールディングでテーブル結合反映されないため、
自分でコードを記述しようと思っているんです。
データベース側は既存のプログラムとの連携が壊れたら困るのでいじりたくありません。。

**デフォルトの名無しさん** · 2018/02/10(土) 06:53:12.80

業務系は複雑怪奇なレガシーDBの呪縛があるからEFとの相性が最悪
SQLを手で書いてDapperでマップするのが正解だよ

**デフォルトの名無しさん** · 2018/02/10(土) 08:43:26.95

壊してもいいデータベースで開発したら？

**デフォルトの名無しさん** · 2018/02/10(土) 11:53:53.43

>>385
壊してもいいデータベースで開発してから、
それを本番のデータベースで運用する予定

>>384
Dapperについて調べてみます。
ストアドプロシジャとパラメーターがつかえたらいいんだけどなあ

**デフォルトの名無しさん** · 2018/02/10(土) 14:09:18.74

>>386
ストアドプロシージャとパラメーター使えるよ

**デフォルトの名無しさん** · 2018/02/10(土) 17:39:31.77

>>387
ありがとうございます

**デフォルトの名無しさん** · 2018/02/11(日) 15:30:58.53

Dapperでは、SQLやストアドプロシジャの結果行に対応したモデルクラスに、
マッピングできるのだとわかってきました。

自分のところのストアドプロシジャでは、テーブルにはない新しい列が登場したり、列の名称が付替られたりするので、
ストアドプロシジャの結果行に対応した専用のクラスをいちいち作成しようと思いました。

ストアドプロシジャでは最終的に、SELECT文で出力したい列が列挙されています。
対応するクラスのプロパティー名（日本語）と列名（日本語）を一致させておけば、
列挙の順番は関係ないでしょうか。

**デフォルトの名無しさん** · 2018/02/11(日) 15:41:40.43

>>389
え、日本語？

**デフォルトの名無しさん** · 2018/02/11(日) 15:53:15.39

>>389
そうだよ
基本的に名前を見比べて1行と1オブジェクトに変換してくれるだけ
変換ルールのカスタマイズも出来るけど保守性がよくないから避けたほうがいい

**デフォルトの名無しさん** · 2018/02/11(日) 21:30:20.43

>>391
レスありがとうございます！

既存のストアドプロシージャーを使って、
テストコードを試してみたいと思います。
結果をマッピングできるのはとても便利ですね。
ありがとうございます！

**デフォルトの名無しさん** · 2018/02/11(日) 23:27:37.20

>>390
列名が日本語で書かれているんですよ。

select ID,名称 from ほにゃらら

みたいな感じでデータを引っ張って来る必要があるので、
マッピングするC#クラスのプロパティーも、こういうのに合わせる必要があるわけなんです。

日本人なら分かり易いというメリットはあるんですが、
システム上の互換性でいつか面倒なことにならないかと心配しますね。

**デフォルトの名無しさん** · 2018/02/11(日) 23:53:51.87

>>393
列名とプロパティ名はこんな感じでマッピングさせる手もある
https://github.com/tmsmith/Dapper-Extensions/wiki/Customized-mapping-for-a-class

**デフォルトの名無しさん** · 2018/02/12(月) 08:53:13.20

>>394
ありがとうございます。

なるほど、そうすれば英語表記のモデルクラスが使えるということですね。
日本語クラス名、プロパティー名で結構だというのなら、使う必要はないという理解でいいのかな？

ところでこれは、DBContextの、関連付けとちょっと似ていますね。
メソッドチェーンしながら、ラムダ式を与えて、エンティティーの定義を行っていました。

**デフォルトの名無しさん** · 2018/02/12(月) 08:55:15.61

>>391さんのおっしゃる、
”変換ルールのカスタマイズも出来るけど保守性がよくないから避けたほうがいい”
というのは、この>>394さんのおっしゃっているカスタマイズのことなんだろうね。

**デフォルトの名無しさん** · 2018/02/12(月) 09:05:51.69

sqlのasを使うと簡単だね
ただoracleだとasしても英訳した列名が30文字に収まらない場合がある

DBの物理的な制約を気にしたくないなら
DTOからドメインオブジェクトにマップする時に物理名を論理名に変換すればいいよ
DTOは日本語を含んでよい
ドメインオブジェクトは日本語を含まない
変換処理はC#で手作業で書く
DapperでDTOを取得して変換処理に流し込む

**デフォルトの名無しさん** · 2018/02/12(月) 10:06:28.69

>>397
>変換処理はC#で手作業で書く
>DapperでDTOを取得して変換処理に流し込む

これは、どういうことですか？
Dapperはドメインオブジェクト（モデルクラス）に行データを自動的に変換してくれるものだと理解してます。

そして、必要なら、日本語の列名を、クラスの英語名のプロパティ名に変換するために、>>394さんの方法を使うのですね。

Dapper自体と、DTOとの区別がわかりません。
いったん取得した行データの日本語名プロパティを含むクラス型を、完全英語名のクラス型に値をプロパティごとにC#でコピーするということでしょうか？

**デフォルトの名無しさん** · 2018/02/12(月) 11:47:11.65

DapperはSQLの結果セットをDTOにマッピングしてくれるだけ
DTOからドメインオブジェクトへのマッピングは別途用意しなければならない
DTOとドメインオブジェクトを同一視してマッピングを省くことは可能だけど
それをやるとドメインオブジェクトが歪な構造になるのでオススメしない

**デフォルトの名無しさん** · 2018/02/12(月) 11:52:36.00

>>399
>DTOとドメインオブジェクトを同一視

**デフォルトの名無しさん** · 2018/02/12(月) 12:16:20.63

＞DTOとドメインオブジェクトを同一視

自分はその同一視をしていたのかもしれない。これは、アプリの設計に深く関わる問題ですね。
ドメイン駆動アプリ？だかの参考書を読んでいたときのことを思い出しました。
でも知識を使う前に、すっかり忘れていました。

最初、こんなつもりでした。
例えばこんな感じで、モデルクラスを定義して、
自分の場合、データベースの日本語列名に合わせて、日本語のプロパティー名で定義して、

public class 人間
{
public int Id { get; set; }
public string 名前 { get; set; }
}

そして、
SQL Server → Dapper →「人間クラス」
（こうして、人間クラスに行データがマッピングされる。だから、「人間クラス」がDTOでいいのかな。）

で、
ControllerのActionメソッドとかから、この「人間クラス」のオブジェクトにアクセスして、
Viewなりに渡そうとしていました。

ああ、これでは同一視になりますよね。

つづく↓

**デフォルトの名無しさん** · 2018/02/12(月) 12:17:48.80

＞DTOからドメインオブジェクトへのマッピングは別途用意しなければならない

SQL Server→Dapper→「人間クラス（DTO）」→→（変換）→→「ドメインオブジェクト」

なるほど。>>397でおしゃっていたことが理解できたかも。

DTOまでは、日本語名のクラス名やプロパティーでもOkなわけですね。
しかし、ドメインオブジェクトという形に、変形してアプリに統一性を持たせるべきで、
そのときに（ついでに）、英語に統一すればいいというわけなのか。

もし、私の理解が間違っていなければ、目から鱗でした！
ありがとうございます。もう一度、設計のための参考書を開いてみたいと思います。
勉強したことを使わないうちに、どんどん忘れてしまう。。。。

しかし、こうして、
日本語名から英語名への統一でも、ドメインオブジェクトという考え方が役に立つんですねえ。

ありがとうございます。

**デフォルトの名無しさん** · 2018/02/12(月) 12:53:34.77

>>402
DTOからドメインオブジェクトへの変換は一パターンとは限らない
だからDapperからDTOにマッピングする時点で、c#の規約に沿った形のクラス/プロパティ名にしておくと便利
じゃなきゃAutoMapperすら使えないし

**デフォルトの名無しさん** · 2018/02/13(火) 13:00:12.61

>>403
どこで、日本語名の列を、英語名のプロパティーに変換するかという問題なんですよね。

SQL Server→Dapper→「人間クラス（DTO）」→→（変換）→→「ドメインオブジェクト」

SQL Server→Dapper→→（変換）→→「人間クラス（DTO）」→ ※ →「ドメインオブジェクト」

ところで、AutoMapperは、上記の※の位置に来るという理解で正しいでしょうか。

**デフォルトの名無しさん** · 2018/02/13(火) 19:41:40.28

ＤＢには日本語つかうのに、プログラムに日本語使うのを嫌がるのが理解できん

**デフォルトの名無しさん** · 2018/02/13(火) 20:39:57.91

>>405
別に質問者は嫌がってなくね？

**デフォルトの名無しさん** · 2018/02/13(火) 22:00:43.94

>>405
var p = new 人間（）;
var n = p.名前;

こんな感じなのは、普通ってことでしょうか?

**デフォルトの名無しさん** · 2018/02/13(火) 22:02:48.71

var s = new 🍣();

**デフォルトの名無しさん** · 2018/02/13(火) 22:25:03.46

カスタムルールはメンテナーがカスタム手順わからなくて困るパターン
手動マッピングなら5分で書けるのにルール設定がわからず1時間ハマりっぱなしとかよくある

**デフォルトの名無しさん** · 2018/02/14(水) 00:25:23.19

>>409

>>404のように、
DTOとドメインオブジェクトとのあいだで、
手動変換するということですね

**デフォルトの名無しさん** · 2018/02/16(金) 06:17:18.75

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**デフォルトの名無しさん** · 2018/02/17(土) 13:05:06.90

Oracle has updated its .NET Core statement of direction. http://www.oracle.com/technetwork/topics/dotnet/tech-info/odpnet-dotnet-ef-core-sod-4395108.pdf

tl;dr
https://t.co/Zn0Rz2SBM2 Core production in CY Q3 2018. EF Core beta shortly after targeting same quarter.
https://twitter.com/OracleDOTNET/status/964631730220023808
https://twitter.com/OracleDOTNET/status/964632656725008384 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)

**デフォルトの名無しさん** · 2018/02/17(土) 13:22:36.50

サンプルのリポジトリ
https://github.com/oracle/dotnet-db-samples

**デフォルトの名無しさん** · 2018/02/17(土) 13:25:36.07

EF Coreはまだまだみたいだから、とりあえずDapperで使えればいいや

**デフォルトの名無しさん** · 2018/02/23(金) 17:48:57.83

Kestrelのhttp2対応ってどの辺までできたのかしら？

**デフォルトの名無しさん** · 2018/02/27(火) 18:35:57.46

kestrel(というかasp.net core)がまだPush対応されてなくて無事死亡

**デフォルトの名無しさん** · 2018/02/28(水) 09:17:05.58

2.1 previewきたな

**デフォルトの名無しさん** · 2018/02/28(水) 13:23:08.67

goを触ってからだとビルドとかパッケージ管理とかの遅さが気になって使えない

**デフォルトの名無しさん** · 2018/02/28(水) 13:31:53.66

比較すべき対象じゃないから問題ない

**デフォルトの名無しさん** · 2018/03/07(水) 10:21:49.84

warn: Microsoft.AspNetCore.Server.Kestrel[22]
Heartbeat too longer than "00:00:01" at "03/07/2018 10:00:00 +00:00"

こんな警告が出るんだけどどういう意味？
解決方法教えて

**デフォルトの名無しさん** · 2018/03/07(水) 14:04:09.79

threadがデッドロックしてるとかしてない？

**デフォルトの名無しさん** · 2018/03/07(水) 14:16:35.99

それか、ブロッキングコード書きまくってるか

**デフォルトの名無しさん** · 2018/03/07(水) 20:39:20.58

>>421-422
色々と洗ってみたけどダメでした
再現性もなくログには不定期に出力されてるからKestrel側の問題なのかな
でもありがとう

**デフォルトの名無しさん** · 2018/03/08(木) 08:01:24.98

>>423
そっかあ。
個人的に気になるインシデントなので、
もし進展があって気が向いたら書き込んでくれると嬉しいです。

**デフォルトの名無しさん** · 2018/03/14(水) 05:54:49.37

VS2017で、.net core 2.0 をつかっていたんだけど、
2.1 SDK を入れてみた。
でも、プロジェウト作成で、選べない。
どうすればいい？

**デフォルトの名無しさん** · 2018/03/14(水) 07:07:42.04

先ずは全裸になります

**デフォルトの名無しさん** · 2018/03/14(水) 07:09:18.85

>>425
自己レス

https://github.com/dotnet/core/issues/1131

使えないぽいな

**デフォルトの名無しさん** · 2018/03/14(水) 07:10:01.79

>>426
無理、外にいるから