Partial Classes and Inheritance

Since VS2005 created the ability to use partial classes, the feature has been available to developers across the .NET community.  This post is to provide a quick description of using inheritance and an example I found it to be particularly useful.

According to Microsoft, partial classes are most useful in these scenarios:

  • When working on large projects, spreading a class over separate files allows multiple programmers to work on it simultaneously.
  • When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when creating Windows Forms, Web Service wrapper code, and so on. You can create code that uses these classes without having to edit the file created by Visual Studio.

So by excluding bullet point #1 because I don’t agree with it (any source control system, even VSS, should facilitate this), we’re pretty much left with code generation.  The main reason partial classes were created is in order to allow part of a class to be regenerated via CodeGen and not have that blow away other code you have added since generation.

I recently found this helpful in working with an industry standard XML definition called WITSML.  We wanted to have C# data objects defined by the XML schema provided by the standard.  However, we also wanted to have these objects decorated with certain features that allowed the objects to fit into our overall data integration architecture.  In order to accomplish this, we simple created a matching partial class definition where we inherited from our base class and added any additional functions we wanted to have in the item.  I would provide some code samples, but this walks the line on some intellectual property issues since the concept belongs to my employer, so I’ll leave it up to your imagination  🙂

An interesting facet of the inheritance capability and the differences between C# and VB is discussed by Cory Smith on his blog.


Updating WCF Service Descriptions

I have been reading Michele Leroux Bustamante’s book on WCF as this is a topic that has been very interesting to me lately.  She has been a guest on .NET rocks and other interesting podcasts several times, and her jovial personality on air intrigued me as to what her books would be like. 

Her book (so far) is great, and I feel that I have learned a lot from the lab examples that walk you though creating host and client solutions that gradually move from the simple to the real world.  I would highly recommend this book, especially if you want to understand all aspects of WCF including security.

Call to SSPI Failed

While going through the labs in chapter 2, I received the following unhandled SecurityNegotiationException:

A call to SSPI failed, see inner exception. 

 InnerException text read:

The Local Security Authority cannot be contacted

The bummer part was that I was on a plane and couldn’t search for what the heck this error meant.  Additionally, I do not have MSDN installed locally, so I was dead in the water.

After arriving at my destination, I posted a question on the MSDN forms (which it turns out Bustamante is the moderator for!) to see if that would provide an answer.  Unfortunately I didn’t give anyone enough time to respond as the answer came in analyzing what is happening when you add a service to your project.

Update Service ReferenceMy first thought was to update the service definition once I got connected to the Internet again.  Maybe my cached credentials woud somehow get jarred and things would start working.  It was a shot in the dark, but worth trying.  So I used the handy right-click option to refresh the reference of my WCF service.  While watching the output window, I noticed that there were 2 files being generated when I would have only expected the single .cs C# file:

  • localhost.cs

  • newapp.config

Since I figured at this point the problem must be in the config file, I looked to see what exactly was in the app.config file of the GigEntry project.  Sure enough, there was an XML element called <identity> that had my domain and username baked into it (seemingly from the CodeGen associated with the proxy).  Here is an example of what the configuration section looked like:


          <userPrincipalName value=<domain>\<username> />


I am not exactly sure what the ramifications are, but I do know that deleting that section allowed the example code to work.  Maybe Michele will reply to my post with some more info? Only after knowing what some keywords to search on were did I find some other interesting reads such as:

Do Not Use the StringBuilder

I know there are plenty of people out there that will disagree with me, but I urge you to not use the .NET StringBuilder class in 99% of the cases you would be tempted or recommended to do so.  Here is why:

 The StringBuilder class does perform better than basic string concatenation.  However, it is really only noticable with ridiculous string lengths.  For example, if you are concatenating a SQL statement together for a statement that has less than 100 columns, the difference will be negligible.  Slamming 10,000 strings puts StringBuilder as the clear winner in time as it will shave about 2 tenths of a second off of your processing time.

Testing In Progress

I ran some tests, and comparing a basic concatenation to using a string builder to slam together 100 “A” characters is a wash.  Sometimes the StringBuilder even took longer.  At 1000 characters, StringBuilder was a slight winner.  Of course this amounted to about 20 milliseconds on average.  Unless you are doing a lot of concatenation, this won’t really be a noticable difference… and we are already talking about 1000 operations!

Below are the results of my test (click on thumbnail) that were not posted on my original rant, but have since been added to this post.  You can see the strings of varying lengths I used as well as the number of concatenation operations that were performed on each.  The “Total String Length” column represents the overall lentgh of the resulting string after all operations are complete.

The Results of My Tests

As you can see, nothing short of  millions of resulting characters or tens of thousands of concatenation operations ends up in response time that is over 1 second.  Looking at a typical operation in my world such as concatenating a SQL statement together, we would be dealing with something like rows 9 and 10 of the above table.  These tests took the string “AND COLUMN1 = ‘VALUE’” and concatenated it together 1,000 times.  Although this would still be a ridiculously long SQL statement (and probably perform horribly :)), the difference between using a StringBuilder (193 ms) and simple concatenation (214 ms) is only 41 milliseconds difference.  Yes, I realize that is about 20%, but again, if you are doing this concatenation many times, you may need to write your own custom object to meet your true needs.  Another interesting find is that the # of operations seems to have a much bigger impact than the overall length of the string itself.

Yes, it is terrific that somebody at Microsoft realized working with a collection (string) of hundreds of thousands of members (characters) will not perform will if it is not indexed.  No kidding!  But who in their right mind will be dealing with strings of 500,000+ characters?  If you are doing that, then you probably need to rethink your approach to solving the problem at hand.

 Because of the added complexity, additional lines of code, developer ramp-up possibility (for those not exposed to the class or .NET) and risk of change in future versions of .NET, I say you should not use the StringBuilder class… unless, of course, you find yourself needing to deal with that all to common million character string 🙂