With, what I believe is, an ever degrading quaility of Microsoft articles and help, we need more articles like this written by individuals who have used the technology.

However I did run into some issues, the first of which was caused by .NET not initialising it’s FPU control word when being called from unmanaged code. The issue occured because the unmanaged application I was calling my component from was written in Borland Delphi, which doesn’t suppress certain floating exceptions in the same was Microsoft does. If I’d had access to the Delphi source I could have recompiled turning off the exceptions, something like this.

Here is how to turn them off in C++Builder:
#include float.h
 
__fastcall TForm1::TForm1(TComponent* Owner)
    : TForm(Owner)
{
  _control87(MCW_EM, MCW_EM);
}


Here is how to turn them off in Delphi:
const MCW_EM = DWord($133f);
  begin
    Set8087CW(MCW_EM);
  end;


Of course I’d have to produce a solution from my component, the easiest implementation I could find for this was to add something to my default constructor of my COMBase class. I started using code to explicitly set the control word, something along these lines…

[DllImport("msvcrt.dll", EntryPoint="_control87")]
public static extern UInt32 Control87(UInt32 Toggle, UInt32 Mask);
 
UInt32 OldControlWord = Control87(0, 0); // Get current value
 
Control87(0x9001f, 0xffffffff); // Set to .NET default
// Call Code Here
Control87(OldControlWord, 0xffffffff); // Restore to previous value


Although this works admirably, whilst I was working on it, a much simpler solution was offered to be from another developer, which I added to my COMBase class.

[ComVisible(false)]
    public class COMBase
    {
 
        public COMBase()
        {
            // Ensure FPU Control Word is set when called from unmanaged applications.
            try { Double.IsNaN(Double.NaN); }
            catch (ArithmeticException) { /* Intentionally empty. .NET will initialise the FPU at this point. */ }
        }
 
        /*  Snip */
    }


With this solved, the only remaining task was distribution of my COM component. For this I added a simple installer component to my code, which would be called from my setup project.

[ComVisible(false)]
    [RunInstaller(true)]
    public partial class CustomInstall : Installer
    {
        public CustomInstall()
        {
            InitializeComponent();
        }
 
        public override void Install(IDictionary stateSaver)
        {
            base.Install(stateSaver);
            RegistrationServices regSrv = new RegistrationServices();
            regSrv.RegisterAssembly(base.GetType().Assembly, AssemblyRegistrationFlags.SetCodeBase);
        }
 
        public override void Uninstall(IDictionary savedState)
        {
            base.Uninstall(savedState);
            RegistrationServices regSrv = new RegistrationServices();
            regSrv.UnregisterAssembly(base.GetType().Assembly);
        }
    }

With the project output added as ‘custom actions’ to my setup project, I could simply build my COM component, test it; then build an MSI for distribution which ensured calling of the registration functions, which in turn registered it for COM. It’s important to note that my components are not flagged for COM registration in the setup project, this is all catered for by the custom code in my installer class and COMBase class.

I thought to myself, this can’t be that difficult, just follow the tickboxes…..

• Project Properties->Application->Assembly Information->Make Assembly COM Visible – Check
• Project Properties->Build->Register for COM Interop (automatically exports a typelibrary) – Check
• Project Properties->Signing-> Sign the assembly (make a new strong key name file) – Check

…. surely that’s enough? Wrong. The assembly was a late bound COM object only.

A few help topics and Googles later, I’m doing all sorts of tricks, adding and deleting things in the GAC and learning the wonders of regasm. However, none of it worked.

Back to basics, the type library defines the interfaces for early binding, so why couldn’t COM see the type library definitions? The answer turned out to be very simple, the C# complier didn’t add the required information into the registry during the build. Help was at hand however, in the form of the attributes [ComRegisterFunction] and [ComUnregisterFunction]. It should be noted that the C# build does add partial information to the registry, but not the required TypeLib key……


[ComVisible(false)]
public class COMBase
{
[ComRegisterFunction]
static void ComRegister(Type t)
{
  string keyName = @"CLSID\" + t.GUID.ToString("B");
  using (RegistryKey key =
     Registry.ClassesRoot.OpenSubKey(keyName, true))
  {
   using (RegistryKey subkey =
      key.CreateSubKey("TypeLib"))
   {
    Guid libid =
      Marshal.GetTypeLibGuidForAssembly(t.Assembly);
    subkey.SetValue("", libid.ToString("B"));
   }
   using (RegistryKey subkey =
        key.CreateSubKey("Version"))
   {
     Version ver = t.Assembly.GetName().Version;
     string version =
        string.Format("{0}.{1}", ver.Major, ver.Minor);
     subkey.SetValue("", version);
   }
  }
}
 
[ComUnregisterFunction]
static void ComUnregister(Type t)
{
  string keyName = @"CLSID\" + t.GUID.ToString("B");
  Registry.ClassesRoot.DeleteSubKeyTree(keyName);
}
}


