Follow @PDSAInc February 2007 - Posts - Paul Sheriff's Blog for the Real World

Paul Sheriff's Blog for the Real World

This blog is to share my tips and tricks garnered over 25+ years in the IT industry

Paul's Favorites

February 2007 - Posts

Finding Machine.Config

OK, this is just a quick little tip. I need to be able to programmatically locate the Machine.Config file. Instead of hard-coding the path where I know it is, I used the new ConfigurationManager class in .NET 2.0 to perform this. Here is the code.

using System.Configuration;

Configuration cnf;

cnf = ConfigurationManager.OpenMachineConfiguration();


Imports System.Configuration

Dim cnf As Configuration

cnf = ConfigurationManager.OpenMachineConfiguration()


You will need to add a reference to the System.Configuration.dll to be able to use this, but then you can use File IO or XmlDocument methods to open and affect the Machine.Config.


Hope this helps someone out.


Are you still writing Add/Edit/Delete code?

Recently one of my programmers came to me after having visited with a PDSA client. He told me one of the programmers at this client was creating a new .NET application and had about 5 add, edit, delete screens created. He had spent, on average, about 7 hours creating, testing, debugging and tweaking the code on each screen. He wrote a little over 200 lines of code for each screen and at least 5 stored procedures for each screen as well. Even though he was able to copy and paste a lot of the code from one screen to another, he still had to fully debug and regression test all the add, edit and delete routines on each screen. This was in addition to the business rule logic that he had to test.

So, what is the point of all of this?

Why was this programmer (and maybe you?) not using some sort of code generator and Framework to generate all of this CRUD (Create/Read/Update/Delete) logic? If you are not using a code generator to create add, edit, delete and simple business rule logic for data, in my opinion, you are spending WAY TOO MUCH TIME CODING and NOT ENOUGH TIME SOLVING the business problem.

The problem with hand-written add, edit, delete code can be summed up fairly succinctly:

  • It may not be standards based (give a CRUD screen to 10 developers and you will most likely get 10 different versions).
  • It is difficult to reuse for the next application.
  • When it needs updating, someone will have to search through all those lines of code looking for locations to update.  Guess what?  They won't find all of them, resulting in high error rates.
  • This code will be harder to maintain over the life of the application, as new team members replace the original coding team.
  • It has to be written and re-written any place you need to add, edit, delete the same table, even on different forms.
  • If you change the table schema, you will need to find all the places where the add, edit, delete code for that table is and modify all those locations. This is a very error prone process.

You can eliminate every one of these consequences if you take advantage of a good Framework and Code Generator.

NOTE:  Many frameworks are NOT worth the hassle.  Microsoft's Enterprise Library, for example, has so many downsides (no support, high learning curve, bad documentation, no upgrade path, way over-engineered, hard to use just one block by itself), it is used at the peril of any developer.

So which Framework should you use? It depends! I know, not a very good answer, but there are so many different frameworks and code generators out there that it is hard to find a one-size-fits-all. As far as code generators go you can't go wrong with CodeSmith ( This will help you generate CRUD logic quickly and simply.

As far as Frameworks, some are good and some aren't. What you need to look for are the ones that do not lock you into their way of doing things:

  • Once a Framework generates code how customizable is it?
  • Can you inherit from their base classes?
  • Can you override their methods?
  • Can you add your own code to the generated code?
  • Do they separate their business logic from their data access code so you can add on your own business logic and not have it wiped out when your database schema changes and you need to regenerate?

So many questions, and so few answers. You will need to ask these questions before purchasing a Framework.

