Geeks With Blogs
CodeSeeker Just another developer trying to do the right thing

Right off the bat I'll tell you I am a beginner when it comes to CodeSmith. Basically, the tech lead set up the templates and I know how to run them and that's about it.

That being said, we figured out how to get around some strange behavior with CodeSmith today that I thought I'd write a brief note about. I was going through a legacy project to convert all .NET Double and SQL Server FLOAT data types to Decimal (on both platforms) for greater precision. I changed all the fields in the tables and re-ran CodeSmith, but for some reason, it was not changing the data types for the handful of Views we had. (We have CodeSmith set up to use a View instead of the table to generate the business object class if the View has the same name as the table.)

By editing the Views and simply running the automatically-generated ALTER statement, the CodeSmith class generation started working correctly. It appears as though SQL Server keeps an internal representation of the data types of the columns represented by the View that doesn't get updated after a data type change until after the View is regenerated, and CodeSmith refers to those data types instead of referencing the underlying table's data types.

Posted on Monday, December 14, 2009 8:08 PM | Back to top

Copyright © Mike Ellis | Powered by: