技術メモ

IIS Express 64bitでのデバッグ

ASP.NETの開発で、64bit指定でコンパイルするとデバッグに失敗するのを回避するために、
Webサーバー側の実行環境も、64bitにする必要があるみたい。
方法としては、IISサーバーを利用する手が、一般的なようだけど、
Visual Studio 2012(以後、VS)から、IIS Express(IIS 8 Express)が64bitをサポートしているもよう
ただし、普通にVS上で、IIS Expressをデバッグ実行するとOSが64bit環境でも、32bitのプログラムが起動する。

VSから、IIS Expressの64bitを起動するには、以下のレジストリを定義を追加することで、
64bit側が起動するようになる。

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\WebProjects]
"Use64BitIISExpress"=dword:00000001

尚、MS曰く実行保証はないみたい

実行環境
Windows 8 64bit
Visual Studio 2012.2

grep検索

ex)
grep -R --include="*.cpp" "xxxx" .

WPFのDataGridで、追加モードをOFFにする注意点

WPFでDataGridを使用する時、追加モードをOFFにして編集モード状態にしたい場合注意が必要
通常、追加モードにする場合、CanUserAddRowsをTrueにすることで、追加レコードを非表示に
できるが、デフォルトがTrueであるため、XAMLで定義する場合、明示的にCanUserAddRowsをFalse
にする必要がある。

このあたりもSilverightと異なる。

VPN接続時、ルーティングとリモートアクセスが応答しなくなる

ISA2006におけるVPN（L2TP/IPsec）環境において、クライアントから１回は接続できるが、再接続を行うと失敗する現象に関しての回避方法

確認できた問題が発生するＯＳは、WindowsXP、WindowsVista。
Windows7では、正常に動作している。

発生要因は、VPN接続時に使用しているWindows2003のルーティングとリモートアクセスのサービスで、
１回目の接続時、ルーティングとリモートアクセスの管理画面は、応答できなくなり、サービス自身も
再起動ができない状態に落ちおり、OSを再起動するしか復旧できない。

原因としては、更新プログラムのKB2509553のパッチが悪さをしているようで、このパッチをOSから
アンインストールすることで、今回の現象からは回避できる。
ただし、このパッチのセキュリティ問題はのこったままになるので、今後対策を講じる必要はあるかも

外部jarを利用時はまったこと

ターゲット
android2.1update1(XPERIA)
Bluetoothを接続した、とあるデバイスの制御アプリの開発
（デバイス制御用にjarファイルが提供されている）

開発環境
eclipse3.7x

まず、行ったことは外部jarとして、プロジェクトに登録
「ビルド・パス構成」-「ライブラリー」で、「外部JARの追加」で登録
これで、実行したところ例外処理が発生する

次に、一旦プロジェクトフォルダー内に、JARファイルをドラッグアンドドロップでコピーしてから、
「Jar追加」（内部JARとして追加）してみたが、これでもだめ、

次に、「順序およびエクスポート」で、該当のJARをチェックしてみる。
でも、これでもだめ。

最後に、もう一度JARファイルを現在コピーされているフォルダーと異なる個所にドラッグアンドドロップしたあとに
再度、当初コピーしたJARへ先ほどドラッグアンドドロップしたファイルを上書き移動する。

これで、実行してみると、プログラムが正常に動作するようになった。

現段階においても、なぜこれで動作するようになったか不明・・・・なぜ？？
ただし、「順序およびエクスポート」でチェックしたのち、JARを上書きすると動作するのは、
別のプロジェクトでも確認したので、たぶん必要なステップと思われる。

ちなみに、正常に動作したあと、「順序およびエクスポート」のチェックをはずしても
以後、正常に動作している？？？

ファイルシステムタイプの確認

マウントされているファイルタイプを確認する

df -T

yumの確認

yumのインストールされたパッケージを確認できる
#yum list all

また、実際にどこからロードするかは、先頭部分をURLが定義されている
* base: ftp.nara.wide.ad.jp
* extras: ftp.nara.wide.ad.jp
* updates: ftp.iij.ad.jp

centos6 日本語化

日本語関連パッケージをインストール
# yum -y groupinstall "Japanese Support"

centos5とはパッケージが違う？

日本語に変更
# vi /etc/sysconfig/i18n
LANG="ja_JP.UTF-8"

#pragmaによるライブラリリンク

たとえば、WINSOCK2のDLLをリンクしたい場合、

#pragma comment(lib, "WS2_32.LIB")

VisualStudio2010でためしました
ちなみに、インポートライブラリしかためしてません

VisualStudio2010 依存関係の取り扱い

VisualStudio2010において、依存関係の取り扱いが2008以前と異なる
(今回は、SP1で確認してます)

たとえば、プロジェクト内にAスタティックライブラリーとBアプリケーション(EXE,DLLなど）
のサブプロジェクト登録して、BアプリケーションにAスタティックライブラリをリンクする場合、

2008までは、プロジェクト依存関係を定義するだけで、Bアプリケーションは、Aスタティックライブラリ
を自動的にリンクできたが、2010からはこれでは、リンクされない。

Bアプリケーションで、Aスタティックライブラリを自動リンクさせる場合、Bアプリケーションのプロパティを
を開き、共通プロパティより、「新しい参照の追加」で、Aスタティックライブラリのサブプロジェクトを追加する
必要がある。
ここで、追加すると、プロジェクト依存関係も合わせて設定される。

とりあえず、今まで設定でなくこんな方法になったかは、リンクの設定を細かく設定できるとして、
納得するとしても、なぜ中途半端な、プロジェクト依存関係の手順が残されているのかは不明である。

さらに、あたまを悩ますのは、
たとえば、Aスタティックライブラリを、あらたに、AAスタティックライブラリのサブプロジェクトを作成して、
Aスタティックライブラリと結合させる場合、今回の方法で「新しい参照の追加」をAスタティックライブラリ
から結合させたところ、依存関係は成立するが、デフォルトでは結合されない。

結合させる場合、詳細設定であるプロジェクト参照のプロパティの項目にある「ライブラリ依存関係のリンク」
をTrueにする必要がある（BアプリケーションとAスタティックライブラリとの参照追加では、デフォルトTrueになっているのに、スタティックライブラリからの追加では、デフォルトFalseになる）。
そのため、BアプリケーションにAスタティックライブラリを追加しただけでは、AAスタティックライブラリーのオブジェクトは、参照できず、リンクエラーになる。

補足だが、AとAAプロジェクトを「ライブラリ依存関係のリンク」でTrueにしなくても、
Bアプリケーションをリビルドすれば、リンクは成功した。
なぜ？これは私だけ？？

以上、C++を使用する場合、ほとんど罠に近いと思われるが、
開発言語の主体が、.NET側になったための弊害なのだろうか？