VisualStudioからSqlServerへ接続する

開発機のクライアントにVisualStudioが入っており、DBサーバーにSQLServerが入っている、という環境でクライアントのVisualStudioからDBサーバー上のSQLServerデータベースへ接続する方法をまとめました。

・準備
・DBサーバーにpingが通るか確認する。
例えばDBサーバーが「DBSERVER01」であった場合そこにpingを打って通るかどうか確認しておく
・サービスが開始しているか確認する。
DBサーバー上でSQLServerのサービスが稼動しているか確認する

・サーバー側設定
①SqlServer構成の設定
SqlServer Configuration Manager(SqlServerxxxx　＞　構成ツールから起動)を起動し、SqlServerネットワークの構成　＞　(インスタンス名)のプロトコルで、TCP/IPが無効になっていれば有効にする(※なお、後述するが名前付きパイプはこの時点では無効にしておいたほうがいい)。
この際、TCP/IPで右クリック＞プロパティから、IPAllのセクションでTCPポート1433を設定しておく。

運がよければこれだけで接続可能になる。VisualStudioのサーバーエクスプローラーから、サーバー名、ユーザー/パスワード、データベース名を指定し、テスト接続でOＫが出ればとりあえず安心(サーバー側は・・・)

②WindowsFireWallの設定解除
うまくいかない場合、WindowsFireWallの設定を見る。有効になっている場合、SqlServer用のポート1433を開ける必要がある。
Windowsファイアウォールから例外のタブへ行き、ポートの追加から1433を登録する(名前は何でも良い)。追加した名前にチェックを入れ、再度トライ。
(可能なら再起動したほうが良いかもしれない)

③SQL Server Browserを起動する（別名の設定を使用している場合に必要？）
いろいろなサイトで起動させるべきと書いてあるが、必要なかった(2008R2では少なくとも)。そのものの内容を見ると、別名を使用している場合に必要なのではないか。。。という気がする。
名前付きパイプの設定を有効にする場合、セットで有効化するとよいと思われる(未検証)。ただ、この場合別名でアクセスしないとエラーになるので注意。

④データベースがリモートアクセス可能になっているか確認する
デフォルトチェックが入っているので、ここがオフになっていることは余りないが、、、
サーバーのプロパティ＞接続から「このサーバーへのリモートアクセスを許可する」にチェックが入っていることを確認する。


・クライアント側設定
基本的にサーバー側に接続できたらＯＫなことが多いが、ここでもヤマがあることがある。
Oracleなど他DBサーバー同様、クライアント用の設定がクライアントにインストールされている必要があるのだ。
具体的には下記参照。

Microsoft.SqlServer.Management.Sdk.Sfcエラー

なお、ダウンロード先のFeature Packのサイトは一見いつもの「ダウンロード」を押しても何もインストールされない(テキストだがhtmのようなファイルが落ちてくる)。ナメとんのか、という気持ちを抑えて下のほうに行くと各種パッケージをダウンロードできるようになっているのでご注意を。

必要なのは下記モジュール。SQLServer以外のものもしこたまあって検索するのが激しく面倒だが、以下テキストは実際のサイトの語尾から取ったので検索に使えると思う。


・Native Client
・SQL Server システム CLR 型
・共有管理オブジェクト


これで晴れてVisualStudioからアクセスできるようになったはずだ。

SqlServer データベースを作成する

SqlServerはインストールできた。で、その後データベースを作成するには・・・？の手順をまとめました。

・前提
以下の要件を満たすデータベースを作成します。
・データベース名はSQLTEST
・このデータベースへのアクセスに使用するユーザーはsql
・スキーマもsqlとする(sql.testtableといったようにオブジェクトを管理する)

・作成
①データベースを作成する
システム管理者権限(saユーザー)でデータベースSQLTESTを作成します。
これは新しいデータベースの作成で難なく可能

②ログインを作成する
セキュリティ＞ログインから、データベースアクセス用ユーザーsqlを作成する。

③スキーマを作成する
データベースSQLTESTで、セキュリティ＞スキーマからスキーマsqlを作成する。
※SQLServerでは、Oracleと異なりユーザーとスキーマはイコールではないので別々に作る必要がある(これが良いか悪いかは・・・)

④ユーザーを作成する
データベースSQLTESTで、セキュリティ＞ユーザーからユーザーsqlを作成する。
ここで、規定のスキーマに③で作成したスキーマを指定、ユーザーが所有するスキーマで③で作成したスキーマにチェック
※SQLServerでは、ログイン(認証情報)とデータベースユーザーは別なのだ。

⑤ユーザーに権限を付与する
①で作成したデータベース(SQLTEST)で右クリック、データベースのプロパティ>権限を選択し必要な権限を割り当てる。

⑥ログインの設定の見直し
ログインは、作ったままだと既定のユーザー/スキーマがdboになっている(ログインのプロパティ、ユーザーマッピングで確認)。
ここで、④で作成したユーザー(sql)を設定しておく。


以上で終了となる。なお、ここで作成したユーザーsqlはシステム管理者/データベース所有者ではないため、このユーザーでテーブルなどを作る時逐一メッセージが出る(権限を持っているかは関係ない)。

実際はsaユーザーでテーブルを作ればよいのだが、テーブルなどのオブジェクト作成もsqlで行う場合このメッセージはかなり邪魔になる。
そのため、こうした場合はsqlユーザーのデータベースロールのメンバーシップでdbownerを割り当てる(ただ、セキュリティ上言うまでもなくよろしくないので、この場合はデータベース開発用に使用するユーザーsqlに加え、システム側から使うselect用ユーザー(sqlselect)などを作成した方が良いだろう)

.NET開発 SAPとの接続(SAP .NET Connector 3.0)

.NETの開発で、SAPとの連携について検証を行ったためそれをまとめます。

・コネクタ用意

SAP接続用のコネクタをダウンロードする(ダウンロードには登録が必要)。

SAP Service Market Placeからダウンロード。32bit版と64bit版があるので注意。

SAP ServiceMarketPlace CONNECTORS

特徴として、SAP GUI(具体的にはlibrfc.dll)への依存がなくなっていることと、SAP側のファンクションとの同期が不要になっている。

・開発準備

・共通

これはSAPコネクタに限ったことではない(よう？)だが、configファイルを記述する際、configSectionsが先頭にこないとビルド時にエラーになる(WPFで確認)。この点に注意。

開発に当たっては、通常のdll同様参照を通しておく(なぜかlibicudecnumber.dllにだけ参照が通らないが、特に不都合はない)。

・クライアントアプリ開発(VB.NET、WPFなど)の場合の注意点

ターゲットのフレームワークにClient Profile版(※)を設定してはならない(デフォルトClientProfileなので注意)。これは、SAPコネクタ(sapnco)でSystem.Webに依存している部分があり、これがClientProfile版にはないためである。

コンパイル > 詳細コンパイルオプション > 対象のフレームワークで確認する。

※Client Profileとは、.NET Frameworkのライト版である。.NET Frameworkは重くてインストールに失敗しやすくてこれインストールしないとアプリは使えません、となると非常にやるせない気持ちになってしまう。これを解消するために、大体の必須機能が入ったライト版があり、それがClient Profileである。

・Web開発(ASP.NET)の場合

まず、Webサーバーに「Microsoft Visual C++ 2010 再頒布可能パッケージ」が入っているか確認しよう(というか、普通入っていない)。これがないと、参照を通してBinフォルダに入れているにもかかわらずrscp4n.dllが見つかりませんというエラーが出る。

Microsoft Visual C++ 2010 再頒布可能パッケージ (x86)

それと、前述の通りSAPコネクタには32bit版と64bit版があるため、サーバーが64bitの場合は注意が必要。

・開発

準備の道のりに比べたらたやすいものである。

サンプルのファイル(StepByStepClient)に丁寧にコードが書いてるので、それを元に開発すればすぐにできる。

注意点としては、SAP側でRFC呼び出し可能として登録されている汎用モジュールしか呼び出せない点である(クラスのメソッドなどは不可、IDocにも非対応)。

具体的には、SAP上のテーブルTFDIRで更新モードが「R」になっているものが呼び出し可能。

なお、ここまで書いておいて難だが、今後のSAPとの連携の流れとしてはWebサービスが主流になる。そのため、SAP側がWebサービスに対応している(6.0以降、具体的にはNetWeaverならOK？)なら、そちらで連携した方がコネクタいらずで簡単である。
最近ではSAP NetWeaver GatewayというRESTライクな形式でのアクセスを可能にするコンポーネントも出ている。そのため、理解ある環境ならこの流れに乗った方がいい(Webサービスを使いたい→その為の作業工数は、カネはどこから出るんだね→orz　ということも多いので、その場合は本記事を参照されたし)。

参考

・sap.net connector 3.0 example

・Could not load file or assembly ‘rscp4n.dll’ or ・・・

 特にC++ランタイムへの依存の発見はスーパープレイだと思う。Eric Laschingerさんは本当にすごい人だ。

