the status of .netSavant…

I have this awesome little ADO.NET code generator called .netSavant.  It analyzes your stored procedures and generates an optimized wrapper class that encapsulates the logic for execution.  After using it myself for quite some time, I thought, oddly, that I could make a little extra cash from the endeavor.  Heh, sadly I was wrong.  Dispite a lot of interest, few people were interested in paying $50 for a visual studio addin that saved a LOT of time and buggy code.  Wierd, but whatever.

So, with mixed feelings I killed the project.  It simply cost too much money to maintain the website and merchant account for a product that only sold a handful of licenses over the 18-24 months.

I’m left wondering what to do with the project.  There are a few options:

1. Create a codeplex project
2. Host the source code myself
3. Release the addin as freeware (no source code)
4. Release the addin as freeware with sponsorship (uhg, gross right?) (no source code)
5. Leave the project inactive and move on to other exciting technologies

I’m wondering if I really want to spend more effort supporting the project as a whole, though with so much time invested, its hard to walk away from it.  Part of me would like to see more people use .netSavant, if only to justify the time I spent creating it.  I’d also like the challenge of updating some of the methodology used to generate the source code, and possibly provide some extensibility points to enhance the analysis features that it supports.

Perhaps some day .netSavant will be resurrected in a better form.  Until that time, thanks for your interest and support.

Joshua

.netSavant 1.1.6 Released

I’ve been working on this latest release of .netSavant for some time now, and released it on 11/23/2008.  Its a pretty substantial update, though it may not look so much so at first glance.  There are a few things of note that are included in this release:

• Created Tools Options Page options to select which methods will be implemented for statements (stored procedures and inline sql).  This allows greater customization of the code that .netSavant generates by excluding methods that you never use.  Personally I never use DataTable or DataSet objects, so I have .netSavant configured to exclude these methods when generating my code.
• Simpler Unit testing support is achieved by not including code that you have no intention of using.  See the point above.
• Updated the VB.NET and C# code generation framework to format the generated code a bit more cleanly.  Who likes messy code right?
• Updated VB.NET generated code to use using statements rather than Try blocks for objects that implement the IDisposable interface.
• Updated the database connection form to default to the SQL Server provider rather than forcing you to select it each time.
• Numerous bug fixes.

I highly recommend upgrading to this version, visiting the Tools > Options page to set your preferences, and regenerating any legacy .netSavant code.

Enjoy!!!

.netSavant rc1 released!

I’m proud to announce the release of my new code generating addin, .netSavant.  You can download the release candidate on the website from our download page.

The addin will help you create robust ado.net code with an intuitive drag and drop interface.  Additionally it will generate best practice implementations of three (currently) system interfaces:

• System.IEquatable<T>
• System.IDisposable
• System.ICloneable

Currently I am working on the example code that will help to explain how to best use the ado.net code that is generated.  I’m also working on more and better F.A.Q. entries to answer those pesky little problems that come along with learning a new tool.

If there is any functionality that you’d like to see added to the addin let me know; I’ll entertain any reasonable request.

Enjoy!

nullable types and ado.net parameters

As most people are aware the .NET 2.0 framework supports nullable value types.  There are many articles on this topic and a few that address the issues of using nullable types in combination with your ado.net code.  However, most of these discuss the issue of using nullable types in combination with the DbDataReader objects, though few address the conflicts that arise when using a nullable type to set or get an ado.net parameter value.

Prior to .net 2.0 you’d run into this issue when attempting to pass a null string to the value of an input parameter.  In this case most of us would have written conditional code that looked something like this:

string firstName = null;
if(firstName == null) {
    Command.Parameters["FirstName"].Value = DBNull.Value;
} else {
    Command.Parameters["FirstName"].Value = firstName;
} 

Or you could have used a ternary operation: 

string firstName = null;
Command.Parameters["FirstName"].Value = firstName == null ? (object)DBNull.Value : firstName;