スレッドプール側で投げる例外に注意 - 匣の向こう側 - あまりに.NETな
http://d.hatena.ne.jp/akiramei/20060124/p1 ↑は、ちょっと説明が足りなすぎなので補足します。 using System; using System.Threading; delegate void SilverSkin (); class Program { static void Lance () { throw new Exception ("届け…"); } static void Callback (IAsyncResult r) { SilverSkin ss = r.AsyncState as SilverSkin; Console.WriteLine ("In Callback."); try { ss.EndInvoke (r); } catch (Exception) { Console.WriteLine ("例外をそのまま投げ
Exceptionから継承しない値のthrow - 匣の向こう側 - あまりに.NETな
C#ではExceptionクラスもしくは、その派生クラスしかthrow出来ませんが、C++/CLIだとそれ以外の値もスロー可能です。 // This is the main DLL file. #include "stdafx.h" #include "MyDLL2.h" public ref class Foo { public: static int Divide(int x, int y) { if (y == 0) // throw gcnew System::Exception(); throw gcnew System::Int32(); // throw -1; return x / y; } }; 上記のようなコードをコメントアウト部分を変えながらC#側でキャッチするとどうなるでしょうか？ using System; using System.Runtime.Interop
アプリケーションの状態を保存 - 匣の向こう側 - あまりに.NETな
例えば、前回起動した時刻や起動回数など、実行時間を超えてアプリケーションの状態を保存したい場合があります。その場合、外部記憶(ファイルやDBなど)にシリアル化などして保存する(いわゆる永続化)ことになりますが、.NET2.0だと、SettingsBase(ApplicationSettingsBase)を使うと便利です。 以下は、アプリケーションの前回起動した時刻を保存する例。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Configuration; namespace Sample { public class MySettings : ApplicationSettingsBase { const string KEY = "Last
app.configのファイル分離 - 匣の向こう側 - あまりに.NETな
app.configを複数ファイルに分けたいことがあります。例えば、app.configとweb.configに共通の設定などがあったりとか。この場合、カスタムセクションを作ったりすることになりますが、そこまで大掛かりなことが不要な場合は、configSourceを使うと便利です。 <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings configSource="appSettings.config"/> </configuration> 上記の場合、appSettingsの内容が別ファイル(appSettings.config)に記述できます。もちろん、接続文字列セクション(connectionStrings)とかも対応可能です。
GetDelegateForFunctionPointer - 匣の向こう側 - あまりに.NETな
気づいてなかったのですが、.NET2.0からは、関数ポインタをDelegateへ変換して呼び出せるようになったんですね。.NET1.1のころはManaged C++を使ったり、ヘルパDLLを用意したりする必要があったのが、C#だけで解決できるようになったのは良いですね。試しにSusieのプラグインを呼び出すサンプルを書いてみました。 画像表示までやると日記で書くようなコード量じゃなくなるので、アーカイブ内のファイル名を列挙するだけです。(^^; using System; using System.Collections.Generic; using System.Text; using System.Runtime.InteropServices; using System.IO; namespace Sample { #region Win32 API static class Win
拡張メソッドによるチェーンメソッド - 匣の向こう側 - あまりに.NETな
ふと、MSDNマガジンの記事を読んでいたら目に付きました。ネーミングルール決めてusingで処理を入れ替えとか出来そうな気がしましたが、トリッキーなのでちょっとダメかな？(^^; using System; using System.Collections.Generic; using System.Collections; using System.Linq; using System.Text; class Block : IDisposable { static Stack<Block> stack = new Stack<Block>(); ArrayList list = new ArrayList(); public ArrayList List { get { return list; } } public Block() { stack.Push(this); } publ
DLLの動的読み込み - 匣の向こう側 - あまりに.NETな
折角、Seasar Conferenceに来たのだから、Javaのセッションも１つぐらいは・・・と、ひがさんのを。Hot Deployの実現方法がリクエスト毎に新しいクラスローダを作成して云々(良く分かってない)というのを聞いて、.NETだとリクエスト毎にAppDomainを作成するようなものかな？とか考えたり。ってことで、サンプルコード。 動的に読み込むクラス用のインタフェース。たとえば、BaseLibrary.dllとかで作成。 namespace BaseLibrary { public interface IGreeting { string Hello (string name); } } その実装。ClassLibrary1.dll。 using System; using BaseLibrary; namespace ClassLibrary1 { public class
NullObjectパターン - 匣の向こう側 - あまりに.NETな
http://d.hatena.ne.jp/akiramei/20071010/1192038349 ↑はるか昔に似たようなことやった気がしていたのですが、はてなで日記を書く前でした。折角なので、数年間更新していない自分のＨＰからコードを持ってきてGeneric対応させてみました。当時(2003年)は、RealProxyがマイブームだった模様(笑)。 using System; using System.Collections.Generic; using System.Reflection; using System.Runtime.Remoting.Messaging; using System.Runtime.Remoting.Proxies; class NullProxy<T> : RealProxy { private static readonly Dictionary<Ty
Excel操作その後 - 匣の向こう側 - あまりに.NETな
じっくり調べたら単にオブジェクトが解放されていないだけという良くある話でした。参考までに動作するサンプルをあげておきます。 画像ファイルをExcel2007のワークブックに変換するスクリプト。 import sys import clr clr.AddReference('System.Drawing') clr.AddReference('Microsoft.Office.Interop.Excel') from Microsoft.Office.Interop import Excel from System.Runtime.InteropServices import Marshal from System.Drawing import Bitmap,Color def bmp2xlsx(path): """Excel2007を前提にしているので画像サイズチェックは入れてない"""
Reflectionによるメソッド呼び出し時の例外 - 匣の向こう側 - あまりに.NETな
ちょっと嵌りました。 using System; class MyException : Exception {} class Foo { public void Bar() { throw new MyException (); } } static class Program { static void Main () { Foo foo = new Foo (); try { foo.Bar (); } catch (MyException) { Console.WriteLine ("Catch!"); } Type t = foo.GetType(); try { t.GetMethod("Bar").Invoke(foo, null); } catch (MyException) { Console.WriteLine ("Catch!"); } catch (System.R
IronPythonからADO.NETを使うサンプル - 匣の向こう側 - あまりに.NETな
PythonプログラマがIronPythonを始める場合、.NET経験者なことはほとんどないと思うので簡単なサンプルを用意してみました。 データベースはMySqlとしました。ADO.NETのドライバーはここから。ADO.NETが初めての方は、アプリケーションとデータの仲介役 : DataAdapterを5分ほどご覧ください。(^^; import clr clr.AddReferenceByPartialName ('System.Data') clr.AddReferenceToFile ('MySql.Data.dll') from System.Data import * from MySql.Data.MySqlClient import * connstr = 'User Id=%s;Password=%s;Database=%s' % ('user', 'pass', 'db'
匣の向こう側 - あまりに.NETな - C++で組むのか苦痛になってきた(^^;#p3
CLR Managed Debugger (mdbg) Sample .NET用デバッガのサンプル。ダウンロードしてビルドしてみたけどこけた。(^^; 日本語ディレクトリがいけないのかしら・・・ main.d .NET上で動くD言語を開発中？詳細不明・・・ メソッドの呼び出しをログに書き出すようにしておくと、トラブル時に役に立ちます。でも、そのようなトレース書き出しをあちこちに埋め込むと、ソースコードが読みにくくなってしまいます。.NETではRealProxyを使ってメソッドの呼び出しに割り込めて、所謂、アスペクト指向プログラミングっぽいことが出来るので素晴らしいのですが、パフォーマンスがとても悪かったりします。やりたいことは、メソッドの呼び出しに割り込めれば良いだけなので、もう少し単純な方法を考えてみましょう。例えば次のようなクラスがあったとします。 public class Calc
委譲クラスの自動生成 - 匣の向こう側 - あまりに.NETな
http://d.hatena.ne.jp/akiramei/20040810#p3 遙か昔のネタを再利用して、委譲メソッドをチマチマ書くのを手抜きしてみる。 #region Using directives using System; using System.Collections.Generic; using System.Text; using System.Reflection; using System.Reflection.Emit; #endregion class Delegator<T> where T : class { public static T To<U>(U dst) { Type t = typeof(T); Type m = typeof(U); // 作成されるクラス名はクラスTo移譲先クラス string name = t.Name + "To" +
はじめてのPostSharp - 匣の向こう側 - あまりに.NETな
NEWSで取り上げたPostSharpが面白そうなので早速実験です。 まず、コンソールアプリケーションプロジェクトを作成して、MyTestAttributeクラスを作成します。 using System; using PostSharp.Laos; [Serializable] class MyTestAttribute : OnMethodBoundaryAspect { public override void OnEntry (MethodExecutionEventArgs eventArgs) { Console.WriteLine ("Enter:" + eventArgs.Method.Name); } public override void OnExit (MethodExecutionEventArgs eventArgs) { Console.WriteLine ("
コンソールでWF - 匣の向こう側 - あまりに.NETな
WFといえば、GUIでお絵かきが目立ちますが、本質は宣言的にプログラミング可能にするモデルだったりします。勉強のためGUIを使わずにWFのコーディングを行ってみたいと思います。まず、最初はHello, Worldから。 WFはActivityによって構成されます。ここでは、HelloWorldというActivityを作成します。 using System; using System.Workflow.ComponentModel; using System.Workflow.ComponentModel.Serialization; [assembly: XmlnsDefinition ("http://Na", "Na")] namespace Na { public class HelloWorld : Activity { protected override ActivityExe
CREATE TABLEの解析 - 匣の向こう側 - あまりに.NETな
EntityGeneratorに使っていたSQLの解析ルーチンが仕事に使えそうなので、Oracle対応なんかしてみたり。 Oracle Developer Tools for Visual Studio .NETが吐き出すCREATE TABLE文は、こんな感じ。 CREATE TABLE "MY"."USERS" ("NAME" VARCHAR2(32 BYTE),"AGE" NUMBER) TABLESPACE "USERS" PCTFREE 10 INITRANS 1 MAXTRANS 255 STORAGE ( INITIAL 65536 MAXEXTENTS 2147483645 MINEXTENTS 1 ) / CREATE UNIQUE INDEX "MY"."SYS_C007336" ON "MY"."USERS" ("NAME" ) TABLESPACE "USERS"
OracleClient vs ODP.NET - 匣の向こう側 - あまりに.NETな
Oracle用のプロバイダとしては、Microsoftが提供するOracleClientとOracleが提供するODP.NETがあります。当然、Oracleが出している方が高性能なんですが、以下のようなデメリットがあります。 標準では入っていないのでダウンロードする必要がある Visual Studio 2005のWizardに対応していない このうち、後者がネックです。なんと言っても型付DataSetとTableAdapterが使えないのは痛すぎます。仕方ないのでOracleClientを使うことにしようかと思ったのですが、こっちはこっちで別の問題が発生しました。 トランザクション分離レベルをSerializableにすると、ダーティリード、反復不能読み取り 、ファントムリードのすべてに対し、安全です。たとえば、トランザクション中で件数を調べるをクエリーを発行し、その後、別トランザクショ
SQLによる例外処理 - 匣の向こう側 - あまりに.NETな
個人的には例外はキャッチしない方針なのですが、SQL関連の例外についてはそうも行きません。重複やNULL制約などは例外ではなくエラー扱いにしたいところです。 try { int cnt = IUserDao.Insert(user); } catch (SQLRuntimeException ex) { // SQLRuntimeExceptionはSeasar.NETの型なので局所化したい // OracleExceptionはODP.NETの型なので局所化したい OracleException oex = ex.InnerException; Trace.WriteLine (oex.Message); Trace.WriteLine (oex.Number); return false; } たとえば、上記のような処理が入ります。例ではS2Dao.NETを使っているので、SQLRun
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
