箱庭ハーブblog

7年目プログラマの趣味の小部屋

ASP.NET知識の供養

Evernoteをあさってたら出てきたので…

「構成にエラーがあります。説明: この要求を処理するために必要な構成ファイルの処理中にエラーが発生しました。以下のエラーの詳細を確認し、構成ファイルに変更を加えてください。 パーサー エラー メッセージ: アプリケーション レベルを超えて allowDefinition='MachineToApplication' として登録されているセクションを使うことはできません。このエラーは、仮想ディレクトリが IIS でアプリケーションとして構成されなかった場合に発生します。」
原因:
Webサーバに配置したフォルダを、Webアプリケーションとして登録していない。WebサーバのIISマネージャから該当するフォルダを右クリックし、アプリケーションの作成を行う


「クライアントは 'text/html; charset=shift_jis' の応答のコンテンツ タイプを見つけましたが、'text/xml' が必要です。要求は以下のエラーにより失敗しました。」
原因:
Webアプリケーションが別のWebアプリケーションやサービスを参照しようとして、それがWebアプリケーションとして登録されていない。WebアプリケーションのサブフォルダにWebサービスがある場合などでよくやる過ち。WebサーバのIISマネージャから該当するフォルダを右クリックし、アプリケーションの作成を行う


IEで開いたとき、強制的に互換表示になる
原因:
1、IEの設定で、「互換表示でイントラネットサイトを表示する」がチェックされている(デフォルトオン)
2、htmlのmeta要素に指定されている
3、web.configのHTTPレスポンス
4、IISの設定

List<T>、配列、IEnumerableとキャスト

Array、IEnumerable<T>、Linq

ども。

C#では、配列とList<T>ではキャストの挙動が違います。
object[] a = new Type[0]; // OK
List<object> b = new List<Type>(); // NG

List<T>の要素型をアップキャストできないんですね。
ちなみに、IEnumerable<T>は明示的なキャストで可能ですが、
実体が配列だった時だけ成功して、List<T>だった場合は例外が発生します。

で、どうしてもキャストしたい場合は、シャロウコピーなりなんなりするわけですが、
System.LinqのCast<T>()でシャロウコピーできます。
List<object> b = (new List<Type>()).Cast<object>(); // OK
このCast<T>()、配列ならキャスト、それ以外ならシャロウコピーします。

VisualStudio2017をインストールしよう!

VISUALSTUDIO2017、Visualstudio2017、visualstudio2017


ダウンロード!

ども

Visual Studio 2017が正式リリースされたので、さっそくインストールしたい!
というわけで、サクッとダウンロードして、入れます。



全チェックすると、50GBになります…!?

2015よりさらに多くなったなオイ!
通常のBlu-rayに収まりきらんぞ!?

Unityなんかもインストーラの選択肢に入って、
だいぶサードパーティに優しくなりましたね。
(正直、光とSSD両方の環境がそろってないと、
インストールだけで2時間とかかかるんじゃなかろうか…)

2015の時は調子に乗って全部入れたけど、
今回は必要そうなものだけ入れる方針で19GB。

それでも19GBか…



自分は15分ぐらいでインストールが終わりました。再起動



再起動後にVisualStudio2017を起動すれば、初回画面に。


あとはMS開発アカウントでサインインすれば・・・



VisualStudioの初期画面!(まだ初期設定中!)


 
初期設定が終わると、ダークがデフォルトになります。


とりあえず、ここまででVSのインストールは完了。
Unityエディタからの紐づけも、2017に変えておきましょう。



テラシュールさんのところにやり方が載ってます。
【Unity】Visual Studio 2017 (RC)をUnityで使う



Browseした先は、こんな感じ。



設定が成功すると、Visual Studio2017になります。


Unityエディタから開くかどうか確認!
適当にスクリプトをダブルクリックして…



セキュリティが聞かれるので許可



開きました!なんか2015の時よりデフォルト設定がすっきりしてる!

今回はRC版などには手を付けられてなかったですが、
次のVisualstudioはβリリースから触りたいところ!

Visual Studio #Region の使い道

