2005 2006 2007 2008 2009 2010 2011 2015 2016 2017 aspnet azure csharp debugging elasticsearch exceptions firefox javascriptajax linux llblgen mongodb powershell projects python security services silverlight training videos wcf wpf xag xhtmlcss

Gosh I hate SPs/SQL (a.k.a. LLBLGen Rocks!)

...well at least in my C# code. That stuff belongs in the world of reporting, integration services, and other places which are NOT IN CODE. You couldn't get me to use ADO.NET anymore; it's such a pain for large projects. I love it for mass importing and when I do extremely dynamics such as report generation and a few other things, but for a static data access teir it's PATHETIC.

Not only is everything you type not strongly typed and therefore prone to error and has no color syntax; SQL (including SP calls) is just abrupt. You are doing this beautiful array of C# 2.0 greatness. Generic collections all over and BAM you see "select * from Person where..." Yuck!

Long live LLBLGen! If you don't know what LLBLGen is, you are completely missing out. I've been using it for months on all my projects and it's just downright awesome. It's basically LINQ...NOW. It allows you to use strongly typed .NET code to access your data WITHOUT writing any data tier code yourself. Not only that, the full blown enterprise edition is only $300. There is NO reason to ever write any data access layer yourself. It will pay for itself in about a DAY. I recommending getting a copy of LLBLGen even for your HOME projects!

All you have to do is point the LLBLGen app to the database, select the tables (and other entities) you want, and hit generate. It automatically creates a Visual Studio 2005 (or 2003 if you HAVE to use that icky thing) project for you. You can either include that project into your solution or compile the assembly and just us the compiled files. You only need to use LLBLGen again when you schema changes, which, as every architect knows...shouldn't be happening that often.

This rant is brought to you by the following sponsor...

DataSet dataSet1 = new DataSet( );
SqlDataAdapter sqlDataAdapter1 = new SqlDataAdapter( );

SqlConn1 = new SqlConnection(connString);
SqlConn1.Open( );

SqlCommData = new SqlCommand("GetDraftBox", SqlConn1);
SqlCommData.CommandType = CommandType.StoredProcedure;

sqlDataAdapter1.SelectCommand = SqlCommData;
sqlDataAdapter1.Fill(dataSet1, "MailList");

return dataSet1;
I was porting this old app from .NET 1.x to .NET 2.0 and I kept seeing stupid garbage like this. I got SO sick of it I decided to disconnect the logic tier and connect it to the LLBLGen access layer. Here's what I have now...
DraftMailCollection draftMailBox = new DraftMailCollection( );
return draftMailBox;

THAT'S IT!!! Short, sweet, strongly-typed, intellisense LOVES it, it's pretty (you gotta LOVE the VS2005 color scheme), and it's VERY easy to extend.

As another quick example here's how you would translate the following code into LLBLGEN code. First, the SQL code...

select *
from Person
PersonUserName = username and
PersonPassword = password;

Now the LLBLGen code...

PersonCollection people = new PersonCollection( );
IPredicateExpression filter = new PredicateExpression( );
filter.Add(PredicateFactory.CompareValue(PersonFieldIndex.PersonUserName, ComparisonOperator.Equal, username));
filter.AddWithAnd(PredicateFactory.CompareValue(PersonFieldIndex.PersonPassword, ComparisonOperator.Equal, password));

Yes, joining is also BEYOND easy and, yes, it databinds to GridViews with no extra work. I use it all the time in my ObjectDataSources.

OK one last example... well two. This one should be the straw that breaks...something. Look at this ADO.NET code (I'll leave some of it out though)

sqlCommand = new SqlCommand();
sqlCommand.Connection = sqlConnection;
sqlCommand.CommandText = "insert into Customers (CompanyName, ContactName, ContactTitle, Address, City, Region, PostalCode, Country, Phone, Fax )values(@CompanyName, @ContactName, @ContactTitle, @Address, @City, @Region, @PostalCode, @Country, @Phone, @Fax)";
sqlCommand.Parameters.AddWithValue("@CompanyName", companyName);
sqlCommand.Parameters.AddWithValue("@ContactName", contactName);
sqlCommand.Parameters.AddWithValue("@ContactTitle", contactTitle);
sqlCommand.Parameters.AddWithValue("@Address", address);
sqlCommand.Parameters.AddWithValue("@City", city);
sqlCommand.Parameters.AddWithValue("@Region", region);
sqlCommand.Parameters.AddWithValue("@PostalCode", postalCode);
sqlCommand.Parameters.AddWithValue("@Country", country);
sqlCommand.Parameters.AddWithValue("@Phone", phone);
sqlCommand.Parameters.AddWithValue("@Fax", fax);


string id = (string)sqlCommand.ExecuteScalar();


Some would say that it would not look so bad if the insert was in an SP. Um, ok...so you want to code in more than one place? No thank you. Also, what happens if there is no id to return? I've noticed that .NET 2.0 doesn't like that too much.

Now heres the LLBLGen code...

CustomersEntity customer = CustomersEntity( );
customer.CompanyName = companyName;
customer.ContactName = contactName;
customer.ContactTitle = contactTitle;
customer.Address = address;
customer.City = city;
customer.Region = region;
customer.PostalCode = postalCode;
customer.Country = country;
customer.Phone = phone;
customer.Fax = fax;
customer.Save( );

string id = customer.CustomerId;

Yeah...wow. Not only that, but in the SQL code you also have to do all that ADO.NET stuff. Not with LLBLGen, it's all in one!

I've been using LLBLGen for almost a year now and I have to say that my productivity has SOARED because of it. LLBLGen + .NET 2.0 + Firefox is a smart, er..., GENIUS match that should not be ignored, but rather ran towards!

To get a 30-day trial copy of LLBLGen follow the below link. I'm sure you will love it and for only $300, your manager will as well.

trycatch in .NET 2.0 - Part 2

As I pointed out in a previous entry, try{}catch{} works differently in .NET 2.0 as it does in .NET 1.x. In 2.0, non-exception "throwables" are wrapped in a RuntimeWrappedException which can be caught by try{}catch(Exception ex){}, while, to catch then in .NET 1.x, you were required to use try{}catch{}. This led me to wonder 1) how does this work? and 2) is there even a purpose for try{}catch{} anymore?

So I started my research by... well, passing the buck, or going to the source, depending on your view on things. The first thing I did was ask Brad Abrams if he had some insights about this. He then forwarded me to Jonathan Keljo who I guess then forwarded me to Joe Duffy...sheesh what a line up! The best of the best of the best right there! Goodness, I feel like an ant...

Anyhow... here's the thing. Joe affirmed that there are at least two purposes for try{}catch{} in .NET 2.0

Here are his exact words...

(1) If your assembly doesn't have "wrapping" turned on;

(2) If you don't care to access the exception information via a variable. This can help to reduce the temptation to accidentally do a catch(Exception e){ /*...*/; throw e; } when you meant to do catch { /*...*/ throw; }.

OK cool, now what about the mechanics? Joe explains that the wrapping of RuntimeWrapperException around non-exception throwables is due to the fact that C# and VB auto opt-in all assemblies to what they call "the wrapping plan". This means there is a RuntimeCompatibilityAttribute(...) on the assembly where, in this case, WrapNonExceptionThrows=true is set. When this is the case all non-System.Exception "exceptions" get wrapped into a RuntimeWrappedException, which, as Joe points out of course does inherit from System.Exception. Conversely, if WrapNonExceptionThrows=false is set, then there is no magical wrapping.

Let's see this all in action. But before we do, last time I wrote about this I forgot to what mention happens when you compile the below code (this is the same code from the previous blog entry about this topic)

