In response to the previous posting.  James Arendt has comment the final word:

static internal String AredntWay(String[] list)
{
   return(String.Join(',',list));
}

Thanks James Arendt!

{6230289B-5BEE-409e-932A-2F01FA407A92}

C# .NET 3.0 has anonymous types, since I am working on some legacy projects I have the experience of using anonymous types already in VBScript.  Remember classic ASP? Not having to Dim your variables, and being able to assign a variable to an int, then a string.  Has it been so long ago that you forgotten all the fun you have had with anonymous types in classic ASP?

I have a project that is classic ASP and SQL Server, if we change the SQL Server column (i.e. rename it or change the type) we have to scan the classic ASP (Find In Files) then make the changes to all inline SELECTS, UPDATES, and DELETES.

So then we got smart and changed to stored procedures, now if the type changes the stored procedures doesn't compile, easier to find places that need to be changed, however we had to adjust the classic ASP to handle the new type as an output -- really not a problem becuase all VBScript is anonymous types. 

So then we got really smart and used ASP.NET CLR 2.0, a class library to talk to our database, and SQL Server.  We generated the class library from CodeSmith using the database schema as a template for the library.  Now we are doing really good.  If the database type changes, the class library changes (we regenerate it), and any code behind that is calling the class library will break becuase of the type change.  Strongly typed language how nice.

Now we have LINQ -- back to anonymous types, we can jump on the bandwagen and rewrite all our code behind to call LINQ.  Now if we make a database change we are back to find In files.  Full circle to our VBScript days. Yippee.

{6230289B-5BEE-409e-932A-2F01FA407A92}

My virtual dev server was running out of hard drive space. Wayne’s preferred solution was a new and different dev server. I called him a few days ago about a build problem but I don’t remember what that was. He dinked with my solution. One of things he turned on was signing. I didn’t notice and at the time everything kept building. But I needed to move to the new server. The major apps were installed. I just needed to move all my VS projects, and whatever else I had on the old server. This part is the drudgery. Move everything and then see if it builds.

Well it built but I didn’t notice that my business object dll wasn’t getting moved up to the web site. So the ObjectDataSource wasn’t finding my new class methods for the business object. Of course, I didn’t figure that out immediately. I thought the docs for the ODS were just missing something. Wayne looked at the project and couldn’t figure out how to solve the problem immediately because of the type of project I had for the web server. He was used to dealing with Web Application projects that look and feel more like Windows application projects. I didn’t know that I had an old-style web project instead with the app_code directory.

In order to fix the problem, I tried to move the files of the project into a Web Application project. No nothing built. It started saying I needed signed dll’s for two specific 3^rd party libraries (assembly generation failed ... does not have a strong name). I knew I didn’t so I waited until Wayne came home from Tamales class. He had set the signed setting in order to fix the original problem of getting the object into the GAC, however gave up when he realized I was referencing third party object that also needed signing. The business object built but the web application didn’t. The new project type didn’t know anything about app_code so those files were moved into a new Classes directory off the root of the web application project. The next project was that the .aspx files couldn’t find those classes so we had to put the classes into a namespace. This meant all code files regardless of type were now in the same name space for both the business object library and the web application project. Next problem was that the controls on the aspx.cs pages were undefined or some error like that. We had to “convert” the web project files so that the “.designer” page was behind as well. Then we changed each “.designer” code page to also be in the same name space as everything else. Once that happened, the whole solution built.

I'm working on the infrastructure for a new web site. Lots of data layer so I can test. But I don't want to spend loads of time with the UI for insert/update/delete from an admin standpoint. Sure the UI for customers will get plenty of time but my own interface can be functional but not pretty. I already have robust classes for the data layer. Do I build my own pages with calls to the data layer in the code behind? I want to remove as much testable code from the UI (aspx and aspx.cs) as possible. So I'm going to try to use the GridView with a DataSourceObject. Make the GridView and ObjectDataSource do most of the work since they are far more tested than any UI code I could write.

That's my logic anyway.

I have a friend who is constantly saying he can write code much faster by configuring the various data controls with the SQL insert, select, update, and delete statements. I tried this. It is true the page was much faster built. A few clicks, a few typed attributes. However, and this is a big however, that style of coding makes several assumptions. Under each assumptions, I'll also list why I think a middle layer needs to exist between the GUI and the database. For those of you who are laughing that I even need to make this argument, beware what project you take over. Look at the code first.

you configured the controls correctly the first time

   In order for the process to truely be fast, you can only touch it once. With a code library, you can easily grow the middle layer to suit all your needs without having to retouch that page using a data control.

you don't have any need to use that code again in that web app, ever

   Whatever you write is what the user, admin, etc see - one interface only. I know this is bogus but it's the only thing that backs up a "much faster" arguement. With a code library, you can have as many views into the data as you need. But, yes, you do have to write that code.

you don't test your code beyond it's first unit test

   In order to test this type of code, it's either by hand or a high-end gui/web tester. With a code library, there are several tools to unit test including nUnit or it's new version xUnit. Once you have the unit test, you can run your tests against every build. The unit tests will find error before your customers do - which is so much nicer.