VISUALSTUDIO、VisualStudio、Visualstudio、visualstudio
#Regionディレクティブ、#regionディレクティブ

ども、お疲れ様です
#Regionディレクティブの使い道、みなさんどうされてますでしょうか
自分はここ1年間で、次の使い方にほぼ確定してまいりました。

1、ある関数とそこからのみ呼ばれる関数をひとまとめにする

業務アプリを作っていると、実質的に1つのメソッドだが、500~1000行になることが往々に在ります。
その場合には、以下の3つのアプローチが考えられます
1、1000行のファットなメソッドを鎮座させる
2、純粋なサブルーチンとして、メソッドをいくつもの関数に分割する
3、クラスが実装できそうなレベルなら、関数の中身でクラス設計をしてみる
3番は小さなプログラムを作るに等しく、(元のメソッド=要求仕様。クラス分割=詳細設計、と考えられる)
労力も自由度も高すぎます
僕としては1番を正しく読める自信もないので避けたいところ
つまり僕のスキルレベルでは2番以外に選択肢がない訳で、文脈と意味単位で適当に分割します
こうすると、実際には1ヶ所からしか呼ばれない関数というものが、大量に出来ます
(経験上1つのメソッドから5、6個の関数が出来上がるのはよく在る)

こんなに、わさわさ関数が在るとうるさいので、これらを#Regionで囲ってしまうとすっきりします。
例えばこんな感じ
#Region "  Private Sub CalBodyValueAll() と その従属関数"
  Private Sub CalBodyValueAll()
    ...
  End Sub
  Private Sub CalBodyValue()
    ...
  End Sub
  Private Function CopyDatasetDataShow(ByVal rsFrom As DataSetHoge, _
ByVal rsTo As DataSetHoge, _
ByVal incomekbn As String)  As Boolean
    ...
  End Function
  ...
# End Region

