I love it when I'm just cleaning up some code after some major changes and I discover code that has been sitting there a while that would never have worked. I don't even have to run/test it. I can read it and know it's broken. So is that a win for finding a bug and fixing it before it showed up or is that WTF? for having such an obvious bug in the first place.

The days when I don't have to deal with web.config are great. The days I have to go in there are bad, bad, bad. Why can't web.config be easy? Why can't it tell me more, and complain less. Why can't it be easily organized in some sort of logical pattern instead of loosey goosey? The registry looks great compared to web.config.

Is this fixed in the latest VS or .Net?

Previously, a few of us held a discussion about the best way to concatinate a number of string array elements into a single string. You can find details here. Last week, I needed something a bit more general purpose. Came up with an extension method on IEnumerable that will accomplish this for any type.

public static string Fuse<TSource>(this IEnumerable<TSource> source, string separator)
{
    if (source is string[])
    {
        return string.Join(separator, source as string[]);
    }

    return source.Aggregate(new StringBuilder(),
        (sb, n) => sb.Length == 0 ? sb.Append(n) : sb.Append(separator).Append(n),
        sb => sb.ToString());
}

The method is optimized to use the string.Join method when the underlying type is a string. Join uses unsafe code and is very quick. Here are a few example uses:

string[] names = new string[] { "Andy", "Wayne", "Dina", };
string allNames = names.Fuse(", ");  // "Andy, Wayne, Dina"

int[] numbers = new int[] { 1, 2, 3, 4, 5, };
string allNumbers = numbers.Fuse(":"); // "1:2:3:4:5"

object[] objects = new object[] { 1, "ten", 5.5, true, false, };
string allObjects = objects.Fuse("/"); // "1/ten/5.5/True/False"

And finally Wayne's Codesmith version for all procs prefaced with 'aspnet_':

<%@ CodeTemplate Language="C#" TargetLanguage="C#"  %>
<%@ Property Name="SourceDatabase" Type="SchemaExplorer.DatabaseSchema" %>
<%@ Assembly Name="SchemaExplorer" %>
<%@ Assembly Name="System.Data" %>
<%@ Assembly Name="System.Design" %>
<%@ Import Namespace="SchemaExplorer" %>
<%@ Import Namespace="System.Data" %>
USE [<%=SourceDatabase.Name%>]

GO

<%

foreach(CommandSchema command in SourceDatabase.Commands)
{
 %>
 
 <%
 if ((command.Name.Length>7) && (command.Name.Substring(0,7) == "aspnet_"))
 {
%>
IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[<%=command.Name%>]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[<%=command.Name%>]

GO

<%
 }
}
%>

After generating all CRUD procs with several different naming prefixes, my database was looking messy. So I knew what I wanted to produce but I needed to get rid of all these other procs. So how to quickly drop all the procs. Wayne said he had a codesmith template for it but I couldn't wait. I google'd and found another person that had the same problem after a heavy CodeSmith NetTiers session. His method was not too different from my post from yesterday. I did my final gen of procs via NetTiers but instead of going into the database, sent them to a file. I opened the file to find the following code which should have been both obvious in that NetTiers would need it and where I should look for it:

BEGIN

DECLARE @procedureName SYSNAME

DECLARE c CURSOR FOR

SELECT name FROM sysobjects WHERE type = 'P' AND objectproperty(id, 'IsMSShipped') = 0

AND name LIKE 'NetTiers_%' AND name NOT LIKE 'WW_{0}_%'

OPEN c

FETCH NEXT FROM c INTO @procedureName

WHILE @@FETCH_STATUS = 0

BEGIN

EXEC('DROP PROC ' + @procedureName)

FETCH NEXT FROM c INTO @procedureName

END

CLOSE c

DEALLOCATE c

END

In Sql server query window, execute query that selects all stored procedures with the prefix you want (such as procedures that start with 'cust'):

SELECT 'DROP PROCEDURE ' + Name FROM sys.objects