ASP.NET OracleProvidersによるフォーム認証がIIS上でうまくいかない

ASP.NETでは、各種認証機能がデフォルトで実装されている。とはいえそれはSqlServer用なので、Oracleで使用する場合はOracleProvidersをインストールする必要がある。

このインストール方法と使用方法についてはOracleから詳しいガイドが提供されているが、問題なのはこの通りにやった場合開発サーバー上ではうまく動くがIIS上ではうまく動かないということだ(後述するが、仮想パスの設定によってはうまく動く場合もある)。

Oracleから提供されているガイド：OracleR Database 2日で.NET開発者ガイド(11g R2)

上記ガイドの通りに設定しても、IIS上では永久にログインできない。IIS上でもまともに動くようにするには、web.configに設定されている各認証要素(membership・profile・roleManager)の設定を変更する必要がある。

具体的には、provider要素内のapplicationNameにサイト名を指定する。それと、ハッシュアルゴリズムにSHA1を設定しておく(これは必須かは分からない)。

<membership defaultProvider="SomeOracleMembershipProvider" hashAlgorithmType="SHA1" >

<providers>

<clear/>

<add name="SomeOracleMembershipProvider" type="Oracle.Web.Security.OracleMembershipProvider, Oracle.Web, Version=2.111.5.10, Culture=neutral, PublicKeyToken=89b483f429c47342" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" connectionStringName="ConnectionString" applicationName="/webSite" />

</providers>

</membership>

認証情報はサイト名（上記の場合webSite）で管理されている。そして、これは仮想パスによって検索されるようだ。

そのため、仮想パスが/webSiteであるならうまくいくが(開発サーバーでの起動はこれに該当)、サーバー上に配置して仮想パスがこれとずれた場合(app/webSiteなど)、認証情報が検索できずうまくいかないという現象が起こるらしい。

これを回避するには、明示的にアプリケーション名を指定しそちらで認証情報を取得するようにする・・・ということのようだ。

参考サイト

Always set the "applicationName" property when configuring ASP.NET 2.0 Membership and other Providers

OracleMembershipProvider Form Authentication

これを発見するのに丸一日費やした。ASP.NET＋Oracleはかくも茨の道なのか・・・

ASP.NET Oracle Providers for ASP.NET設定時にconnectionStringでエラー

Oracle Providers for ASP.NETの設定時に、接続文字列関連のエラーが発生する場合、以下点をチェックする。

１．サーバー以外に、ローカルのmachine.configを編集しているか
通常はローカルのVisualStudioからASP.NETの構成を参照するので、ローカルのmachine.configを修正しないとまずアクセスが出来ない。※これとは別に、当然サーバー上の設定も必要。


２．.NETフレームワークのバージョンは適切か
machine.configに該当の設定があるのは2.0と4.0の二つある。マニュアル上では2.0で紹介されているが、.NET Framework4.0を入れている場合そちらの修正が必要

参考ドキュメント(P104あたり)
Oracle Database 2日で.NET開発者ガイド(11g R2)

Oracle DBConsoleが起動しない場合の対処法

1.状況確認用コマンド
emctl status dbconsole

2.起動用コマンド
emctl start dbconsole　停止の場合startをstopに

3.リポジトリの再構築(方法が2つある？)
1.構成情報を再構築？
set oracle_sid=XXXXX(SID)
emca -deconfig dbcontrol db
emca -config dbcontrol db

2.構成情報を削除/再作成(1がうまくいかなかったときに試すと良い。これまでの設定が消えるらしいので要注意)
emca -deconfig dbcontrol db -repos drop
emca -config dbcontrol db -repos create

もしくは

emca -deconfig dbcontrol db
emca -config dbcontrol db -repos recreate

単純に削除しても失敗する場合は、SYSMANのユーザーなどを明示的にDROPする必要がある(参考のOracleDBConsoleの再構築参照)

4.参考

　DBConsole for Oracle Enterprise Manager

21 Enterprise Manager Configuration Assistant（EMCA）
OracleDBConsoleの再構築

ASP.NET WebFormでNUnitによるUnitTest環境を構築する

ASP.NET WebFormはUnitTestにすばらしく向いていないため、テスト駆動型開発の環境を整えるのは茨の道になる。試行錯誤しなんとかそれなりに出来たので、以下にその手順を記載します。

・前提
備え付けのMSTest(右クリック→テストケース作成)は使わない
→有料のProfessional以上でないと使用できず、また作成/テスト実行が異常に遅いため
(コード管理のTeamFoundationも有料だし、これでもうイヤと言われたら返す言葉は、ない)

