Friday, December 9, 2011

Happy Holidays!

So - you want a happy holidays messages for everyone you know but don't have the time to personalize it for each recipient?  Try this newfangled song writer class!  It's C# but should be easy to port to Java, C++, C, and pretty much any other object oriented language.  Enjoy, and have a wonderful holiday season!

Holiday Song Writer

Sunday, July 24, 2011

Please COM down

As part of our VB to C# conversion, we created an assembly compiling with the .NET 4.0 Framework.  One method in the converted class had a signature like:

void MethodName(ref object p1, ref object p2, ref object p3, ref object p4)

The first two paramenters are input parameters and the latter two are output.  p1 and p3 are really arrays of strings, and p2 and p4 are two dimensional arrays of strings, 16 and 32 bit ints, date/time, and potentially null values.  The ASP code worked fine on top of this.

Then, we realized we want to use this component from an ASP.NET site currently compiling with the .NET 3.5 Framework.  We weren't using any 4.0 specific code so simply changed the compile type, deployed and regasm'ed the new assembly.  Strangely, when the ASP code tries to call the method above, it occasionally chokes, claiming that the "Variable uses an Automation type not supported in VBScript" followed by the method name.  What's odd is that it doesn't always blow up - only sometimes.  Also, the method signature and code didn't change.  Why would .NET 4.0 framework and regasm work fine while .NET 3.5 framework with the 2.0 regasm not?

Well, it's still a mystery but the one clue is this - the second input to this function is an output param of a previous function.  The nulls that it contains aren't really "null" but DBNull.Value.  Perhaps the 2.0 regasm is somehow typing these in a different way than 4.0...

We're open to suggestions but at this point will compile the assembly as 4.0 and have the ASP.NET 3.5 site access it via COM, unfortunately.

Tuesday, May 3, 2011

Conversion excursion

My team's applications rely on a large array of assemblies, some C++, some VB6, and some C#. The front end is largely a web site that is a mix of ASP and ASP.NET. We also have some Windows services - mostly C++ with a few newer ones in C#. A few of the C# assemblies are COM enabled to be usable from the C++/VB code, ASP pages, and services while others are only used by the ASP.NET.

We're trying to migrate away from the VB6 code so I helped compile a list of which of the assemblies are in use by which other components. Our first pass will be to perform a direct port with COM wrappers so existing code can simply point at the new object with no API or behavior change. As we do so, we'll make a note of places where we think there are existing bugs or room for performance improvements.

Have you ever performed a massive migration or upgrade? How did your team go about it? What pitfalls did you encounter as you went? With the one assembly we've ported so far, we found that trying to fix bugs at the same time as we migrated to the new code caused many more issues than it solved.