The blog of michael eaton

Chris Pratley has a great post about the "life" of MS Word: Let's talk about Word

I'm trying to burn a compilation CD of all my favorite Metallica songs, but it's proving to be tough. :-\  I may as well just carry all of my CDs with me.

So far (in no particular order):
Ain't my bitch
Wasting my hate
Nothing else matters
Fuel
Damage Case
Breadfan
Overkill
Stone Cold Crazy
Stone Dead Forever
Master of Puppets
All Within My Hands
Too Late Too Late

I realized today that I haven't ripped 'And Justice for all...' yet.  Geesh...I've owned the CD for years and I consider it to be their best album (although St. Anger is a close second).

A friend suggested that I look into buying an MP3 player for my car.  I should...I hate lugging CDs around.  I'd love to burn a couple hundred MP3s onto a CD and take it with me.  I may have to look into it.

Hehe...oops.  Because I was writing a template, I didn't start writing my unit tests until now.  The unit tests (using NUnit of course) are being written against my business objects.  Because of this, I'm now finding issues in my generated code.

More on this later...

This really shouldn't be called a 'DAL', so I'm gonna start calling it my 'Stored Proc Wrapper' template instead.

Check it out.

This assumes the stored procedures are named as:
Inserttable
Updatetable
Gettable
Listtable
Deletetable

I created my stored procedures using the 'AllStoredProcedures' template that ships with CodeSmith.

It also assumes a class named 'Common' that contains a static ConnectionString attribute:

using System;
using Syste.Configuration;
public class Common {
    public static string ConnectionString() {
        get {return ConfigurationSettings.AppSettings["ConnectionString"];}
    }
}

My app.config file looks like this:
<?xml version="1.0"?>
<configuration>
<appSettings>
<add key="ConnectionString" value="put your valid connection string here"/>
</appSetting>
</configuration>


Notice that I made all my 'Stored Procedure Wrapper' methods static. This way I can simply say:

DataSet ds = StoredProcedures.GetTable(ID);

I'd say it's taken about 2-3 hours of dedicated time to write the template. Granted, a lot of that time has been spent a) waiting for the template to be compiled and b) looking up details in the Schema Explorer help file. CodeSmith is a great tool and I can definitely see using it on future projects.

My current DAL template is going to need some major refactoring, but that's no big deal. I'll try to post my template later today.

Roy Osherove is promoting a cool contest for the "most useful Add-in/Macro for Visual Studio.NET".  This looks very cool.  I need to come up with some cool ideas.... :-)

My original thought was to write a template for CodeSmith that would generate wrapper methods around all my stored procedures.  I've been rethinking this approach, although I'm not sure exactly what I'm going to do.

Anyway...I've been working on the CodeSmith template and I have a good start.  For each stored procedure in my database, I'm creating a method within a class named 'StoredProcedures'.  This class lives in my DataAccess namespace.  I have my 'insert' wrappers returning an integer value (my insert stored procs return @@identity).  My "select" wrappers return DataTables.  Updates and Deletes return void.  I'll probably include exception handlers in all of the methods.

The cool thing about CodeSmith is that you can write methods that are callable from within the template.  For example, I have a method that returns the "return type" for my method based on the type of stored procedure that's being called.  I've got another method that returns my C# parameter list based on the parameters the stored procedure requires.

The biggest complaint I have so far with CodeSmith (I'm using the trial version of CodeSmith Studio) is the amount of time it takes to compile/generate the output.  Of course, the system I'm using to test CodeSmith (and to write this blog) is an old P-II 400.  My laptop (a P-III 1.7 gHz) is sitting on my desk, but that would mean leaning forward to type. :-)

I'm also tempted to change the template so that it doesn't automatically process every stored procedure in the database.  I may change it so a single proc is processed.  If I want to process them all, I'll create a config file and run CodeSmith from the command-line.

On Wednesday, April 14th, I was elected Vice President of the Detroit Chapter of the Independent Computer Consultants Association.  The chapter was established last year and since its inception, I've been responsible for the design/development/maintenance of the Chapter website.  My goal during my time as VP is to help grow our Chapter as much as possible.

What we had was a FUSER error...yep, a good old F'in User that screwed up.

Turns out, my app.config file was screwed up, but not by VS.NET.  It's amazing what you can find when you actually take the time.  My app.config file looked like:

<?xml version="1.0" encoding="uft-8"?>="BR"><configuration>
    <appSettings>
        <add key="ConnectionString" value=" value="valid connection string"/>
    </appSettings>
</configuration>

See the problem?  yep....the value="

Now that it's fixed, my form comes up fine. 

Live and learn I guess...

Whew...a stroke of luck.  I still have the prototype of the search form, so I at least have a starting point. :-)

Let's get one thing straight right off the bat...I have never used 'Dynamic Properties' in *any* of my WinForms.