AppCode内に単体テストケースは作成しない
→純粋に考えればこれが一番早いが、プロジェクトファイルが作れなくなるためNUnitの恩恵が受けられない＋どの道aspx.vbのコードが参照できないため、あまり意味がない。
Slim3のkotoriのように、NUnitがWeb配置できるようになればこの道も開けるかもしれない。

Kotori Web JUnit Runner


・事前準備
NUnitのインストール(msiファイルをダウンロードして、あとはYESで大丈夫)

・テスト環境構築手順
1.テストプロジェクトの作成
Solution NavigatorでWebサイトを開き、ソリューションのところで
「追加->新しいプロジェクト->クラスライブラリ」を選択し、テスト用プロジェクトを作成する。
※こうすること(ソリューションに追加する形で作成すること)で、テスト対象のWebサイトとテストプロジェクトがまとめて見られるようになる

2.Webサイト参照の作成
Webサイトをプリコンパイルし、テストプロジェクトから参照できるようにする。
この処理はバッチファイルで行うが、自動でやりたい！という場合以下2つの方法がある。
1.Webサイトのビルド後処理にプリコンパイル処理を入れる
2.テストプロジェクトのビルド前処理にプリコンパイル処理を入れる

プリコンパイルした内容は、テストプロジェクトのbin/TargetSiteに入れることにする(テストプロジェクトから参照できるならどこでも良い)。プリコンパイルのコマンドは以下の通り。
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe  -f -d -fixednames -p <Ｗｅｂサイトの物理パス>-v / <テストプロジェクトの物理パス>\bin\TargetSite

環境は.NET4.0を想定している。付与しているオプションのポイントは下記点。
-f：ファイルが存在したら上書きするようにするオプション。
-d：デバッグを可能にするためのオプション
-fixednames：出力するdllの名前を固定にするオプション。こうしないと毎回参照を設定しなおさないといけなくなる。

プリコンパイル方法参考


3.テストプロジェクトの環境設定
プロジェクトのプロパティ>デバッグで、以下2点を設定
・外部プログラムの開始→インストールしたNUnitのexeを指定
・コマンドライン引数　　 →作成したプロジェクトのdllを指定(bin/Debug内にある)

プロジェクトのプロパティ>参照で、2で作成したサイトのBin内にあるdllを片っ端から参照設定。
あとは、NUnitのdll(bin/framework/nunit.framework.dll)を設定すれば準備OK。
※外部プログラムの開始の設定がない場合、プロジェクトファイルを直接編集

VisualStudioとNUnitの連動設定　

さらに、web.configの設定を読み込むようにしておく。
NUnitのTools→Setting→Test Loader→Assembly Isolationについて、Default Domain UsageのUse a Separate AppDomain per Assemblyにチェックを入れる。
web.configを<テストプロジェクト>/bin/Debugの配下にコピーし、名前をテストプロジェクト名.dll.configに変更する

NUnitからweb.configを読み込む方法


4.テストの作成/実行
やり方はNUnitの普通のテストケース作成と変わらない。
Webサイトの参照を通しているので、ページ内のパブリックメソッドなどもテスト可能。
ただ、方針としてはaspx/aspx.vbにあまり重たい処理は持たせない方が良い。イベントハンドリング処理のみとして、実際の実装はクラスオブジェクトで行ったほうが良い(MVPパターンを参照)

MVPパターンの例
※サイトは英語だが、色々見て回った中で一番分かりやすかった。


最後に、環境構築のバッチの例を。


@echo off
setlocal
REM テスト対象のサイトと、サイトのコンパイル結果のコピー先を指定。コピー先は、bin直下の必要あり
set TARGET_SITE=\\app\webSite
set UNIT_TEST_PJ=D:\unitTest\webSiteTest\bin\TargetSite
set PJ_NAME=webSiteTest


echo 【指定されたwebサイトのコンパイルを開始します】
REM オプションについては下記サイトを参照
REM http://msdn.microsoft.com/ja-jp/library/ms229863.aspx
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -f -d -fixednames -p %TARGET_SITE% -v / %UNIT_TEST_PJ%


echo 【サイトのweb.configをテスト環境にコピーします】
REM コピー先に移動
cd /d %UNIT_TEST_PJ%
REM コピー先はbin直下、という前提に基づきweb.configをbin/Debugへ移動
copy /y web.config ..\Debug\%PJ_NAME%.dll.config


echo 【テスト環境の構築が終了しました】


endlocal