Sunday, May 27, 2007

In terms of keeping this blog up-to-date on my goings on, the month of May has been a dismal one.  There has been a lot going on, but I've simply not made the time to log my activities and/or code snippets and it's eating at me.

Recently, I've been writing some code that needed to run in response to certain activities that would be triggered by another application.  These applications would not be connected, per se, in the sense that one would 'hook' into the other and respond to events.  Rather, one application would set a flag, send a message, etc such that the second application would recognize the notification and run some activity in response.

The logical choice for such an architecture is a messaging-based system.  In this case, I decided upon MSMQ/Queued Components and boy am I happy about that!  I hadn't seriously worked in MSMQ for years (though I used to do quite a bit of it) and it was fun to romp around my old playing grounds, but now with a .NET engine helping out.  Tons of fun!

This particular application is structured such that I have a web-based application (ASP.NET in this case) that will send certain messages to a message queue when the user completes some task.  Then I have a Windows Service running that will read messages from the queue and run a configurable response.  As part of the setup, I have written a few installer classes that will 1) create the message queue and 2) install the Windows Service and 3) run it automatically after install.

The task of creating a message queue installer is quite simple and straightforward.  I wanted my installer to detect the existance of the queue and create it if it wasn't found.  Upon rollback or uninstall, the queue would be deleted.  Here's an example from the Install method of my Installer class:

public override void Install(IDictionary stateSaver) {
   base.Install(stateSaver);

   try {
      const QueueName = @".\Private$\TestQueue";
      if ( !MessageQueue.Exists(QueueName) ) {
         MessageQueue queue = MessageQueue.Create(QueueName, true);
         Trustee trustee = new Trustee(@"NT AUTHORITY\NETWORK SERVICE");
         MessageQueueAccessRights rights = MessageQueueAccessRights.FullControl;
         MessageQueueAccessControlEntry ace = new MessageQueueAccessControlEntry(trustee, rights);
         queue.SetPermissions(ace);
      }
   }
   catch ( Exception er ) {
      // log the error to the event log
      throw;
   }
}

At this point, I'm ready to start interacting with the message queue by sending and receiving messages.

To simplify this process and to make it more structured, I decided to create a simple class called QueueItem.  This class provides the structure and data needed by the recipient application so that it can effectively run in response to the website's activity.  This class is also decorated with the appropriate attributes that enable it to be serialized to XML.  To further simplify the process of interacting with the message queue, the QueueItem class contains a method that allows the caller to send the message to the queue; all of the logic necessary is enclosed therein:

[XmlRoot("queueItem")]
public sealed class QueueItem {
   public QueueItem() { /* parameterless ctor for serialization support */ }
   public QueueItem(string id, string action) {
      _id = id;
      _action = action;
   }

   private string _id, _action

   [XmlElement("id")]
   public string Id {
      get { return _id; }
      set { _id = value; }
   }

   [XmlElement("action")]
   public string Action {
      get { return _action; }
      set { _action = value; }
   }

   public void SendToQueue(string label) {
      QueueItem.SendToQueue(this, label);
   }

   public static void SendToQueue(QueueItem item, string label) {
      MessageQueue queue = new MessageQueue(@".\Private$\TestQueue", QueueAccessMode.Send);
      queue.Formatter = new XmlMessageFormatter(new Type[] {typeof ( QueueItem )});

      using ( MessageQueueTransaction trans = new MessageQueueTransaction() ) {
         trans.Begin();
         queue.Send(item, label, trans);
         trans.Commit();
      }
   }
}

The Windows Service, now, is responsible for watching the queue and running the appropriate response to messages that find their way into the queue.  To accomplish this, I decided to have the service spin off a secondary thread at start up.  It's this thread that is responsible for processing messages off of the queue.

protected override void OnStart(string[] args) {
   try {
      Thread th = new Thread(new ThreadStart(processMessages));
      th.IsBackground = true;
      th.Name = "QueueListener";
      th.Start();
   }
   catch ( Exception er ) {
      EventLog.WriteEntry(Service.ActualName,
                          string.Format("Unable to start service\n\n{0}", er),
                          EventLogEntryType.Error);
      this.ExitCode = 1;
      this.Stop();
      return;
   }
}

