Unlike the many million posts, comments and mindless shouting matches preceeding this date, I will not delve into a discussion that one is better than the other.  Instead I'd like to talk about a situation that I ran into today at work.

Although I'd known for some time that you could do this

using Microsoft.VisualBasic;

in your C# code, I never believed it to be a good idea. Today I ran into a situation where I was debugging some code and sure enough I found that code existing for the purpose of implementing the Visual Basic IsNumeric() function. When I tried to explain to the developer responsible for it's existence why this was a bad idea, I found myself unable to put together an arguement that was strong enough to rebut his continual assertion that "It is just an assembly being referenced like any other." Nothing bothers me more than a person who can't suggest a change in code without having a strong supporting reason. Today I hated me. Tonight I'm on a quest to bolster my quiver of arguments for the next code review battle.

The question that needs answering (or at least a little attention given to it) is "Why should I not use the Microsoft.VisualBasic namespace in my C# code?"
First stop.....Google. Here I found a lot of "This is great! I can reference VB.Net in my C# code and get the IsNumeric and financial functions without having to rewrite them!" Followed closely by "You shouldn't do this. It's not natural." So my quest continues on.
Next stop....my bookshelf for a copy of Practical Guidelines and Best Practices from Microsoft Press. Again I am thwarted in my attempt at enlightenment.

I have no idea what to say now. I suppose that the main argument that I should have used was that we didn't need to use the namespace for the following code situation:

using Microsoft.VisualBasic;

function void DoStuff()
{
    double dblSomeVal = 0;
    if (Information.IsNumeric(dblSomeVal) == true)
        DoOtherStuff(dblSomeVal);
}

Yesterday I attended a meeting that was to determine where in the corporate environment we were going to locate our MSMQ.  This was the first time that I'd been involved in this type of conversations with the client and it was an adventure in patience.  The meeting was different for me, not because Gollum was chairing it, but due to the fact that the client had us and another service provider (who's implementing a MSMQ solution too) in it.  I've determined, in my two meetings with him, that Gollum is most comfortable standing in front of a white board with a marker in hand.  He's just at ease in that pose and spouting about something.  XML (his precious), recoverable (yesterday's word of the day) and leveraging (just 'cause it sounds cool).
So I figure that these guys have so many procedures, standards and areas of control that the physical location of the MSMQ's would be a simple "It goes here, whether you like it or not."  Imagine my surprise to go through numerous recirculations of conversation where I learn that the other provider's test queues are in the dev environment, their production queues are in the test environment and there are no queues in the production environment.  Of course the ensuing confusion led to a 10 minute discussion on the benefits of the upcoming server naming standard which shed a whole lot of light in the room we weren't sitting in.
In the end I figured that all this meeting was held for was so that the interested parties (primarily those from the client environment) could get up, sing, dance and feel like they had input.  In reality it proved that the forcing of standards and evironmental configurations are occaisionally ignored.
Ah well, Aragorn in her long black, hooded coat is paid to endure these tribulations.  I'm just a masochist.

Today I figured out why I was successful at failing yesterday.  Actually, all I figured out was why I was failing.  Why I was succeeding at it still eludes me.  The configuration that I was implementing was a Queue that had a Trigger that had a Rule that invoked a COM component.  The Rule was configured to call the COM component and pass into it a couple of parameters.  The parameters that I had chosen were Message Body (as variant) and Message ID (as variant).  The method on the Com component was defined as:

public void DoStuff(object objMsgBody, object objMessageID)
{...}

So both the variant Invocation Parameters were COM parameters defined as objects.  Apparentally this is where I was going wrong.  I still have no idea what data type the Message ID (as variant) should be coded to, but if I change it to Message Queue (as string) and redefine the method as follows, the code runs wonderfully.

public void DoStuff(object objMsgBody, string strQueueName)
{...}

I've got a call in to MS, actually Aragorn does, so hopefully I will be able to get a listing of the Invocation Parameters and the C# data types that should be used.

I got to hear a great statement from a co-worker a few days back.  He was telling a story about a friend, named Bob, who had changed his name.  The reason? 

"Every Tom, Dick and Harry is a Bob".

Today I was back at building the structure and logic code for the MSMQ message sending, COM component that the MSMQ Trigger fires and the web service that the COM component calls.  It was pretty easy to get the code all written, the work started when I began to walk through the code and test it.  First I ran into problems with Public Transactional Queues.  To keep the momentum moving I got rid of the Transactional part of that configuration and messages began arriving in the queue.  The next problem that I ran into was that the triggers were not calling the COM component without first thowing an error.  The method being called in the COM component had two parameters: MessageBody (as variant (object in the component)) and MessageID (as variant (object in the component)).  I removed the MessageID parameter from both the component and the trigger configuration and voila, my code begins to run (of course the COM component recieves an error from the web service, but hey one step at a time).  Why you ask?  I don't know.  Maybe it knew it was quitting time and it just wanted to give me enough hope so that I would come to work in the morning. 