WHERE type in (N'P', N'PC')

and name like 'cust_%'

 

After using NetTiers for a couple of weeks now, here are some suggestions for usage:

1) Use NetTiers like any third party library. Build it and include the libraries. Do not alter code inside generated libraries unless mission critical. I also use the Microsoft.Patterns library. They ship the code but I don't alter it, I just use the built libraries. 

2) Prefix the library namespace with NetTiers so that the generated libraries look like NetTiers.Entities, NetTiers.Data, etc.

3) If you use NetTiers to generate your CRUD, set the ProcedurePrefix value to NetTiers_. When you are looking through a million procs, it easier to pass a whole section based on alphabetical sorting. If you use AspNet Membership, you will be accustomed to this naming schema as those procs are prefixed with aspnet_

4) If you create your own procs, prefix those procs to something that you won't confuse with any other library's procs, such as 'cust' for custom. Of cource, IncludeCustoms is set to true and CustomProcedureStartsWith should be set to 'cust_{0}_' so that a table name of Profile should have a custom proc of cust_Profile_SelectAll.

5) While still getting your template settings figured out:

• Don't set ExecuteSQL to true until you have tested your generated SQL and looked through what was created.
• Set LaunchVisualStudio to true and save yourself a few clicks.
• Set ViewReport to false. You don't need another browser to open while you are still figuring out your templates.

6) Build the Web Service and the Admin site. Even if you don't plan to use AJAX or you have your own admin pages already built, these are just more examples of NetTiers code usage. Then when you need a data backdoor or quick AJAX, you are that much closer.

7) NetTiers documentation suggests using DeepLoad to get to a related table via FK. I can see how this would be used in their example of list of Orders in a grid and you also want to display the Customer's Name in the grid. What if you had a table of ProfileItems and a table of UserProfileItems and you wanted a list of all the ProfileItems in a grid with this user's settings? With the NetTiers usual get based on FK from either table, you won't get the grid I want (right?). So in that case, I'll create a custom proc with the proper bind.

I have a table with two FKs. NetTiers creates a stored proc for the PK as well as a stored proc for each FK however it doesn't create a stored proc that uses both FKs as the IN params. So I need to create this in a way that NetTiers can discover it and build the code objects to support it.

First I have to create the stored proc with a discoverable name. This requires several settings in the NetTiers template. First, that I want custom stored procs discovered so IncludeCustoms=true. Second, I want any stored procs to have a naming prefix so ProcedurePrefix=usp. Third, I need to handle the actual name of the stored proc. NetTiers uses discovery based on a template where the zeroth parm is the table name and the first parm is the Procedure Prefix so CustomProcedureStartsWith={1}_cust_{0}_. The remainder of the stored proc name is irrelevant but what is returned is very important. I usually return all columns which is NetTiers default object handling. If I choose not to include all columns, I would have to deal with an IDataReader or a DataSet.

If all the other stored procs and NetTiers code has been generated and you only new a few stored procs to be discovered, make sure to set ExecuteSQL=false and SourceTables=(only immediate tables.)

Once you generate your objects, you can verify the stored proc was discovered by looking in the Data layer in the base directory for the TableNameProviderBase.generatedCore.cs in the Custom Methods region.

I've been stuck in build hell for a week but now back to code. I want data that would normally be a JOIN between two tables. It's a join between ProfileProperties and UserProfileValues. But since I'm using NetTiers for my middle tier and I just want to get going, I'm writing a subpar GridView. The first column is pulled from a select of all profile properties provided by my ProfileDataSourceObject given to me by NetTiers. The second column is a function with a param of the profile property. The function grabs the user from the context and the profile property from the param, then determines what (if any) value has been set. This is not how I should do things. And since I usually don't do it this way, I'm sort of having to relearn some aspx syntax on how to do this.

I much prefer to have SQL return this data and just format it in the GridView. SQL doesn't change everytime Microsoft releases a new version of Visual Studio.

How would you do this?