Volia, derive all my ‘COM’ classes from ‘COMBase’ and I have a working early binable COM object. Should also mention, none of the GAC and regasm manual processing is needed either. Not particulary neat, I would certainly like to know if there’s a better way.

As an aside, during my time with COM in .NET I picked up a few pointers on ‘best practices’ the most useful of which is using defined interfaces, with fixed GUIDs to keep the resultant COM ‘backwards compatible’.

For example:-


[Guid("89B65A92-5CE6-4295-A6DF-9506530C7877")]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface IFoo
{
int Bar();
}
 
[ProgId("MyCOMObject.Foo")]
[ClassInterface(ClassInterfaceType.None)]
public class Foo : COMBase, IFoo
{
public int Bar()
{
    return 42;
}
}


Should also be noted that explicitly specifiying the COM ‘ProgID’ makes it easier to manage also (and elminates the need to shorten namespaces and class names for COM). Specifiying ‘ClassInterfaceType.None’ for the class effectively hides it from COM, leaving only the parts you want to explicitly expose in the interface.

Prior to my current role, the VB6 code was about as cutting-edge as you can get with an 8 year old development environment. Extensive use was made of collections, classes and COM to build a robust central object library that was a breeze to use.

By comparision, the product I’m working with currently has ‘history’, and a lot of it. The only time a class is used is to provide a public interface to an ActiveX control. By and large the majority of the ‘framework’ is implemented in shared modules.

Neither way is the ‘right’ way, both are valid in VB6, one being an object oriented approach and the other very much ‘procedural’. That said it is difficult moving back to procedural programming after writing so much object oriented code.

It’s the procedural code, having been around as long as VB6 itself, that threw up a few surprises for me. Along with the fact that several contributers had their roots in VB to the early versions. That said I don’t remember using some of these features, even way back in VB3…..

Multiple executions on one line of code
foo=1:bar=1

GoSubs!
Private Sub Foo()
    GoSub Bar
Exit Sub
Bar:
    MsgBox "Hello world!"
Return
End Sub

Option Compare*
Option Compare Text

…and an interesting technique to detect a VB program was running interpreted…..

Debug.Print 1/0

…I’d always for some reason used Debug.Assert to call a function and set a value. I’m sure both techniques have their pros and cons.

* Not strictly ‘forgotten’, just never used, the default binary has always suited.

Happily the whole kit and caboodle seems to run along side old versions of development tools, such as Visual Studio 6 and SQL 2000 etc without any gripes.

I was eager to gain some ‘hands-on’ with C#.NET and VB.NET, which for all intensive purposes seemed pretty easy to grasp. Exception handling is a bit of a revelation if coming from a VB6 background, which is where most of my ‘commercial’ day-to-day work happens, who said VB6 was dead?

Aside from looking at the .NET 2.0, I was also particulary interested in Visual C++, being the last language that is now able to compile native applications (VB is .NET only). Herein lay my first dissappointment with the Express package, support for native applications in C++ appears to be limited to console applications only. I can’t knock Microsoft for ’steering’ developers towards .NET, especially after providing such a rich free development environment, but as much as I don’t want to commercially write VB6 forever I also don’t want to always write .NET applications.

You can get halfway to a working Win32 native application development enviroment by following Microsoft instructions here and/or here. But, and its a big but, at the end of the day you cannot edit resources in Visual C++ 2005 Express. You are left with a very nice development environment for the Platform SDK, albeit without integrated GUI support.

This is a great shame, it leaves the Express Editions in a strange place – somewhere between something too complex for a complete ‘rookie’ programmer, and something not quite useful enough for a more experienced one. Unless of course you are fully on the .NET bandwagon, in which case it’s probably very difficult to justify buying the full product for use purely at home.

The course will initially comprise of:-

