Visual Studio.NET and Nant

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.

GUID's are mangled passing through DB2 DAAB in Enterprise Library

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:
[code lang='vb']
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;

[/code]
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:
[code lang='sql']
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
[/code]

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.

Handling GUID's (UniqueIdentifiers) in DB2 using VB.NET

Continuing the saga of DB2, I am now trying to handle GUID's/UniqueIdentifiers from the Enterprise Library. First thing I had to get a handle on is that DB2 UDB has no datatype similar to a GUID. In Microsoft SQL they are represented as UniqueIdentifiers and used quite extensively. Oracle represents them as RAW(16). When I ran the conversion on my database using the IBM Migration Toolkit (MTK), the GUID's in my database were converted to CHARACTER(16) FOR BIT DATA. So basically, a container to hold 16 bytes worth of data. It takes 2 hexadecimal characters to represent 1 byte so 32 hexadecimal characters is 16 bytes or 128-bits.

IBM DB2 on Fedora Core 3 64-Bit

I have moved on to my next adventure in writing a native database interface. We have decided to add native DB2 support to our product offering. I was fairly excited when I first started out to install this but after 5 days, I am frustrated and dismayed at the lack of forethought or testing put into the product. I downloaded DB2 8.2 from IBM's web site and installed the 90-day trial for enterprise edition on my Sun Sunfire V20Z development server running Redhat Fedora Core 3, 64-bit edition. Now I bet there are alot of people who want to test DB2 under these types of conditions and from what I read, it just won't work.

Callvantage QoS

I finally got around to fixing the QoS problem with my Callvantage VoIP setup. After determining about 3 months ago that my Callvantage box was dropping packets and causing general outbound havok on my system, I decided to move it inside my network behind my trusty linux firewall/router/mailserver/gameserver box. The unfortunate side effect was that I lost the Quality of Service capabilities. This caused a serious delay in voice transmission and sometimes even stuttering while I was talking on the phone. I usually just accepted it until my friend got his new Actiontec router and it handled VoIP QoS automatically. Now if Actiontec can do it, I know my outdated Redhat 7.3 install should be able to.

Coaxial Run with Power CCTV Troubleshooting Guide

Written by Jim Shank 8/2/05

 

There should be two major troubleshooting points for CCTV, the camera’s themselves and the central terminating location (CTL) in which the video signal is captured and the power is supplied (if power is not supplied mid-run or directly at the camera location). Troubleshooting will be started at the CTL and then move to each individual camera. It helps to have a baseline camera that is working in order to capture normal readings for comparison. Remember that CCTV cabling should be as follows

		RG-59/RG-6		UTP with Baluns		Fiber Optic
Run Length		< 250 ft.		250 – 3000 ft.		> 3000 ft.

 

Tools Needed

• Digital Volt Meter (DVM)


• Electrical Tape

Optional Tools

• BNC or F-type connector and small piece of coax


• 9V battery

 

.NET Remoting and App.config files

I am moving on to some remoting applications in my project and found another interesting tidbit. Almost all of the remoting examples in Microsoft .NET Distributed Applications: Integrating XML Web Services and .NET Remoting use console applications as component hosts (listeners) and of course call the RemoteConfigurationFile.Configure method. This really doesn't make sense since in the real world, you are probably going to be running your component host as a service. What isn't revealed is that when you start your service, it's local directory is your system dir (e.g. c:windowssystem32). In order to access your application configuration you either need to hard code the whole path (bad idea) or use the ever so handy AppDomain.CurrentDomain.SetupInformation.ConfigurationFile. This makes it much simpler to access the app.config file and load your remoting configuration correctly. I found a snip that this information is included in Ingo Rammer's Book Advanced .NET Remoting in VB.NET but I haven't read that one yet.