UPDATE 10/5/2005

I figured out why I was getting the BC2010 error finally. I decided to isolate the failing build project into it’s own directory and determine what the differences were between it and the Visual Studio build. As soon as I reloaded the project in VS.NET, I started getting errors that the signature was incorrect on the methods I was implementing for an interface. Upon further investigation I realized that I had renamed the dll in Nant when it was copied to my lib directory. So the interface that I was implementing referenced the DLL as one name internally, MSDocument.dll, and the library I was trying to build had a reference to it as well as MyCompanyDocumentStructures.dll. Although the contents were the same, I assume the name difference affected the signature enough that I was unable to implement it with a different name. Some sort of compiler information on the error would have been much more helpful but at least I know what was going wrong. I guess the moral of the story is to isolate the problem and then compare the vbproj file to the nant build file and figure out where you have differences. I am now looking forward to taking full advantage of Nant without vbc compiler errors. » Read more: Visual Studio.NET and Nant

Continuing my work on the DB2 interface for my application using the DB2 DAAB, I am working extensively with GUID’s. The probelm I am running into is that somehow, the Byte Array conversion or DB2 itself is changing the GUID value when it is added to the database. I have a simple Stored Procedure in DB2 that accepts a CHAR(16) FOR BIT DATA. This is handled under the covers by the AddParameter Method keyed by the dbType.GUID field. A conversion takes place from a GUID to a binary byte array.continued…

Here is the code from db2Commandwrapper.cs:

case DbType.Guid:
guidParameters.Add(param.ParameterName, "System.Guid");
param.DB2Type = DB2Type.Binary;
param.Size = 16;
// convert Guid value to byte array only if not null
if ((value is DBNull) || (value == null))
{
param.Value = Convert.DBNull;
}
else
{
param.Value = ((Guid)value).ToByteArray();
}
break;

Now here is the weird part, lets say I supply a GUID of value 9c1fcfe7-d68e-4a6d-b395-823bac3022f7. I run it through my stored procedure:

CREATE PROCEDURE DB2ADMIN.PROCESSORINFOADDSINGLE ( IN v_ProcessorID CHARACTER(16) FOR BIT DATA))
DYNAMIC RESULT SETS 1
------------------------------------------------------------------------
-- SQL Stored Procedure
------------------------------------------------------------------------
P1: BEGIN

INSERT INTO DB2ADMIN.PROCESSORINFO (PROCESSORID)
VALUES (PROCESSORINFOADDSINGLE.v_ProcessorID);

END P1

and it comes out as as x’E7CF1F9C8ED66D4AB395823BAC3022F7′. The first 16 characters are somehow changed. Weird. If I run a select statement against it from CLP, it will not match. However, if I used a parameterized query that runs the same GUID back through the db2Commandwrapper conversion function, it matches. This will cause problems if I try to run a standard GetSqlStringCommandWrapper without using a parameterized value for the GUID.

I posted this same information to the Enterprise Library Newsgroups. Maybe I will get some feedback.