• 2555 – Developing Microsoft .NET Applications for Windows (Visual C# .NET)
• 2389 – Programming with Microsoft ADO.NET
  (Exam 70-316 – Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET)
• 2310 – Developing Microsoft ASP.NET Web Applications Using Visual Studio .NET
  (Exam 70-315 – Developing and Implementing Web Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET)
• 2524 – Developing XML Web Services Using Microsoft ASP.NET
• 2557 – Building COM+ Applications Using Microsoft .NET Enterprise Services
  (Exam 70-320 – Developing XML Web Services and Server Components with Microsoft Visual C# .NET and the Microsoft .NET Framework)

I’m taking the C# route, although I’ll probably end up taking the Visual Basic exam also, just to broaden my knowledge.

You may ask why bother with the certification at all, after all I have 15+ years experience in C, C++, Visual Basic, Pascal and others. It’s more of a personal achievement thing, and a ‘I told you so’ more than anything else. I’ve also never been in the fortunate position of working for a company willing to provide any formal training.

I did have a preliminary look at some of the course material, and found it rather easy. I do honestly hope I will learn ’something’ from this, after all that is the idea.

It really is a site that every programmer should be conversant with, and should you find any of your code published there, you might think about a career change.

That said, I’ll leave you with a short snippet of a bizzare line of code that I somehow managed not so long ago…..

If iif(IsNull(rs!id, -1, rs!id)) = -1 Then ...

… hopefully this proves we are all fallible ;)

“Run-time error ‘3001′: The application is using arguments that are of the wrong type, are out of acceptable range, or are in conflict with one another.”

The error was occuring when assigning the ‘ActivateConnection’ property:-


Public Function MyFunc(objConn as ADODB.Connection) as Boolean
 
Dim objCmd as New ADODB.Command
 
Set objCmd.ActiveConnection = objConn


Nearing the end of a seemingly fruitless search for the answer (it would seem error 3001 occurs for all sorts of reasons), the answer was stumbled upon.

The connection object was being created in an EXE and being passed to the function in a DLL, herein lay the problem. Apparently, you cannot pass an ADODB connection object between processes. This is the reason it ran correctly when complied, as the DLL became part of the EXEs process, when debugging in Visual Basic two distinct processes existed.

As with all obsure problems like this, there was a simple and elegant workaround. That is to simply debug the EXE and DLL in a Visual Basic group file.

I’ve been beavering away with a smallish development team developing a new product which, for compatiblity reasons with the ‘host’ application, is developed as ActiveX DLLs using Visual Basic 6. To date there are about 14 individual ActiveX DLLs and other files that make up the product.

Of course we have source control, without which the synchronisation and rapid development pace would be impossible.

A problem occured today with one of the ‘central’ dependency ActiveX DLLs we have developed, a mini .NET library if you will. It is flagged to build as binary compatible and all other ActiveX DLLs early-bind to it. Fair enough you may think.

But what if due to limitations of working with source control, the ‘compatible DLL’ is in a sub folder of the main project and isn’t updated as frequently as maybe it should be. As it happens, part of the interface (IID) that wasn’t in the ‘compatible DLL’ changed between versions. Let DLL hell ensue……

The only viable solution was to break compatibility completely and ‘re-bind’ all dependant DLLs to the new GUID.

Considering the ‘master build’ of the product is done in reverse order, that is dependancies first, it begs the question of whether binary compatibility is really worth the effort anyway. ‘Project Compatiblity’ would preserve the GUIDs and therefore early-binds, any changes to the classes/methods of the central DLL could be tracked via source control, so the correct developer could be thumped should any change produce ‘real’ incompatibilty anyway.

Of course there’s always someone that will pipe up about the advantages of late binding, but for the purpose scale and speed of this project early binding is almost essential.

Like many people I’m sure, I work on Windows 99% of the time. However much you want to knock Microsoft, it really is still the platform of choice for most purposes. In my case, I’ve little choice anyway, it is the platform for which I develop software.

Also like many people, I have a website and the same as many ISPs, my ISP PlusNet offer a package comprising of something other than Windows based webserver software, namely the all too common Apache, PHP, MySQL combination.

This is a complete pain, this ‘alien’ software package is very good for developing dynamic websites etc, but the problem is how to develop and test them locally, i.e. on your PC before publishing them to the big wide world of the internet. Of course you can download Windows ‘flavours’ of all these packages, and spend another week configuring them.

Or you can download Webserver On A Stick.

As I started out, yes it’s a simple idea. Bundle Apache, PHP and MySQL, add a front end control program and away you go. Of course the author’s original intention was to produce a minimal footprint webserver environment for use on a USB stick, however there is nothing to stop you running it off your local hard drive. Simply unzip the package, and throw your website at it’s ‘www’ folder and away you go.

It’s certainly something I wish I’d found sooner, according to the copyright notice it started in 2003, maybe if more people shout about it, more will find this remarkably useful little piece of software.