Thursday, January 17, 2008
I have many time tired gvim to compare 2 files. Here is a trick by which you can put your ‘favorite utility’ on fire.
Go to Visual Studio -> Tools -> Option -> Source Control -> Visual Studio TFS. Click on ‘Configure User Tools…”. Here you can configure your ‘Compare’ and ‘Merge’ tools separately.
This is my configuration:
Command: C:\Program Files\Vim\vim71\gvim.exe (you have to fully qualify the path. Specific for GVim, add C:\Program Files\Vim\vim71 to your $Path)
Arguments: -dR %1 %2
Also, you can pass various arguments for existing diffmerge utility. Here is example to pass ‘ignorespace’ argument.
Command: C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\diffmerge.exe
Arguments: /ignorespace /merge %1 %2 %3 %4 %6 %7
Although /ignorespace is not a recommended but you may want that to do in some specific case.
See complete tutorial here... http://blogs.msdn.com/jmanning/articles/535573.aspx
Friday, January 11, 2008
Recently I was stuck in a peculiar problem where I couldn’t insert a new record in a table using NHibernate. It came out to be the .hbm file which was giving problem. Because our DO generators are written so well, we looked for the bug there at last.
NHibernate class generator always creates class thinking that the primary key will be ‘auto-generated’. But that table doesn’t have auto-generated primary key. And so the “generator” element was incorrectly set to ‘native’ (i.e. auto-generated) for that table.
About “generator” element:
If the value of this is set to ‘native’, the key is auto-generated. Set ‘specified’ to set the primary key yourself in code. See link below for description of all values that generator can have. Note that ‘specified’ is the default in case “generator” element is absent in hbm file.
Wednesday, January 09, 2008
You might have figured out ‘Find 10 difference’ column in from your favorite news paper. Here comes it again with finding one difference that affects your code:
catch (Exception ex)
Answer: In case of ‘rethrowing’ exception, 1st case would still save the stack trace. Re-throwing the same exception in 2nd case will result into losing your stack trace.