Archive for March 2014

NHibernate 3.0+ rounding a decimal data to 5 decimal places

March 14, 2014

Note: Precision is the number of digits in a number. Scale is the number of digits to the right of the decimal point in a number. For example, the number 123.45 has a precision of 5 and a scale of 2.

Problem: One of our team member was trying to to insert data into a SQL Server database from an application that is using NHibernate ver. 3.1. The format for a decimal datatype value is being forced to decimal(16,5) always, regardless of the SCALE defined for the column (ex: DECIMAL_VALUE1 decimal(16,6) in the SQL Server table. This results in decmial values being truncated before being written to the SQL Server database.

Here is the sample sql profiler trace:

exec sp_executesql N’INSERT INTO TEST_TABLE( DECIMAL_VALUE1, DECIMAL_VALUE2, LONG_VALUE1) VALUES (@p0, @p1, @p2); select SCOPE_IDENTITY()’ , N’@p0 decimal(16,5),@p1 decimal(16,5),@p2 bigint’, @p0 = 9.94434, @p1 = 9.94434, @p2 = 5583

Hence, the gotcha is that NHibernate by default sets the SCALE to “5”, if we haven’t told any SCALE in entity mapping class for the particular property.

The reason behind: [NH-1594] – When setting property in hbm type=”Decimal(precision, scale)” – “DECIMAL(19,5)” is always generated Ref: https://github.com/leemhenson/nhibernate/blob/master/nhibernate/releasenotes.txt

Solution: Enforcing scale to “6” in the fluent mapping or .hbm like below, it works great.

Map(x => x.DECIMAL_VALUE1).Scale(6);

<property name=”DECIMAL_VALUE1″ scale=”6″ />

Happy coding!

Advertisements

.NET GAC (Global Assembly Cache) folder location

March 6, 2014

Hope, some of you still think that the default GAC folder is c:\windows\assembly [%windir%\assembly] as such. But there is a BIG “NO”.

Yes, starting with the .NET Framework 4, the default location for the global assembly cache has been changed.

Reference: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).aspx

In .NET Framework 4.0, the GAC went through a few changes. The GAC was split into two, one for each CLR. The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. There was no need in the previous two framework releases to split GAC. The problem of breaking older applications in Net Framework 4.0.

To avoid issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GAC’s for each runtime. The main change is that CLR v2.0 applications now cannot see CLR v4.0 assemblies in the GAC.

.NET 2.0 GAC:

  • c:\windows\assembly – Non-native 32bit and 64bit assemblies.

.NET 4.0 GAC, below are the folders.

  • c:\windows\Microsoft.NET\assembly\GAC_32 – Non-native 32bit assemblies.
  • c:\windows\Microsoft.NET\assembly\GAC_64 – Non-native 64bit assemblies visible only on 64bit Windows.
  • c:\windows\Microsoft.NET\assembly\GAC_MSIL – Non-native MSIL (AnyCPU – 32bit & 64bit) assemblies.

Note:

While trying to load assemblies from the GAC, the CLR first looks at the GAC specific to the platform. If it is unable to find the same, it then moves to the GAC_MSIL.

Happy reading! 🙂