文書の過去の版を表示しています。
目次
dotNET
user.configの保存先
OS | フォルダ |
---|---|
Vista,Windows7~ | C:\Users\(ユーザ名)\AppData\Local\<CompanyName>\<ProductName>\<ProductVersion>\user.config |
XP | C:\Documents and Settings\(ユーザ名)\Local Settings\Application Data\<CompanyName>\<ProductName>\<ProductVersion>\user.config |
Windowsのディレクトリ構成ガイドライン
ガイドライン抜粋
Program Files、ユーザー固有・アプリケーション共有データ
- C:\Program Files
プログラム、ソフトウェアコンポーネント置き場
通常ユーザーはこの場所に書き込み権を持たないため、ユーザーデータやアプリケーションデータはここへ置くべきでない。
- C:\ProgramData:
コンピューター上のすべてのユーザーが共有するアプリケーションデータ置き場
C:\Users\<ユーザー名>\AppData:
ユーザー固有のアプリケーションデータ置き場
AppData以下はさらに階層構造を持つ
- C:\Uses\<ユーザー名>\AppData\Roaming
コンピュータに依存しないユーザー固有のアプリケーションデータ置き場
アプリケーションデータのうち、ユーザーカスタマイズ情報などで、ユーザーの操作を伴い変更するもの
- C:\Uses\<ユーザー名>\AppData\Local
このコンピュータに固有のユーザー固有のアプリケーションデータ置き場
アプリケーションデータのうち、一時的で破棄されてもアプリケーション動作に支障のないもの(ログ、デバッグ情報など)
コンピュータに依存しないユーザー固有のアプリケーションデータでも、ユーザーの操作なしに再生成できるデータ(ユーザーが作成するカスタマイズ情報や設定情報は含まない)
- C:\Users\<ユーザー名>\AppData\LocalLow
ユーザー固有の特権(管理者権限)なしに扱えるアプリケーションデータ
Environment.SpecialFolder 列挙体のメンバ | 環境変数名 | 場所の例 |
---|---|---|
UserProfile | %USERPROFILE% | C:\Users\<ユーザー名>\ |
ApplicationData | %APPDATA% | C:\Users\<ユーザー名>\AppData\Roaming |
なし | %TEMP% | C:\Users\<ユーザー名>\AppData\Local\Temp |
LocalApplicationData | %LOCALAPPDATA% | C:\Users\<ユーザー名>\AppData\Local |
なし(配下はある) | %PUBLIC% | C:\Users\Public |
CommonApplicationData | %PROGRAMDATA% | C:\ProgramData |
初回起動が遅い
別の.NETアプリケーションが既に動作していれば起動は速いがPC起動時など遅い。
理由は、.NET Framework 自体のロードをファイルシステム・キャッシュ上に乗せるためで「コールド スタート」と呼ばれる、別の.NETアプリケーションが既に動作していると「ウォーム スタート」となる。
ウォーム スタートは、主要なCLRコンポーネント用のページの殆どが既にメモリに読み込まれているときに発生し、貴重なディスクアクセス時間が節約されます。このため、マネージ アプリケーションを再度実行すると、初回よりも短い時間で起動します。
アプリケーションの起動時間
起動を速くするににプリコンパイルする「Ngen.exe」を使用する方法がある。インストール時にカスタムアクションでNgen.exeでプリコンパイルするといった手法もある。
チュートリアル : カスタム動作を使用して、インストール中にアセンブリをプリコンパイルする
但しプリコンパイルの効果は永続的ではなく、.NET Frameworkなどのバージョンが変わったりなどの条件によって効果が消えてしまう。
ネイティブ イメージ ジェネレータ (Ngen.exe)
他にも64bit OS上だとJITのパフォーマンスが悪くなるとの報告がある。x86で作成すると良いらしい。
アプリ起動に限ればクアントアプリは今のところx86ターゲットのほうが良いのか?
Windows上で電子署名されたロードモジュールを実行すると10秒以上起動にかかることがあるとのことで、対処方法としてアプリケーション構成設定で「generatePublisherEvidence」を「False」に設定する。
Windows上で電子署名されたロードモジュールを実行するとなーんか遅い?という話
Windows10では「高速スタートアップ」機能があり、パソコンの起動を速くするためシャットダウン時にメモリやCPUなどの状態を保存しておくようになっている。これにより初回の初回起動以外は速くなる。
厳密名による特定バージョンの縛りについて
特定バージョンについては厳密名と同じで、アセンブリファイルの参照プロパティで確認できます。
特定バージョンを設定するためには、以下の2つの条件を満たす必要があります。
- 参照するアセンブリファイルに厳密名が設定されている。
- 参照するアセンブリファイルがGACに登録済み
特定バージョンがTrueの場合、参照設定しているアセンブリのバージョンが一致しないとコンパイル時にエラーや警告が発生します。
ClickOnceの発行
オフラインの必須コンポーネント
ブートストラップファイルの場所
VS2008 | C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages |
---|---|
VS2010 | C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages |
VS2013 | C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Packages |
VS2015 | C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper\Packages |
VS2017 | C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages |
バージョン管理
ClickOnceでは、アセンブリバージョンで設定ファイル(user.cofig)が作成されるので、アセンブリバージョンを変更してしまうと、前バージョンの設定を引き継げません。ってことが発覚!
ClickOnceを使う場合は、発行バージョンで管理するってことになります。
よって、アセンブリバージョンとファイルバージョンは1.0.0.0のままにしておく。
既にインスール済みでインスールできない
アンインストール後に再度インスールしようとした場合、ClickOnceのエラー詳細にて既にインスール済みと判断される。
Setupがゴミ箱にある場合でも、既にインスール済み扱いになってしまうので、対応としてゴミ箱から削除する。
クラッシュする場合
.NET4.0以降はメモリアクセス違反「AccessViolationException」等になるとアプリケーションが終了する。
.NET Framework 4 以降で挙動が変更されたことにはそれなりに理由があります。というのも、すでにメモリアクセス違反が発生してしまったものを復旧しつつ挙動させることは極めて困難だということです。保証できない状態になっているのを無視してアプリケーションを継続してしまう場合がほとんどなので、それぐらいならアプリケーションをクラッシュさせる方がよほどマシとの考えでしょう。中途半端になって 2 次災害を引き起こすよりも突然の死を選ぶ方が安全である、と。
AccessViolationExceptionを捕捉できるようにする
構成ファイル (*.config) に <legacyCorruptedStateExceptionsPolicy> 要素を入れることで解決できます。
- app.config
<configuration> <runtime> <legacyCorruptedStateExceptionsPolicy enabled="true" /> </runtime> </configuration>
Tips
staticクラス
クラス自体を static と宣言することで、インスタンス作成を禁止し、static 宣言したクラスのインスタンスが複数作成できないようにできます。
- staticクラスは継承元として使えず、ほかのクラスが継承することもできません。
- プロパティのセットはメソッドの記述が必要