I haven't been posting much about the technical aspects of the work that I've been doing.  The primary reason is that all I've been working on is data modelling and writing the data layer for the app.  Last week I started working more exciting things.  One of the things that this application needs to do is asynchronously run a couple of different processes.  To accomplish this we are going to use MSMQ.  According to our architect (Aragorn, to whom I am ever grateful) we should really be using BizTalk, but, alas, it would take most of next year to get the application approved and installed into the client's environment, so we are just going to skip the easy route and take the hardest possible route available.

One of the things that I'm going to have to write today is the ability to read a message from the queue, perform some operations and, upon success of those operations, remove the message from the queue.  We also are going to "pause" the queue during times when the datasources aren't available.  I'll write more about how we accomplished this later, but today I just wanted to post a link to a posting from ISerializable that has some good stuff about MSMQ.

I really haven't posted all that much recently.  Mostly its due to the fact that I've been stressed at work and probably wouldn't have posted anything constructive.

The short of the past weeks is that I've been stuggling with completing the Data Model to Bind Them All.  Finally the battle has started to slow.  Sadly this is mostly due to the fact that Grima has gone on holidays.  I've been trying to figure out why the process of getting the models approved has been such an epic struggle.  I've only thought of a few things.

One of them is that I did not produce the quality of deliverable that I should have.  I will admit that there is truth to this statement.  I certainly should have spent more time working on the finer details of the product.  I should have created a step in our process for creating the deliverable which was "Export report to RTF and run through the MS Word spell and grammer checker."  I should have spent half an hour reviewing the final report that I created for the deliverable, and this should have happened every time that the deliverable was created.  When I finally got access to the application that stores the "approved abbreviations", I should have started over and reviewed every aspect of the model.  So, fine, I was to blame for some of this debacle.

The other major problem that I've determined was that there was a major disconnect in the communication between our team and Grima.  People, you don't understand the scope of this problem.  MAJOR!  Communication directed at us mostly consisted of vague statements such as "There are many abbreviations being used that aren't approved".  Okay, this may be true, but can you feed us a bone?  Maybe just one example?  There also was the problem of not knowing what procedures Grima wanted us to follow.  There is a process for the review and approval of these deliverables.  Both review and approval have a number of different people who must sign off on them.  Our process was review for a certain specified number of days, absorb the comments, clarify them, make the changes and finally send for approval.  I did this only to have Grima get upset and ask that we issue an interm version, to him alone, so that he could approve it prior to us releasing the changes to the rest of the sign off people.  We also dropped the ball by saying that we would make changes and would send the "interm" version to Grima when completed, and then we missed sending it by three hours.

Now for the last problem.  I hate to say this was an issue, but it was.  Grima has no technical skill in data modelling.  When changes to cardinality, normalization and relationships arose they did not come from the Data Architect.  Instead the only conversations that I had on these subjects were started by the Business Analysts.  Instead of focusing on approving the structure of the models first and then riding us to produce a deliverable that met his standards, Grima decided to reverse this and firstly concentrate on producing a clean deliverable.  Once we had been in a few meetings with Grima we realized this and one of the people on my team decided that the best approach to solving this was to clearly state to Grima that, although his issues were very real, we needed to get the "real" issues resolved or he was going to stop the project and begin pushing the delivery date of the software.  This definitely achieved the result desired and the correct order of importance was acheived.

I have to say that, although it was stressful (see the sign on my window stating "No Jumping Zone"), I have learned a lot from interacting with Grima.  I just hope that he picked up a few data modelling pointers from me.

Today I had a nice long wait in the grocery store to buy my 7 items.  While waiting for hte 10 people in front of me (express lane my ass) I began to wonder what I could figure out about the people around me by looking at the contents of their baskets.

The lady in front of me -- blue berries, yoghurt, peaches (amongst other things)  Combine that with her hippy style clothing and bicycle I would say it's not a stretch to say she's a tree hugger at present or was one in the past.  Possibly all it amounts to is a healthy person who can't be bothered paying 103.9 /L for gas.  I'll stick with the first though.

The lady behind me -- Depends....I think I'll skip this analysis

Me -- Deli sliced pastrami, taco sauce, lemon and chicken thighs.  Well, all I am is a guy with bad breath and puckerd lips who likes dark meat.  Take that for what it's worth.

Guy in front of me two weeks ago -- Medium sized english cucumber and a box of 12 Trojans.  Hmmmmm.  I would venture that he is.....ah hell, I can't bring myselft to make an analysis on that one.

Welcome to the new block of ice.  As you can see, the style of the site doesn't really speak to an igloo, but rather the home of Ronald McDonald.  Over the next little while I'm going to get this looking chilly and I'm going to be working on some new stuff for the Community Server platform.