no one else will ever touch your code

   Few decent programmers would work this way. It says you are lazy and work alone.

those controls will never change or be removed

   In order to get the full benefit of time savings, it has to live for the life of the project. However, with the middle layer, the logic can live beyond that app to any other app or variant. Of course, you could totally munge the library into a piece of #$% but both approaches assume the design skills are solid.

The one newsletter that arrives in my inbox that is bound to perk me up anytime is from http://www.sqlservercentral.com/. It is sort of an older style newsletter but the contents are great. The editorials (yes, there are editorials) are also great. The main articles might not be right for me at the time but then there is the question and the community-submitted help code as a featured script.

In response to the previous posting. A few weeks ago, I would certainly have solved this the same way that you did in "OldSchool" with the exception of using IEnumerable<string>. Why limit your code to just string arrays? Now that we have LINQ, we can get pretty fancy! Technically one line within the method but I split it up to aid readability.

static void Main(string[] args)

{

    string[] names = new string[] { "Andy", "Marcy", "Cindy", "Jennifer", "Aaron" };

    Console.WriteLine(NewSchool(names));

}

static string NewSchool(IEnumerable<string> list)

{

    return list.Aggregate(new StringBuilder(),

        (sb, n) => sb.Length == 0 ? sb.Append(n) :

         sb.Append(",").Append(n),

        sb => sb.ToString());

}

And for even more fun, I built a simple test harness for each of these three methods. The test: 10000 itterations where I concatenate a string array that contains 8192 elements. Junior ran 36 minutes and 41.5 seconds*. OldSchool ran 8.453 seconds. NewSchool ran 9.484 seconds. NewSchool is likely slightly slower than OldSchool because of the use of the delegate. * I was only able to run 100 itterations on Junior which ran 22.015 seconds. I then extrapolated from there. The actual result would likely be even longer given its use of memory.

Creating a comma delimited string from an array came up yesterday, here is a couple of methods, one from our junior developer and one that I did.  I entitled mine old school, because of the C coding that shaped my programming.

static internal String Junior(String[] list)
{
    String output = String.Empty;

    foreach (String item in list)
    {
        output += item + ",";
    }

    output.TrimEnd(',');

    return (output);
}

static internal String OldSchool(String[] list)
{
    StringBuilder output = new StringBuilder();

    foreach (String item in list)
    {
        if (String.IsNullOrEmpty(item))
            continue;

        if (output.Length > 0)
            output.Append(",");

        output.Append(item);
    }

    return (output.ToString());
}

Which one do you like?

{6230289B-5BEE-409e-932A-2F01FA407A92}

I have several reasons not to use open source and I will be posting all in short order.  By open source, I mean a free assembly I can get on the web that includes the source, usually a development tool that is build by a group of people.

For some time I have been debating weather to use open source projects for my C# programming, or to buy professional components.  By debating, I mean thinking about, trying, and experimenting with both -- however now it is time to put my ideas to paper and share.  Disclaimer: in a year I might change my mind, or a posted comment might change my mind.  However here is one tought to chew on:

We reference assemblies so that we can gain functionality without having to code the funtionality ourselves.  Microsoft provides some great functionality in the CLR and it allows us to make significant gains in productivitiy by not making up write the stuff in the CLR.  However, if Microsoft is missing the functionality and it isn't specific to your vertical or product -- there is a tendency to get the functionality from the web as a open source project.  I tend to get the source, recompile it and make it a project within my solution, instead of using the assembly already compiled -- this can be a whole other discussion.  Ok, to recap: I reference an assembly from the Internet because I don't want to write the code myself.

However, it is my experience that the open source projects are very buggy, which leaves me fixing them to get them to work.  Which means I am coding in someone elses code just to get the thing to work correctly.  If I purchased a professional product, I could just write customer support, provide a reproduction, and get a fix.  Which leads me to reason #1: There is no support, I would rather buy (and I mean have my company buy) a $1000 per license product and get support for bugs then fix and worry about the open source.  

Just to drive the point home, even popular projects like ICSharpCode.SharpZLib have bugs, I just fixed three of them.  And, no I am not going to submit the changes to the open source project -- it takes to much time, they will not like my changes (since I patched it and didn't fix it like I would my own code), and usually those developers are hard to reach (hiding from doing customer service) and snobby (not SharpZLib in paricular just open source developer in genderal).

{6230289B-5BEE-409e-932A-2F01FA407A92} 

This was Wayne Berry's presentation about real-world crypto coding for web sites. The presentation was identical to his asp.net user group presentation. He stayed calm with 15 minutes of Digipen equipment not working and two room switches. But it was a great presentation and the level of detail and code was just right. He said he will post the presentation here at some point.

This presentation was given by Zlatko Michailov & Asad Khan, PMs, Microsoft ADO.NET. The best thing said in the entire presentation was that if your model is well built you shouldn't have to do any group bys or joins. Drink the kool-aid, swallow the pill, enjoy that illusion in a real-world situation. Especially some piece of $%^@ database that is mission critical and the data is 10 years old, not normalized, and some one else's baby. But if you are going to dream, dream big, right?

Their blogs can be found at: http://blogs.msdn.com/esql/. E for entity. Why be normal? right?