カテゴリー別アーカイブ: .NET

VB.NETからC#へのWindowsFormプロジェク移管メモ

マルチプラットフォームの時代にまだWindowsFormなのかよと、常に先進的なプロダクトに関わってる方からは思われるかもしれませんが、、未だにWindowsFormは結構現役です(笑)

使うからには保守が必要ですが、VB.NETはそろそろお役御免ということで、一先ずC#へ色々なプロジェクトを移管してますので、備忘録ついでに、、、

今回は以下のツールとサイトを使わせてもらいました
SharpDevelop4.4
TelerikCode Converter

1、対象のソリューション(プロジェクト)の複製を作ります

2、SharpDevelopでプロジェクトのコンバートを試みます

SharpDevelopは.NetFramework4 までしか対応しておらず、既にVisualStudio2017等の最新ツールを使っている場合は、対象フレームワークの変更と、*.vbprojファイルの編集が必要になります。

ToolsVersion 12.0を14.0へ
——

なるべく最新の記述はしてないほうが良いです(笑)
↓こんなのやLINQバリバリだと弾かれます。。。
Dim = $”{新しい記述方法}”

読み込めたら対象のプロジェクトの右クリックメニューからConvertを選べます。

しばらくすると結果が表示されますので、その結果を見ながら、Visualstudioで追加の処理をします。

3、上記変換出来なかった一覧は、CodeConverterを使って部分変換&貼り付け等をすると、少しは効率的にしょりが行なえます。

4、細かい部分は自分の手で修正。。。
はい、頑張ってください。
多分6,7割はツールによる変換で対応出来ると思います。

あと、、イベントの挙動がVBとC#で若干違います(特にフォームが開いたタイミングで発動するイベント、、VBのWithEventが悪さしてる感じ)

そのあたりの手間をみても、ツールを使えば手動よりも圧倒的に早く移行作業が出来ます。

TransactionScopeを使用した際にMS-DTCの昇格を防ぐ

Windowsばかりがある環境では Microsoftの.NETFRAMEWORK の開発環境は最強である、、恐ろしいほどの開発工数の削減が可能で、更新も簡単だ

今回は開発環境のうち問題になるポイントをば、、
トランザくショナルな処理を行いたい場合は幾つかの方法があるが、その中でも推薦されているのが以下のライブラリを使ったトランザクション処理だ
System.Transactions.TransactionScope

スコープというだけあり、その範囲内に記載されたデータベース処理を単一、複数サーバー問わずにアトミックに処理できる優れた仕組みであり、また記述方法もシンプルでモジュール化も行いやすい

と、、とても使いやすいんだけど難点がある、それはプログラムの記述方法により『分散トランザクション』が発生した際にMS-DTCの設定がDBサーバーと各クライアントに必要になること、、

MS-DTCの設定であるが少なくともWindows2003までのActiveDirectoryが提供するグループポリシーでは自動設定が出来ないために、個別にクライアントへの設定が必要になってくる。

ファイヤーウォールでのmsdtc.exe プログラムの通信を許可することも必要

また、厳密な処理をするためかNetBiosでクライアントからDBサーバーのIPアドレス、またサーバーからは逆引きでクライアントのIPアドレスを特定できる必要があるが、ケースにより逆引きが正しく行えないなど、運用面ではトラブルが起きやすい。

話をもとに戻すとそもそも『分散トランザクション』とは複数のDBサーバーをまたぐ際に一貫した処理を維持するための機構であり、『2層コミット』とも呼ばれる仕組みで、オール or ナッシングを実現している。

大規模なシステムでない限り1台の DBサーバーとの間では必要ない仕組で、単純にプログラムの記述を簡潔に行いたい場合においては『要らぬ世話』なのである。

だがしかし、1台のDBサーバーとやり取りをするプログラムであってもコネクションが複数になると自動的に『分散トランザクション』へ昇格してしまうことが今回の問題。

Visualstudioで開発しているならば型付データセット、テーブルアダプターは開発工数を劇的に下げる素晴らしい仕組みだが、TransactionScopeとは完全に相性がいいわけではない。

この状態では『分散トランザクション』へ昇格する
原因はDBサーバーへのコネクションが複数張られるため

幾つかのサイトで .NETFRAMEWORK2.0 SP1 とSQLServer2008である場合はこの制限がいくらか緩和されるようだが、あくまで1つのコネクションを共有する場合である。

緩和されているが、あまり劇的ではない。出来れば対象が一つのDBサーバーである場合スコープ内の処理方法問わず昇格しない様にしてほしいが、SQLServer2012のドキュメントをみてもこの辺りは改善されていないようだ。

またこの仕組、ローカル環境(プログラムとDBSQLServerが同一マシン)では一切昇格しないので、ネットワーク環境でテストして初めて直面する問題であり、自分としてはとても厄介だ。

この問題は、複数のコネクションが発生する場合に起きる、つまり単一コネクションを引き廻せば良いことになる。

これに対しての一つの解決策がコネクションをSingletonパターンで作成すること
これで”唯一のコネクション”を確保できMS-DTCへの昇格を防ぐことが出来る。

さて、実装していってみよう。