Many people have asked me what we use here at my consulting company PDSA, Inc. ( We built our .NET Framework and Code Generator from scratch! I know, a lot of work, but it was worth it. We now have a process in place that is consistent from developer to developer. We have all CRUD logic generated in literally a few seconds. This includes all stored procedures. The code generated is also 100% bug free! This means we do not need to test any of this code. We only need to test the custom business logic we need for those particular screens that we are coding. This eliminates hours and hours of work. If the table schema changes, we simply regenerate, and since our business logic is separated from the CRUD logic, our custom code is preserved.

So, how does our Framework and Code Generator work? I do a monthly webcast that shows you our Framework. Sign up at

Please understand I am not on this blog to promote our stuff. I happen to believe in Frameworks, any Framework, and I believe you owe it to yourself to check out the myriad of Frameworks that are on the market. I have been developing and designing Frameworks since I worked on COBOL on the mainframe. When I was doing Clipper programming I designed a code generator, screen painter, and a process for creating CRUD logic. In VB 3.0 I created a code generator and starting with VB 4.0 I have had a more complete framework. That has then led into our PDSA .NET Productivity Framework that we sell today. So stop writing so much code and focus on the business problem at hand. This will make you a better developer and one that is more demand by employers.


Posted: Feb 23 2007, 11:25 AM by psheriff | with 10 comment(s)
Filed under: ,
Check out DNR TV!

Last month I recorded an episode of DNR TV on creating custom providers. Carl and I go through a lot of code showing how to create your own custom providers. Enjoy!


Posted: Feb 06 2007, 08:11 PM by psheriff | with no comments
Filed under: ,
Migrating to .NET, simple to do

In my travels, I have noticed many companies are sitting on legacy applications that are good candidates to migrate to .NET.

While many of these applications run fine right now, eventually they will become obsolete due to changing business requirements, new operating systems, missing source code, etc.  Upgrading to .NET offers significant advantages, but the time to start upgrading these applications is *before* they become obsolete.

Planning for Obsolescence

Planning for the end of an application's life should be a part of your overall IT strategy in your company. Does this mean you lose all the investment you put into this application? Not necessarily. Hopefully the application has provided value to your company.  There are plenty of business rules, screen elements and other valuable assets in the existing application that can be leveraged in the migration to .NET.

Starting the Migration Process

One of the first steps in any migration process is to identify which applications should be migrated first. Once you decide on this, you should find any old specifications or requirements documents that describe the old system. If you can not find any, then create new ones. The goal is to create a new document that describes what the new application will do, what its goals are, and what the value proposition (ROI) will be to the company.

The next step is to prototype the screens in the new technology. Either ASP.NET web forms, or maybe Windows Forms. This step should be fairly easy since you have an existing application that you are designing from. However, you might want to the opportunity now to update the look and feel of the application to some of the newer ways people like to view applications.

When you are doing the prototyping, you should look around on the Internet for any tools that might help you migrate the screens and/or code to the newer platform. While the code may not migrate perfectly, it can be a help to identify business rules. We always recommend re-writing code as opposed to using code that is converted, but we need to find all the buried business rules in the existing code.

As you prototype the new application, you should also be updating the specifications and requirements document with any new business rules, fields and additional screens that will be added to the new system.

Using a Framework

Before you begin any serious coding, you should have a Framework in place. As most of you know PDSA is a strong proponent of Frameworks. We believe that if you don't have a Framework in place, you should purchase one (preferably ours!), or create one. A proper Framework is essential to ensuring your application development is done correctly, quickly, efficiently, consistently and ensures a lower Total Cost of Ownership over the life of an application.

If you look at many of your legacy applications you will most likely find the same routines written in each one. Take the time now to find/create a Framework that creates these routines in one DLL and can then just be re-used as you migrate each application.

Write the New Code

Now that you have created the prototype, created a specification document, consulted with the users of the system, convinced management of the ROI of the application, put your Framework into place, you are finally ready to start coding! Now is the time to look at other tools that can help make your job more efficient. For example, are there third-party tools that will make your UI design better, quicker, more efficient, and take you less code to write? Use CodeSmith, or the PDSA DACGen (from the PDSA Framework) code generators to develop the CRUD (create, read, update, delete) logic for your database calls.

The goal of developers today should be to reduce the amount of code you write and to focus on the business rules of the application. How the application manages the business is most important, not how many cool, wiz-bang routines you wrote. Those programmers that write applications to save the company money or reduce costs are the programmers that are most valuable to the company.


While migrating legacy applications does take time, money and resources, the upsides are tremendous. You will keep your programmers skills up to date, you will get better documentation, you will get a better, more robust system that is able to grow with your business, you will get a chance to put standards and a framework in place that will help with all other applications you migrate and create from scratch.

My company ( have done many migrations over the last few years. While it is never a "slam-dunk", once it is complete, the upsides for our clients have been huge. I have posted many samples that can help developers migrate their applications up on my Inner Circle at

Posted: Feb 06 2007, 11:18 AM by psheriff | with 1 comment(s)
Filed under: ,
More Posts