private void processMessages() {
   try {
      using ( MessageQueue queue = new MessageQueue(@".\Private$\TestQueue", QueueAccessMode.Receive) ) {
         queue.Formatter = new XmlMessageFormatter(new Type[] {typeof ( QueueItem )});

         while ( true ) {
            using ( MessageQueueTransaction trans = new MessageQueueTransaction() ) {
               trans.Begin();
               Message msg = queue.Receive();
               trans.Commit();
               QueueItem item = msg.Body as QueueItem;
               if ( null != item ) {
                  EventLog.WriteEntry(Service.ActualName,
                                      string.Format("Message received: {0}, {1}", item.Id, item.Action),
                                      EventLogEntryType.Information);
               }
               else {
                  EventLog.WriteEntry(Service.ActualName,
                                      string.Format("Invalid message datatype received: {0}.  Expected: QueueItem.", msg.Body.GetType().FullName),
                                      EventLogEntryType.Warning);
               }
            }
         }
      }
   }
   catch ( Exception er ) {
      EventLog.WriteEntry(Service.ActualName,
                          string.Format("Critical shutdown\n\n{0}", er),
                          EventLogEntryType.Error);
      this.ExitCode = 1;
      this.Stop();
      return;
   }
}

The beauty here is that I don't have to poll.  Rather, I have the background thread call .Receive() on the queue.  This will effectively block the thread indefinitely or until a message is pushed into the queue.  At that point, it unblocks and begins processing the message.  Once finished it calls .Receive() again.  If there's a message, it gets processed, if not, it blocks.  And thus the cycle repeats itself.

Using MSMQ can be very rewarding and a lot of fun, and this little project has reminded me of that fact.

Sunday, May 27, 2007 6:51:00 PM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [2]  |  Trackback
 Tuesday, May 15, 2007

I have a very small utility application that I wrote that takes an XML string and submits it as a query against a web service, displaying the result.  Very simple, and just for testing purposes.  There are times when the XML string that I want to use as the web service query is encoded.  That is, it's littered with &lt; and &gt; strings in place of the XML '<' and '>' respectively.  Were these strings succinct it wouldn't be a big deal, but there are times where the query string is several thousand characters.

In the past I've resorted to opening a text editor and performing a find/replace on each of the escaped sequences, and then copying and pasting the result into my application to run the test.  Simple but cumbersome.

Well, I finally got tired of jumping through those hoops and decided to make the application a bit smarter in that I wanted to have it identify when encoded XML was being pasted into it, and have the application automatically format the result performing the string replacements automatically.  This is quite trivial, but I wanted to share the result as it may be informative.

My 'algorithm' for determining whether the text being pasted is in fact XML is quite rudimentary and basic, but it suffices in this instance.  I'm simply checking for '&lt;' at the start of the string.  If that sequence is found, it determines, hey, this is an XML string, and attempts to perform the replacement.

It occurred to me as well while writing this that XML isn't the only format that I may want to custom-paste into a TextBox.  Therefore, I abstracted the code such that you can write your own special formatting code and simply 'plug it in' to your application.  NOTE: I did NOT want to derive from the TextBox to create a special 'CustomPasteTextBox' control as that would further restrict its usefulness.

The base class (which I called PasteFormatterBase) takes a TextBox and a callback.  The operation is wrapped within a NativeWindow-derived SubClasser class; when the WM_PASTE message is received, a call is made back out to the callback to handle it.

public abstract class PasteFormatterBase {
   public PasteFormatterBase(TextBox txt, MethodInvoker callback) {
      _subClass = new SubClasser(callback);
      _subClass.AssignHandle(txt.Handle);
   }

   private SubClasser _subClass;

   private class SubClasser : NativeWindow {
      private const int WM_PASTE = 0x0302;
      private MethodInvoker _callback;