シンプルですが、中々使いやすい方法です
独学でC#をやっていた頃は、サブルーチンになる部分を#regionで関数に見せかける書き方をしてました
(なお、VB.NETではメソッド内に#Regionはかけないのでこの方法は実践できません)
ですが、先に例に挙げた方法のほうが分かりやすいと思います
インデントをネストせずにローカル変数の局所化が出来るので。



2、PublicFunctionsなど、静的関数群クラス内の分類分け

これはもう、それ以上でもそれ以下でもなく。
基本的に同じ分類の汎用関数は予め名前の先頭部分をあわせたりしますが、関数の数が50、100となってくると探すだけで大変だったりするので、#Regionで括ります




で、結局?

正直なところ、#Regionのこの使い方は他の俺俺コーディングルールと密接に関わっているため、
万人向けかどうかは分かりません
とりあえず、一応、俺俺コーディングルールも載せておきます

俺俺コーディングルール

1、メンバの宣言順序は原則として次の順番で宣言する
また、各メンバ間は必ず1行空ける
但しプロパティの元となるフィールドは、プロパティの直前に空行を空けずに記述する
また、在る関数からのみ呼ばれる関数は、その関数のすぐ下に空行を空けずに記述する
 1、Public Shared(public static)
 2、private shared(priavte static)
 3、Public Property
 4、Public Method
 5、Private Property
 6、Overridesメンバ
 6、コンストラクタ、Form.Loadイベントハンドラ、Shownイベントハンドラ
 7、Private Method(イベントハンドラ)
 8、Private Method(非イベントハンドラ)
 
2、余計なコメントは基本的にかかない。関数名で役割を適切に体現する
 主に修正日付や修正内容などを簡潔に書くこととして使用する
 また、ドキュメントコメントはよほど複雑でない限り、使わない(折りたたむと読めないため)

3、自分は、Ctrl+M、Oを多用する

4、リファクタリングするときは、絶対に修正は行なわない
リファクタリング時はリファクタリングのみ行ない、チェックインする

補足、 Public/Private、Method/Propety、Static/instanceで分けない理由

経験上、余り効果的でないです
というよりも、意味が余りないです
なぜなら、少なくともPublicメンバは普通に記述していると頭に書くはずで、
PrivateメンバをPublicに書き換えた場合も、その時点で移動させる人がほとんどでしょう
つまりPublicメンバが上にいることは保障されています
そして、#Regionは、基本的に邪魔です
なぜなら1回開かないと中が見れません。面倒です
メソッドまで折りたたんでいた場合、2回開かないとコードを見れないことになります。
めんどいです。

そもそも各アクセサやメンバ種ごとに分けたいなら、
まず分けた上で境目に下記のように1行コメントを書けば十分で。
' ↑ Public  ↓ Private

Publicメンバが多すぎてPrivateメンバを見るのが面倒だというなら、
そもそもそんなにPublicメンバが多いことが問題なわけで。
(Publicプロパティが10個もいたら、ほとんどの場合クラス分割したほうが見通しがよくなります)
(但し構造体ライクなクラスを除く。しかし構造体ライクなクラスは単純な構造のはず)

まとめ

#Regionは基本的に自分以外で使ってるのをほとんど見たことがないです
が、ファットメソッドに対して関数分割をやる人は、積極的に使っていくといいかもしれません
それ以外の方法でもいい使い道があるなら、割と積極的に使っていける機能だと思います
但し、ソースを見るのが1手間余計にかかるため、へんな使い方はお勧めできません

結論:#Regionは、使い方を誤らなければ便利(なはず)

Windowsアプリケーション コントロール数 デスクトップヒープ

WINDOWS、Windows、windows
3MB
コントロール数、System.Windows.Forms.Control
デスクトップヒープ

お疲れ様です、今回はOSの呪縛について

あるデータの一覧を表示したい
こんな時にはDataGridViewで作りますが、場合によってはコレでは満たせない場合があります
(1つのデータが1行で表せないときなど)

解決策
 カスタムコントロールを作り、必要な項目を配置
 Forループでぶん回して行数だけ、カスタムコントロールを配置する



【問題点】
こんな作りにしていると、一覧を何度かリロードしたり、一定数以上ロードすると落ちる
前者はデスクトップヒープのメモリがすぐ解放されないので起きる
後者はデスクトップヒープのメモリを1度で使い切った

どっちにしてもデスクトップヒープを使い切ると起きるわけです
前者はガベージコレクションを明示的に走らせれば解決らしいですが、
後者は無理です



【原因の詳細】
デスクトップヒープ
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B9%E3%82%AF%E3%83%88%E3%83%83%E3%83%97%E3%83%92%E3%83%BC%E3%83%97

@IT insider.NETの質問スレッド
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=28552&forum=7

仕様です。しかも大体下記のような状況のため、逐次読み込みや部分表示を実装するしかない
1、デスクトップヒープは1セッション3MB。約15000個のコントロールを管理
2、3000KB ÷ 15000個 ≒ 0.2KB?1コントロール200Byte消耗?
3、デスクトップヒープを増やすのはやめたほうがよい。OSが不安定になる

補足。用語。http://technet.microsoft.com/ja-jp/windows/mark_16.aspx
セッション:≒ログインしているユーザ。サーバOSなら複数がありうるため
プロセス:実行中のプログラムの単位。必ず誰かのセッションに所属する
ウィンドウマネージャ:描画内容全てを管理している大元の仕組み
デスクトップ(内部用語):普段意味するデスクトップフォルダのことではない
  ウィンドウマネージャが管理する単位。1人のユーザが4つまでらしい。よくわからん
ウィンドウステーション:1セッションに1つのメインと任意のサブを持つ。
 メインとなるステーションはセッションと入出力デバイスの紐付けを行なう。
 サブは、例えば各Windowsサービスごとに作られる(描画不要なプロセスのため)


というわけで、コントロールは配置し過ぎないのが吉

フリーエリア

takemori
Twitter : @takemori_kondo

1. Unityと戯れてます
2. Cake3は劣化じゃないRails

iOS
coming soon...

Windows
Html Editor - Nazuna
Managed DirectX サンプル集

beginning since
2006.08.17
renewaled on
2011.06.03

最新コメント

[2018/11/20 スーパーコピーブランド専門店]
[2013/06/14 ミューネ]
[2012/08/30 ノートPC]