Ok...so, there I was, happily coding my business objects and tying them to my user interface. Up to this point, I have used a hard-coded connection string (like you've never done that) in my application.  Today I finally got around to adding my app.config file with the appropriate key for the connection string.  This, it turns out, was a big freakin' mistake.

The user interface was created a few days ago.  One of the forms I created was to be used for searching.  It consisted of a some panels, buttons and a tab control.  Today I was ready to make the form actually work, so I opened the designer for this form to give it a once over before I started adding the glue for the business objects.  After a few seconds, my Task List popped up with about 300 items in it.  I don't recall the exact error, but it had something to do with dynamic properties and the app.config file.  WTF?  The UI looked fine to me, so I double checked my app.config file which also looked fine.

I closed the form and re-opened the designer.  Nothing happended this time, so before starting, I renamed a couple of controls (forgot to change them from the default when first creating the form).  I closed the design view of the form and then I recompiled the app to make sure the new names weren't gonna cause any problems.  No problems compiling the app...

Ok, now here's where the urge to scream starts.  I opened the form in design view again (to see where I should begin adding the "glue") and this time the form was completely screwed up!  The form itself was about 1/4th the size that it should have been, no captions were displayed and all of the controls that weren't Docked were now moved to the far left of the form.  Again I say 'WTF?'.

What the hell did adding an app.config file have to do with my search form?  Time for Google: search for 'app.config dynamic properties' -- 187 hits.  Cool.  After some reading, I discover that if you create dynamic properties, they are stored in the app.config file.  Ok, fine...Did I mention that I *NEVER* used any dynamic properties? 

So, it appears that somehow an app.config file was created and placed in the bin\ folder, but not in the project root.  Why did this happen?  Why did VS.NET allow me to add the new app.config file? 

The pisser of it all is that I did a Bad Thing.  The form hadn't made it to SourceSafe yet, so I am totally screwed.  I now have to recreate this damn form.  I think I'm more pissed about this than the fact that VS.NET did something without me knowing.

This time I'm going to pay attention and try to figure out what the deal with the dynamic properties is.  As soon as the form is created, it's getting checked into VSS. :-\

 

I should point out that I originally looked at the CommandWrapperClass template (ships with CodeSmith).  While I'm sure the author of the template put a lot of thought into it, it appears to be a bit more than I need for my test project.  I do think I'll end up using some of the code from the CommandWrapperClass template, but I'm not absolutely sure yet.

So, I need to decide if I want all of my wrapper methods to be in a single, huge class or if I want them in table-related classes.  The latter seems like the right thing to do, but now I have to figure out how to do it. :-)

Writing CodeSmith templates is almost identical to writing ASP.NET.  You have the <% %> tags and the <%@ directives.  You can have code-behind files to do some heavy lifting as well as script in the template itself.

Here's what I have so far:

<%@ CodeTemplate Language="C#" TargetLanguage="Text" Description="Creates DAL" %>
<%@ Property Name="Namespace" Type="System.String" Description="The namespace this class belongs to."%>
<%@ Property Name="SourceDatabase" Type="SchemaExplorer.DatabaseSchema" Category="Context" Description="Database" %>
<%@ Assembly Name="SchemaExplorer" %>
<%@ Assembly Name="CodeSmith.BaseTemplates" %>
<%@ Import Namespace="SchemaExplorer" %>

namespace <%=Namespace%> {

}

Because templates can be written in C#, VB.NET and JScript, the first directive specifies which language I'll be using.  You can create properties that are settable using the properties window by using the Property directive.  I've created two properties; one for the namespace I want to use and the second is for specifying the stored procedure I want to wrap.

I then reference and import the SchemaExplorer namespace.  This lets me interrogate the database schema and retrieve the database objects so I can use them when creating the template.  This means the template will be able to generate all of the SqlParameters by looping through the database objects.

Just for the heck of it, here's some test code to dump all of my stored procedure names along with their parameters:

 <%
  foreach(CommandSchema cs in SourceDatabase.Commands) {
   Response.WriteLine(cs.Name);
   foreach(ParameterSchema ps in cs.Parameters) {
    Response.WriteLine("\t" + ps.Name);
   }
  }
 %>

 

I've been playing with Eric Smith's CodeSmith tool for the past couple of days.  The templates that ship with the product are great, although I have had to make some modifications to a couple of them.

I'm in the process of writing my first template to create a simple data access layer.  By simple, I mean it's going to create wrapper methods around my CRUD stored procedures (which, BTW, were created using the AllStoredProcedures template that ships with the product).

Based on what I've seen in the other templates, this really shouldn't be difficult.  Of course, I could always download a template from the CodeSmith support forums, but I'm really in the mood to try writing a template myself.

I can already see the power of this tool...not necessarily in the templates themselves, but the fact that you could drive the generation from the command line.  This means I can specify all the template criteria in a config file and then have the CodeSmith engine kick out the code.  This is far better than doing it manually.

The CodeSmith Studio is a nice, well thought-out IDE.  I'll post more on the subject later.

I've been subscribed to Packet8 for a couple of months.  Besides a few glitches (no dial tone at times which required a device reset, the occasional "white noise" during conversations -- I can be heard, but I can't hear the other person) and a couple of annoying features that are missing (all I get with caller id is the number, not the name and the line won't actually ring if the line is connected to a multi-line phone), it's been a good deal when compared to a plain phone line.  I spend about $20/month for unlimited calling in the US and Canada. 

I have it setup to forward calls to my cell phone just in case I'm not at my desk, so I never miss any calls.

In a recent post, Don Kiely said:
"Here's the problem. We developers slog through our every day life using the released versions of tools, getting real work done. There is so much to learn and know about the current state of the tools and technologies that I still feel like I've only scratched the surface of a very thick block of knowledge. I'm figuring out how to do stuff in real apps today, and sometimes feel like I'm barely keeping up with that. "

This comes on the heels of the latest MSDN Magazine that has "An In-Depth Look at the Technologies Behind Visual Studio 2005".

While it's great to see what's coming, there are still 10,000 things about Visual Studio.NET 2003 / .NET 1.1 that I want/need to learn.

Yahoo! News - Despite jobs boost, Kerry still blasts Bush economic record: "Kerry touted his plan to create 10 million jobs if he is elected president. "


Anyone that believes Kerry can "create" 10 million jobs in 4 years is out of their mind. This is the same as the "100 thousand cops" and the "100 thousand teachers" crap that came up during the Clinton years. It all sounds good...