      public SubClasser(MethodInvoker callback) {
         _callback = callback;
      }


      protected override void WndProc(ref Message m) {
         if ( m.Msg == WM_PASTE && null != _callback ) {
            _callback();
            return;
         }

         base.WndProc(ref m);
      }
   }
}

Then, the class that performs the actual XML decoding of the string is quite simple:

public sealed class PasteXmlFormatter : PasteFormatterBase {
   public PasteXmlFormatter(TextBox txt)
      : base(txt,
             delegate {
                   IDataObject obj = Clipboard.GetDataObject();
                   string data = obj.GetData(DataFormats.Text) as string;
                   if ( null != data && data.StartsWith("&lt;") ) {
                      data = data.Replace("&lt;", "<").Replace("&gt;", ">");
                      txt.SelectedText = data;
                   }
                })
   { }
}

There may be better ways to write this (it's just a quick first pass), but it's elegant in its simplicity.

Tuesday, May 15, 2007 8:15:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Friday, May 04, 2007
 For the waffle and computer lover in me, this may be just the thing I need.  Why couldn't have this been made earlier?
Friday, May 04, 2007 6:00:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Wednesday, May 02, 2007

<grin>I've had a lot of free time lately.  So much, in fact, that I don't know what to do with myself.</grin>

With this copious free time I've dabbled a bit in Subversion.  I'd experimented with it before, but not on a grand scale.  In fact, I've used SourceSafe (which in my experience isn't as bad as people would have you believe), SourceGear's Vault (which I use presently and absolutely love), and I've experimented a bit with CVS, Perforce, et al.  I've been very impressed with Subversion and thought I'd give it a whirl for all of my personal software development.  If nothing else, I get a good, rock-solid SCM system and a more well-rounded understanding of this other system.

Thus, with that in mind, I set out to establish a new source code control system.

First of all, I downloaded the current version (version 1.4.3) and installed it on my server.  This gave me the %ProgramFiles%\Subversion folder and added the %ProgramFiles%\Subversion\bin folder to my path.

Next, I don't ever have to want to logon to that server interactively just to start the application 'listening'.  So, I set it up as a service with the following command line:

sc.exe create svnserve binpath= "C:\Program Files\Subversion\bin\svnserve.exe --service --root C:\SVN" displayname= "SubVersion" depend= tcpip start= auto obj= "NT AUTHORITY\NetworkService"

