http://msdn2.microsoft.com/en-us/library/ms364069(vs.80).aspx

Writing code that is fully interoperable with two different runtimes can blow; 'nuff said. The single-most valuable thing to remember when doing COM interop (in my opinion) is to add your damn .NET module to the GAC. Why?

The reason lies in the internals of COM, and if you've ever had the distinct pleasure of pounding your head against the desk while working on COM you'll quickly understand what I'm trying to say. COM was built with the ideals of interoperability in mind: so long as the two, distinct components stuck to a particular contract-based communcation (through "interfaces") then everything worked nicely.

In COM to get at a particular bit of functionality (which is exposed via an "interface") you must get at the Com Class (coclass) which implements the interface. A particular COM server houses the Com Class (coclass) which implements the interface. Basically, to get at functionality, then, you must locate the physical module, then ask the physical module to activate a particular "object" and then ask the "object" for an interface pointer to the functionality; the rest is done through vtable pointer arithmetic (this is all if you're using "IUnknown" semantics, otherwise the game is slighty different).

.NET interops with COM by having the mscorlib.dll module be the server - it is responsible for loading the necessary DLL files that implement your .NET functionality and doing all the proper dirty work of interoperating with COM. Say you have a COM plugin, then, for some application - but the plugin is written in VB.NET. The main application attempts attempts to create a com instance (through CoCreateInstance()) of your .NET module - this routes the COM runtime to Mscorlib.dll which attempts to locate your DLL; however, how does Mscorlib.dll find it? Well, if you haven't placed it directly next to (in the same directory as) the main application or in the GAC, MScorlib.dll will not be able to find your module and you're, effectively, "dot screwed".

....by placing the module in the GAC you'll be able to guarantee mscorlib.dll will find your module.

I am going to be published in MSDN this September on the internals of the ASP.NET AJAX ScriptManager control. For those that are currently reading this blog and have an interest in other subjects related to this topic, please feel free to comment and/or drop me a line (ben@sideshowsystems.com).

I've got another article in the works (another reason why blogging has been so sparse lately); but again no reason to believe it'll make it to MSDN again, but I'll try. I promise I'll try to post more regularly here too.

I'm a consultant, and as a consultant I spend a great deal of time concerning myself with the "next job". I may not always be a consultant (I don't believe it's related in any way shape or form to my eagerness to be one, just that times change, etc) but for the time being I am one and so must constantly be on the outlook for the next great "gig".

How do you go about getting a consulting job? Well, for me the challenge is my locality. I'm located in Nebraska which, for the most part, is a relatively barren wasteland for modern technology. Most of my "gigs" have been acquired through word of mouth and diligence on my part to help people in times of need when they requested it - you treat someone well and they'll treat you well back, it's the basic law of the land.

First - I would not look on sites like rentacoder.com. I have tried it, and I don't like it. Why? The reason is simple, for the most part people you will find on rentacoder (on both ends of the spectrum: developer or "buyer") are unrealistic. It's not their fault; they're not "stupid" in any way shape and or form, they're just somewhat naive about the nature of software and how much it costs to develop something correct. Take this for example: say you find someone on there who bids for a full-featured ASP.NET site for $20.00 (I've seen it); chances are they will be back bidding again in a month or two to correct the myriad of mistakes the $20.00 wunderkind caused.

Oh well.

Second - I would join local organizations, clubs, etc. and become active members of them and rub elbows with business-folk. One thing we, as developers, are relatively poor at is communicating with the outside world. You can make a business person fall in love with you if you express, in some way, an appreciation for their situation and, especially, a firm understanding of it. At the end of the day everyone is out for the same thing in business: to make money. Being an active member of this world will clue business people onto you as someone who "understands" the needs and processes of real-world business software. Remember, the stereotype most business dudes have of us is that we're cowboys - loose cannons who sleep by day and hack by night. For the most part they treat you as a risk - you wield a black magic that they do not understand; do not use this force for evil, use it for good.

Third - Do things with the end in mind. You have a choice as to whether you get yourself certified as a Microsoft developer or master your latest XBOX game. Look at your resume' and think about what it says about you - as a person. Does it project someone willing to explore the depths of a project for someone, or not?

Fourth - have a reachable presence. I'm not promising I'll be doing this consulting stuff in a year, but I am promising that as I continue to write, and continue to learn, I will continue to grow my presence/influence wherever and however I can.  This means things like blogging, speaking, writing for magazines, etc. The first step is always advertising your presence because without a presence you cannot be reached, period (well, duh).

Fifth - try your damndest to say atop of the needs of your area. Note how I say, "Of your area" - this is extraordinarily important. Areas differ on their needs and requirements for software; different places require different talents - you will succeed if you have a good rap sheet and expertise on those needs. Consider that and ask around, talk, discover, etc.

...I think the most important thing to take away is opening the lines of communciation, being accessible and being real. Believe it or not, but if you can make those things happen you can probably (probably) make it as a software consultant.

What if you had a web service method like this:

[WebMethod]
public List<String> Test() {
List<String> blah = new List<string>();
blah.Add("First");
blah.Add("Second");

return blah;
}

The method returns a generic List<> type of String objects. What happens if you want to consume it from AJAX via a web service method call like this?

function callWebService()
{
WebService.Test(OnMethodSucceeded,OnMethodFailed);
return;
}

The result will get sent back to the browser as an array type in JavaScript. Doing an alert() call on the result returned from OnMethodSucceeded like this:

function OnMethodSucceeded(result, eventArgs)
{
alert(result);
}

Yields the string "First,Second". You may also index into the array too and get the individual strings.

So, what about parameters? ECMA script doesn't support generics in the same way .NET does, but given that we've identified the runtime returns the generic list as an array back to ECMA script, it seems logical that we could pass a "generic list" to the runtime via ECMA script as an array. Indeed, we can. If we change the web service method to something like this:

[WebMethod]
public String Test(List<String> arg) {
if (arg.Count > 0)
return arg[0];
else
return "NA";
}

We can call it from script like this:

function callWebService()
{
var arr= new Array(5)
arr[0]="1";
arr[1]="2";
arr[2]="3";
arr[3]="4";
arr[4]="5";
WebService.Test(arr,OnMethodSucceeded,OnMethodFailed);
return;
}

The web service method returns, as a string, the first item in the array. OnMethodSucceeded, with our alert() method, will display "1" returned to the client.

My article has been written for MSDN now and so I'm back to blogging. The article wasn't done quite as well as I would have hoped because I've got about three or four other things going on at the same time right now and so focus has been thin; but it was an article and we'll see if it makes its way through the submission process.

Apart from that I have decided that I'm going to blog on the ASP.NET AJAX control toolkit for the next month or two, exploring each of the control's from the inside out and teaching people how to use them. Hopefully I can even contribute some of the things I write to the community project itself. Regardless, my hope is that we can all explore the internals of the AJAX controls a bit and begin to leverage them more productively.

I'll continue posting answers to people's questions too.

I'm going to go alphabetically through the control toolit, so starting tomorrow we'll begin an exploration of the Accordion control and I'll try to spend, at least, a couple days (maybe even a week) on each control.

Cheers.

I have been busy :)

Currently I'm writing an article for MSDN detailing the internals of the ScriptManager; and so between that and work I have had next to no spare time to really do anything else. When the article if done then I'll have plenty of time for exploring ASP.net, AJAX, .Net and the like...but for now, I gotta get this article done!

Thanks....

(about another couple days, probably)

I quickly through this sample together because someone in the newsgroups wanted a way to create a filesystem view through the ASP.Net TreeView control. Note: I'm not touching this with icons or any other niceness, that's an exercise left to the reader:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="WebUserControl.ascx.cs" Inherits="WebUserControl" %>
<script runat="server" language="C#">
    protected void Page_Load(object sender, EventArgs e)
    {
        System.IO.DirectoryInfo di =
            new System.IO.DirectoryInfo(@"c:\mydirectory\mydirectoryschild\");
        TreeNode root = new TreeNode(di.Name);
        this.TreeView1.Nodes.Add(root);
        HydrateTree(di, root);
    }

    private void HydrateTree(System.IO.DirectoryInfo dir, TreeNode parent)
    {
        foreach (System.IO.FileInfo file in dir.GetFiles())
        {
            parent.ChildNodes.Add(new TreeNode(file.Name));
        }
        foreach (System.IO.DirectoryInfo di in dir.GetDirectories())
        {
            TreeNode child = new TreeNode(di.Name);
            parent.ChildNodes.Add(child);
            HydrateTree(di, child);
        }
        return;
    }
</script>
<asp:TreeView ID="TreeView1" runat="server">
</asp:TreeView>

This is what it looks like on my machine:

Recommended reading:

Kind of an interesting mental exercise. Say you wanted to enumerate all the classes in any particular namespace. Unfortunately there doesn't appear to be a way to say, "Get all classes in a namespace" using reflection, so you kind of have to roll your own implementation. But, this is how I did it....

namespace TestingGroundsCSharpConsole
{
    class Program
    {
        static void Main(string[] args)
        {
            Assembly a = Assembly.GetExecutingAssembly();
            List<String> namespaces = new List<string>();
            foreach (Type t in a.GetTypes())
            {
                if (t.Namespace == "TestingGroundsCSharpConsole")
                    namespaces.Add(t.Name);
            }

            foreach (String s in namespaces)
                Console.WriteLine(s);

            Console.ReadLine();

            return;
        }
    }

    class Class1
    {
        private Int32 _myInt;
    }

    class Class2
    {
        private Int32 _myotherInt;
    }
}

....the output is

Program
Class1
Class2