When creating .NET classes that will be accessible via COM Interop, you need to be sure to add a default constructor to the class. If you don't, regasm will end up generating the tlb without the CanCreate flag for that class, and therefore, when registering the tlb, those classes will not be registered.

Yes, this makes sense, and yes, this is covered in MSDN, but I thought I'd mention it here, as it recently tripped me up for a little while.

Since I'm a programmer, I don't always keep up to date on other areas of software because it's always more fun to write your own tools. I can find my way around Excel some, but I am not exactly a power user. I had a need to highlight the maximum cell value in a column today, and it turned out to be not entirely obvious. Fortunately, here's a Google post to walk you through this exercise if you need to do the same thing.

I've been tasked with adding text searching through documents to our application. Since we need to support multiple databases, I didn't want to use the native DBMS indexing options. Looking around, I came across Lucene.Net. It is an open source port of the Java version of Lucene, which is a lightning fast search engine over indexes of documents. The list of features is rather extensive, but my favorite feature would be the advanced search capabilities, including proximity search. There is also a very impressive open source project based on Lucene.Net called SeekAFile which adds functionality over Lucene.Net, and works extremely well, too.

I wanted to centralize the index storage of Lucene.Net, though, since it would be possible to have multiple app servers located in different physical locations, and allowing access from one machine to another could prove problematic. This meant that storing the index to the central database. I found a source code sample that would do this on a Firebird database. I have now converted that to work with MSSQL and Oracle, and it works very well. Yes, it's a bit slower than using the native file system directory provided with Lucene.Net, but it solves the problem we set out to solve.

I came across a link to COMTrace from Scott Hanselman. This tool allows for interception and logging of COM traffic. I just tried it out, and it mostly works on some of my more complex MIDAS applications. Granted, it is far from perfect (e.g. I needed to start a new process multiple times before I could get it to work when tracing an app server, or it would hang when starting a client process), but I was able to eventually use it to get tracing information on all of the round-trips that the application makes, including seeing parameters being passed from client to server. From the history log, it appears that the last change was in 2002, so it's a bit dated.

A while back, I was going to develop a tool like this, and actually had some things working on the Delphi level by intercepting VarDispHandler, but that would only work within an application, and for late-bound calls. That didn't sit well with me, as I wanted all traffic intercepted, be it early-bound or late-bound, and I didn't want to necessarily instrument my applications with my tracing/hooking code. I started looking at Keith Brown's Universal Delegator, and associated tools, and was going to go down that route, but the priority changed on having this tool, so it got shelved. It's nice to see that something is out there, even if it is imperfect.

Oracle is much more stringent with parameter bindings than other DBMS (e.g. MSSQL). For example, take the following statement "UPDATE MYTABLE SET FILENAME = :to WHERE FILENAME = :from". Pretty innocent, and the same query works on MSSQL. The problem is when you bind the parameters and execute the SQL using the OracleClient ADO.NET provider, you get an ORA-01745 error. I didn't see anything in google on this, but I figured that reserved words were at the root of the problem. So I changed the parameter names to ":toname" and ":fromname" and everything works just fine.

Many posts have been written about the fact that you cannot specify a config file for class libraries. While I understand the logic of putting the config file in the host process instead, there are always valid reasons for wanting to go outside the use case scenarios envisioned by the designer. My example would by COM Interop. If you have a .NET class library that requires some amount of configurability, and you use COM Interop, you cannot use the host process' config file because it doesn't exist. Instead, you need to get the configurability another way. I thought of the registry, a simple INI file, and a config file, and in the end, I settled on the config file. By doing this, I was getting people here and in the field used to the config file concept. However, that meant that I needed to provide custom support for maintaining this config file.

There are several options, like the EntLib FileConfigurationSource, creating a custom Reader to read arbitrary config files, etc. I came across Mike Woodring's AppSettings implementation, which gives a pretty close approximation of how config file logic works. It doesn't use the new .NET 2.0 sections, but it's a good start and got my code working with minimal trouble.

I have a need to allow users to build up a connection string and store it in a config file. Pretty simple need, and I would imagine rather standard. After all, I can't imagine any user I deploy to would have the same connection string I do, much less the same database. As it turns out, providing a robust piece of code to get this done will have to be all custom code. Given how common this scenario is, I'm more than a bit disappointed that MS just punted on this entire thing. Do they really expect end users to just wander around and edit config file XML syntax by hand and get it right? Do they really think not having the ability to do a "Test Connection" is a good idea?

I know about the support article from MS, but that uses interop back to plain ADO. I really can't believe they would not provide a managed code alternative that works with ADO.NET. Furthermore, the DbConnectionStringBuilder class in ADO.NET 2.0 starts to solve the problem, but stops short, like Frank Costanza on a drive through New York City. That class gives us some capability to build up the connection string, but none to visually build it up, much less edit a connection string in-place in the config file.

After way more time searching around the Internet than I care to admit, I'd like to think that I'm missing some simple link, but it looks like MS expects every single .NET developer to implement their own Connection String Wizard from scratch. Feel free to reply if you know of any pre-built solutions.

I wrote a VS.NET 2005 class library that I wanted to use from Delphi. Using COM Interop, this should be a breeze. Simply call "regasm MyLibrary.dll /tlb" and I should get a type library that I can import in Delphi. If that's all there was to it, then I wouldn't be blogging.

The first problem I had was that when I ran this command, I got an error stating:
RegAsm error: Failed to load 'C:\MyLibrary.dll' because it is not a valid .NET assembly

This was weird, considering it was a .NET assembly. The problem was that the regasm being used was the one from the .NET 1.1 framework, so it choked on my .NET 2.0 compiled application. Simply running the VS 2005 Command Prompt and re-running regasm got the type library I wanted - or so I thought.

I marked the classes I wanted exported via COM with the [ComVisible(true)] attribute, but the only thing exported to the type library was classes with no members. In order to get the members exported, I ended up putting the [ClassInterface(ClassInterfaceType.AutoDual)] attribute on the class, too. This isn't the optimal approach, according to MSDN, so I'll end up extracting the members to an interface and exposing that instead, but at least I'm up and running for the moment.

I just came across this site today. It shows a bunch of different connection string sample for various databases and technologies. It also links back to downloads for the databases. All in all, a very focused and nicely done reference web site.