(Note that there is no space before the equal sign for each parameter but there is one afterwards.  Personally, I think this is a silly construct for the sc.exe command, but maybe it made the command line easier to deal with.  Oh well, I didn't write it)

That statement will register the svnserve.exe application as an NT Service so in the event that I have to restart the server the service will automatically start.

Next, I created the root folder for my repositories (which for purposes of this example is C:\SVN) and granted the NT AUTHORITY\NetworkService account the appropriate rights to it.

The very first thing that I didn't really care for with respect to Subversion was the way it does authentication.  I wanted to have a single source for all authentication and not maintain it for each repository.  While not a show stopper, I don't like the idea of having to change n passwd files (one for each repository) in the event my password changes.  Now that I mention it, I don't like the idea of having to put it in a file at all (especially in clear text!) - there are oh so many security issues with this.  I have seen some articles on how to set it up to use Windows Authentication (which would be ideal in my situation), but I'm not that far along with it yet.

Nonetheless, I set up a simple folder named “C:\SVN\(auth)” to hold the authz and passwd files (I like to use parens on folder names like this so they filter to the top of my directory lists and stand out).

I then edited the files accordingly:

authz

[/]
Aaron = rw

passwd

[users]
Aaron = xxxxxx

As is traditional with SCM systems (and in keeping with that tradition), each repository has three folders: \trunk, \tags, and \branches.  However, when you create a repository those don't get created automatically for you.  Rather than always remembering to create these for each repository, I created a template folder called “C:\SVN\(template_repo)” which contains the structure and helper files for new repositories.  In addition to the folders there's a simple svnserve.conf configuration file that is designed to replace the automatically created svnserve.conf file in each new repository and point back to the (auth) folder.  That way, each new repository uses the same catalog of credentials.  Then I have a batch file that simplifies the creation of a repository and automatically imports the folder structure, replaces the files, and deletes extraneous ones.  I put this batch file in the root C:\SVN folder:

CreateRepo.bat

@echo off
if "%1" == "" goto USAGE

echo Creating SVN repository "%1".
svnadmin create "%1"

echo Establishing default credentials.
copy "(template_repo)\svnserve.conf" "%1\conf\svnserve.conf" > NUL
del "%1\conf\authz." > NUL
del "%1\conf\passwd." > NUL

echo Building folder structure.
svn import "(template_repo)\folders" svn://%COMPUTERNAME%/%1 --message "Initialize folder structure for repository." --quiet

echo Done.  "%1" repository created.
goto DONE

:USAGE
echo.
echo Invalid usage.  Please specify a repository name.

:DONE

I guess the last thing I needed to do to set it all up was to configure my backups.  There's not much point in having an SCM system without a good backup system in place.  Well, everything done to this point was done with a purpose.  I intentionally put everything in the C:\SVN folder to have a single point of reference for all repositories and file, and to simplify backups.  I can simply walk the directories therein and back them up.  If I add a new repository it's automatically included in my backups and there's nothing more to set up.

In the Subversion documentation they warn against simply 'copying' the repository tree or your backup might be completely invalid and useless.  Instead, you're recommended to run svnadmin.exe with the hotcopy argument.

I wrote a very simple VBScript (appropriately named BackupSVN.vbs) to take care of my backups.  I put this file one level out of the repository root (e.g., C:\ for this example).

Essentially the script file enumerates all of the directories, determining whether they are Subversion repositories or not.  For those that are, it runs svnadmin hotcopy.  For those that aren't, it simply runs xcopy.  All backups are then made to the \SVNBackup\SVN folder.  The script then executes WinRar to archive the tree into a date-stamped .rar file which is placed in the \SVNBackup folder.

Though it doesn't do it yet, I'll soon have this archiving the .rar files to a remote store (e.g., a network share) because a backup on the same physical drive isn't much good if the drive crashes.

BackupSVN.vbs

' ************************************************************************************

Dim fso, shell, f, root, fileName
Set fso = CreateObject("Scripting.FileSystemObject")
Set shell = CreateObject("WScript.Shell")
Set root = fso.GetFolder(".\SVN")

'
' copy each folder to the svn backup directory
'

For Each f in root.SubFolders
   if ( IsSVNFolder(f) ) then
      cmd = "svnadmin hotcopy ""SVN\" + f.Name + """ ""SVNBackup\SVN\" + f.Name + """"
   else
      cmd = "xcopy ""SVN\" + f.Name + "\*.*"" ""SVNBackup\SVN\" + f.Name + """ /I /E /Y /H"
   end if
   Call Exec(cmd)
next

'
' copy each file in the \SVN directory to the backup directory and archive it
'

fileName = """SVNBackup\SVNBackup (" + Replace(FormatDateTime(Date, 2), "/", "-") + ").rar"""
Call Exec("xcopy SVN\*.* SVNBackup\SVN /Y")
Call Exec("""%ProgramFiles%\WinRar\rar.exe"" a " + fileName + " SVNBackup\SVN\*.* /ep1 /r /df")
fso.DeleteFolder(".\SVNBackup\SVN")


' ************************************************************************************

Function Exec(cmd)
   Dim result
   Set result = shell.Exec(cmd)
   Do While ( result.Status = 0 )
      WScript.Sleep 100
   Loop
End Function


Function IsSVNFolder(folder)
   IsSVNFolder = HasFolder(f, "conf")
End Function


Function HasFolder(folder, name)
   Dim f
   for each f in folder.SubFolders
      if ( f.Name = name ) then
         hasFolder = true
         exit function
      end if
   next
   hasFolder = false
End Function

I simply set this VBScript to run nightly and I'm off to the races.

Wednesday, May 02, 2007 5:28:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [6]  |  Trackback
 Tuesday, May 01, 2007

Today was not a fun day.  Among the many tasks that I had to accomplish my primary development virtual machine decided to barf on me.  The system would boot but then the moment I attempted to run VS and load a project it would 'blink' off and reboot.  It did this twice and then decided to run a CHKDSK at the third boot.  This found several invalid file chains and ended up 'restoring' several files.

At this point, the OS wouldn't even boot, saying that the C:\WINDOWS\SYSTEM32\CONFIG directory was missing.  Great!  My next step was to run a repair from the Windows XP boot disk.  This ran fine (for a while) until it eventually crashed with an invalid memory address read.

The rest of my day was spent attempting to get my development files off of the VPC so I could move over (a.k.a., rebuild) another.  That, in and of itself, isn't a big deal - I have several base images to work with so I'm not worried.  Getting the files off of a VPC image turned out to be non-trivial.  There may be better ways to do this (and I'm open to thoughts), but here's what I did:

  1. Create a secondary, blank VHD (virtual hard drive).  I had to do this because VPC wouldn't let me mount a non-CD/DVD/ISO drive within the image and I couldn't share a folder between the VM and the host machine.
  2. Boot the VPC to the command prompt (I used an old Win98 disk cause it was laying around).
  3. FDISK to create a partition on the VHD.
  4. Boot to the XP Recovery Console (via the XP boot disk) - a step which we'll soon see was a waste of time.
  5. FORMAT D:\ /FS:NTFS
  6. At this point, I wanted to copy my ~\dev directory to the new VHD.  Well, as it turns out the XP Recovery Console doesn't allow XCOPY (even when referenced directly in the c:\windows\system32 folder) !! Even then, COPY doesn't allow wildcards nor directory copying !!  This completely, utterly baffles me.
  7. I then remembered my best friend in boot-time travails: Windows PE (Pre-installation Environment) Server Edition: boot to WinPE.
  8. Once I booted up to PE it was a cakewalk.  It's a good thing too, because manually copying 2490 files manually (one by one due to lack of wildcards in NTRC) would have been a nightmare.

Well, now I'm back up and running, but what a nightmare.

Tuesday, May 01, 2007 10:33:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Thursday, April 26, 2007

The other day I posed a question regarding the processing of data from a web service where the structure (i.e., the names and quantities of the fields) varies.  The fictitious example had us suppose that we wrote a component designed to plug into and consume the services of an application that may be installed across a wide customer base where each customer might customize (albeit indirectly) the results of the web service.  The web service, of course, would purely be an abstraction of the customer's customizations and business model.  For instance, a customer may decide to add a special/custom property to an 'Account' within the system that helps him track some aspect of the Account that isn't out-of-the-box.  This may, as a byproduct, affect the structure of the web service such that the new field is now present.

Part of our solution is to be accepting of such a change in structure in a manner that crosses any and all customer needs.  One customer may customize the heck out of an entity (such as Account) while another may make just a few changes.  Others will leave it alone entirely.  Our product must be able to operate on and affect any and all fields (including custom ones).

We discussed that there are some considerations to make in order to support this environment.

The question posed, then, was "How would you approach this problem?"  How would you design a system whereby you can consume all of the attributes of the entity (e.g., Account) across the board?

From within Visual Studio you can "Add Web Reference".  From the command-line (and my preferred mechanism) you use WSDL.exe.  Regardless of route you take (heck, you can even do it manually - I've done that in the past too), you'll end up with a proxy class with method calls to the web service and classes representing the various structured types that the web service exposes.

This isn't enough when you want to support a structure that will vary from implementation to implementation; the service won't have any inkling of any of the custom fields.

Alright, enough setup.  How would you solve this potential issue?

There are a couple of approaches worth investigating, each with their own varying degrees of complexity and control.  And probably many more that are eluding me and are simpler still.

First of all you can rewrite all of the traffic to/from the web service via a SoapExtension.  This approach may ultimately yield the greatest flexibility, but at the expense of a lot of work.  Essentially, with a SoapExtension you can inject your code into the web service pipeline and read, alter, or even rewrite completely all of the traffic to and from the web service before it is ultimately returned to you (or delegated on to another SoapExtension in the chain).  In fact, when I was first experimenting with this issue of dynamically structured data this was my first approach.  I have the history documented here if you're interested in reading more about it.

A second approach takes a different angle on this idea.  It involves defining a "bucket" into which all fields not formally defined within your proxy class are grouped.  To achieve this we must alter the generated proxy class by adding a custom field (note, don't re-gen the proxy class once you do this or you'll lose your changes).

Recall the original example:

[XmlType(Namespace="http://schemas.devstone.com/svc")]
public abstract class customer : BusinessObj {
   public string id;
   public string name;
}

Let's add our "bucket" and we'll call it "custom":

[XmlType(Namespace="http://schemas.devstone.com/svc")]
public abstract class customer : BusinessObj {
   public string id;
   public string name;
   [XmlAnyElement()] public XmlElement[] custom;
}

This very small change is what works the magic for us.  The XmlAnyElementAttribute identifies that the "custom" member will represent any XML elements within the results from the web service that don't have a corresponding member in the object.  That's pretty cool.

Ok, this is only part of the problem.  This gives us the ability reference potentially anything that the web service may throw our way, but how do we make use of this in our application?

I like to define a wrapper class for the object that encapsulates the business object:

public sealed class DynamicObj {
   public DynamicObj(BusinessObj busObj) {
      _busObj = busObj;
      _busType = busObj.GetType();  // cache the type for repetitive use
   }

   BusinessObj _busObj;
   Type _busType;

   // expose the business object directly so we can continue to interact with the web service with
   // the actual object (not the wrapped one)

   public BusinessObj Object {
      get { return _busObj; }
   }

   // provide a indexer mechanism to read/write field values
   public object this[string fieldName] {
      get { return getFieldValue(fieldName); }
      set { /* I'll leave this as an exercise for you, the reader - it's not difficult at all */ }
   }

   // returns the value associated with the specified field name
   public object getFieldValue(string fieldName) {
      FieldInfo field = _busType.GetField(fieldName, BindingFlags.Public | BindingFlags.Instance);
      if ( null != field )
         return field.GetValue(_busObj);
      else {
         XmlElement customField = getCustomField(fieldName);
         return ( null != customField ? customField.InnerText : null );
      }
   }

   // returns simply the number of fields defined by the business object
   public int FieldCount {
      get {
         FieldInfo[] fields = getDefinedFields();
         XmlElement[] elems = getCustomFields();
         return fields.Length + elems.Length - 1;  // subtract 1 to account for the presence of the 'custom' field
      }
   }

   // returns an array consisting of all of the fields within the business object
   // NOTE: depending on usage, we might want to cache the result of this method so
   // we're not constantly regenerating it.
   public string[] GetFieldNames() {
      string[] ret = new string[FieldCount];
      int i = 0;
      foreach ( FieldInfo field in getDefinedFields() )
         if ( "custom" != field.Name ) ret[i++] = field.Name;
      foreach ( XmlElement elem in getCustomFields() )
         ret[i++] = elem.Name;
      return ret;
   }

   // returns an array of all fields formally defined on the business object
   private FieldInfo[] getDefinedFields() {
      return _busType.GetFields(BindingFlags.Public | BindingFlags.Instance);
   }

   // returns a list of all fields found within the 'custom' field.
   private XmlElement[] getCustomFields() {
      FieldInfo customField = _busType.GetField("custom", BindingFlags.Public | BindingFlags.Instance);
      ifnull == customField )
         throw new NotImplementedException("The BusinessObj does not support the 'custom' field.");
      else
         return customField.GetValue(_busObj) as XmlElement[];
   }

   private XmlElement getCustomField(string fieldName) {
      foreach ( XmlElement elem in getCustomFields() ) {
         if ( fieldName == elem.Name )
            return elem;
      }
      return null;
   }
}

As you can see, it's pretty simple and removes a lot of the complexity of dealing with an object of whose structure you're not aware.  There is a whole lot more you can do with this object than I'm letting on, but it may be a starting point.  There are a few issues that this approach does not address (such as the notion of 'type').  For example, there's no way of knowing whether you should be dealing with an int, a string, a DateTime, etc - but I'll leave that implementation up to you.

What do you think? Plausable? Idiotic? Cool?

I'd like your feedback and input.

Thursday, April 26, 2007 4:12:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Tuesday, April 24, 2007

With .NET, consuming web services is a snap.  Heck, it's not all that difficult without .NET, but it sure makes it even easier.  In general, and for simple cases, all you need to do is add a web reference to the target .asmx, have the proxy generated (via VS.NET or wsdl.exe), and you're off to the races.

Some additional care and consideration should be taken, however, when the data returned from the web service can vary in format and structure.  Allow me illustrate this with an example:

Suppose you are developing an application that must consume some data from a web service.  This web service returns structured data that, via the auto-generated proxy, is represented in a class.  For argument sake, this class is Customer (which derives from BusinessObj) and it has a few properties as identified below:

[XmlInclude(typeof(customer))]
public abstract class BusinessObj { }

[XmlType(Namespace="http://schemas.devstone.com/svc")]
public abstract class customer : BusinessObj {
   public string id;
   public string name;
}

Furthermore, this web service is part of a larger application that a company will purchase and deploy internally.  In fact the customer may customize each type of data (e.g., Customer) by adding custom fields and attributes.  Your component is designed as a 3rd-party add-in for this application and may be deployed across this varied environment.

Some customers will leave the base application alone (not customizing it) where other will 'go-to-town' and change the schema entirely to fit their business needs.

The question is this: how can your application operate in such a varied environment, consume the web service, and process all of the customizations that the customer has implemented?

You cannot, for instance simply create your web service proxy against the default schema and expect that to work.  The reason being that once you deploy your component into a customized environment, your proxy will not know about the custom fields and cannot serialize/deserialize them.  You won't get an error, per sé, but any custom fields will be ignored and not made available to your application.

This could be disastrous in the event that you needed to populate or read the custom fields.

How would you approach this problem?

NOTE: I'll post my answer tomorrow (or perhaps tonight) of how I've implemented it in the past to great success.

Tuesday, April 24, 2007 3:50:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [2]  |  Trackback
 Monday, April 16, 2007

Phew! What a crazy, fun weekend!  I'm finally getting caught up.

This past weekend (April 14th, 2007) we had the opportunity to host and participate in the second Code Camp in Utah officially entitled “Utah Spring Code Camp 2007”.  Our goal is to put these on every six months, the next one sometime between Sept and Nov of this year.

Nonetheless, this event was a lot of fun.  There were many in attendance, though not quite as many as we were hoping for.

I had the opportunity speak on .NET Serialization.  It was a variation on a presentation that I had prepared a few months back for the Utah .NET User Group and this time, after rewriting the presentation and code samples from scratch it went MUCH better.  I am quite happy with how it came out (I hope those in attendance gleaned some nuggets of information).

As it turns out one presenter was not able to make it out to the Code Camp (calling in around 10:30 or 11:00 in the morning) so we had to scramble a bit.  I had some ideas up my sleeve based on what I had trimmed from my presentation and we focused the second hour on XML Serialization.  That was a lot of fun! :-)

The third block was a shortened (30 min) presentation in which I discussed an evolution in accessing application configuration files (e.g., web.config, app.exe.config, et al).  Beginning with the most basic access method via AppSettings, we progressively made the transition to ConfigurationSectionHandlers and XML Serialization.  We used this technique to deserialize a block of XML from the configuration file into an object in code that we can access.

All in all, I'm quite happy with the Code Camp, though I wish I could have attended more of the presentations.  I guess that's a drawback from having multiple tracks running simultaneously - you have to pick and choose what you're gonna see.

The code for my presentations can be downloaded here.  Enjoy!

Monday, April 16, 2007 4:00:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [2]  |  Trackback