// ThrowerHarness.cs
namespace ThrowerExample
    class ThrowerHarness
        static void Main(string[] args) {
            try {
                Thrower.ThrowException( );
            catch (System.Exception ex) {
                System.Console.WriteLine("System.Exception error: " + ex.Message);
            catch {
                System.Console.WriteLine("Non System.Exception based error.");

            try {
                Thrower.ThrowString( );
            catch (System.Exception ex) {
                System.Console.WriteLine("System.Exception error: " + ex.Message);
            catch {
                System.Console.WriteLine("Non System.Exception based error.");

Compiling this code actually gives the following warnings...

throwerlib.cs(16,7): warning CS1058: A previous catch clause already catches all
        exceptions. All non-exceptions thrown will be wrapped in a
throwerlib.cs(29,7): warning CS1058: A previous catch clause already catches all
        exceptions. All non-exceptions thrown will be wrapped in a

As you can see, we know at compile that try{}catch(Exception ex){} will grab the exceptions.

Here's the IL we are using, which contains the Thrower class and is referenced by the C# application.

// ThrowerLib.il
.assembly ThrowerLib { }

.class public Thrower {
    .method static public void ThrowException( ) {
        ldstr "ThrowException exception from the IL world!"
        newobj instance void [mscorlib]System.Exception::.ctor(string)

    .method static public void ThrowString( ) {
        ldstr "Weird exception!"

Of course, there's our command syntax...

ilasm /t:dll ThrowerLib.il
csc Thrower.cs /r:ThrowerLib.dll

After a successful assembly and compilation, running this application gives the following output...

System.Exception error: ThrowException exception from the IL world!
System.Exception error: An object that does not derive from System.Exception has been wrapped in a RuntimeWrappedException.

Now, what about what Joe was saying about the RuntimeCompatibilityAttribute? Well, if we were to tack the following onto our existing class, we would get absolutely no warnings. Pretty cool...

using System.Runtime.CompilerServices;
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = false)]

Not only that, but here's the output as we would expect.

System.Exception error: ThrowException exception from the IL world!
Non System.Exception based error.

As you can see it did not wrap the exception. So, now, the picture of how things work and how to modify them is a bit more complete.

You can download the code for this entry by the link below.

Joe Duffy also has an explanation of this, although his is from the Beta 2 era (I only see one change -- WrapNonClsExceptions -> WrapNonExceptionThrows; but there may be more). Here is his article.

Indigo Girl

OK, everyone interested in WCF needs to stop what they are doing and head on over to http://www.thatindigogirl.com/. Michele has posted chapters to her up amazing, soon-to-be-released WCF book up there. Not just that, but there are a few things that really impress me.

First off, she has to be my new technology role model (move over Brad Abrams and Andrew Trolsen) as she to be the highest ranking MVP in the world. Sheesh, just go look at her profile at http://www.idesign.net/.

Secondly, she's probably the best writer I've ever read. Picky doesn't even begin to describe me. If I don't consider the author absolutely outstanding, I don't bother flipping the pages. She is one of the very few people I can actually put up with. Her bypassing of the silly Hello World example for a more useful one was very respectable and it demonstrated to me that she wants to get right to the point (in turn this shows technical security; insecure writers have SO padding and PCness!)

Third, she seems to be a bottomless pit of powerful and useful training. Today was the first time I read her work and in the first 30 pages of her book I was able to overcome a load of WCF obstacles I was hitting with the go-live version.

Fourth, she has a very beautiful website. Not that she did it, but it does show that she cares about her environment. It rather bothers me when my fellow architects feel the need to go all hardcore and boring on me. She seems to be immune to that. Um...yes, I rate my favorite architects by more than their technical skills!

I swore to only buy book from Abrams and Troelsen, but I'm going to pre-order her book...something I've never done before. I'm extremely impressed with her work. Seriously, go check her blog, website, and book out!

Brainbench C# Fundamentals Technical Editor

What a week... I finally finished my gig as Brainbench technical editor (they called it an exam "cleaner") for the C# Fundamentals exam. Apparently they were extremely impressed with my work. Where others write a small comment line, I would write a page or so about the question and the answers citing the ECMA standard and anally explaining the improper wording of something.

I'm also rather kicking myself for turning down another gig they offered me. After I finished with this gig, I was offered the gig to write the VB.NET 2005 exam. My initial justification to myself for rejecting it was for the same reason I wouldn't write an Internet Explorer exam: it's no different than devil worship. Now I wish I took that gig, because even though the vbc.exe compiler packs a TON of useless garbage (you ever look at that stuff? A ton of odd Microsoft.VisualBasic references) in the assemblies, it's still IL! .NET is .NET! In any case, I did tell my rep there that I want to be on the list for any C# 2.0, CLR, or .NET 2.0 framework exams! We'll see!

March 2006 WCF Resources

Heres just an update on the popular resources on WCF on the web.

Some links worth looking at...

Here's a list of the video Mike has up at the MSDN Nuggets website (link above).

  • "Hello World"
  • Type Serialization
  • DataContract Serialization
  • Typed and Untyped Messages
  • Bindings
  • Message Encoding
  • Message Patterns
  • Sessions
  • Instancing
  • Concurrency
  • Exceptions
  • Transactions
  • HTTPS Transport Security
  • Message Security
  • Authorisation
  • Auditing