Remove "Powered by DB/Text WebPublisher, from INMAGIC" text from search results

How many billions of times have I done this and I still forget? I'm talking about how to remove the "Powered by DB/Text WebPublisher from INMAGIC" text from the bottom of your search results. You may laugh at my inability to remember such a simply thing, but even if just for my own sake, I'm making a note of it here while I still remember from yet another time I couldn't quite recall the process:

1. Locate the inmagic.ini settings file (do yourself a favor and simply search across your entire drive for all instances of this file as it can be, among other places, in your Windows directory, in your Inmagic Program Files directory, and/or etc.).
2. Add the following text to the bottom of the file:
   [WebPublisher]
   WebHideINM=1
3. And while you're at it, add IgnoreAccents too (ignores accents in searching, for i.e. searching on Université with ignore accents on, ahem, ignores the accents. Yes, Ted of the brilliant explanations. Trust me, this is a good thing:
   [Inmagic DB/TextWorks]
   IgnoreAccents=1
4. You'll likely have to reset IIS to get the settings to hold. Easiest way to do this is Start Menu -> Run -> type in "iisreset" (without the quotes) and enter.

The Uri gotcha that gotcha'd me good

When working on ASP.NET web applications, it's not unusual to be working with the System.Uri class, which is an object representing a uniform resource identifier (URI). It can spit back handy references to various properties of a URL, such as host, query, scheme, yada yada.

I was down in the dingy Andornot lab today, working on the Onesearch class library and feeling clever because I was using Uri objects to hold WebPublisher search URLs instead of mere strings. But strangely, something kept going wrong whenever I called upon the Uri to actually perform a web request. The search text I was passing in was not getting encoded. (This is so "doctor & nurse" gets encoded to "doctor+%26+nurse" and doesn't make WebPublisher cry like a wet-nappied baby.)

I encoded that string every which way I knew how, and viewed the results in the trace log. It was going in encoded, but somehow whenever I asked for the whole Uri as a string to make a web request, it came out "doctor+&+nurse". I was going completely bananas. Had I slipped into some alternate Twilight Zone universe? Was there a bug in the .NET 2.0 framework? Where was my encoding? Double U Tee Eff!

I finally figured it out. I had been asking for Uri.ToString(), which indeed returns a full string representation of the Uri, sans encoding, even if you had forced encoding upon any portion of the Uri previously. Buggrit! Millenium hand and shrimp! I humbly accept my chastisement from the gods, and ask instead for Uri.AbsoluteUri(), which returns a full string with encoding. Amen.

As a postscript, UriBuilder.Query is a trip-up as well. Do not append a string directly to this property! I did, and now I'm sorry.

Don't

uriBuilder.Query += "&QI0=smith";

What does that get you? Two question marks preceding the query instead of one.

Do

uriBuilder.Query = uriBuilder.Query.Substring(1) + "&QI0=smith";

Install CS 9 side-by-side with CS 1.3

Lord knows why you'd want to do this, but it is possible. I have to do it to support as many client configurations as possible, but that's *my* nightmare.

I had CS 1.3 installed on the ICS_MSDE instance, just like the install directions told me to. Everything was default, so nothing strange about it.

I wanted to install CS 9 on SQL Server 2005 Express, though, not MSDE. I think that's the recommendation from Inmagic anyway. However, I wanted to keep CS 1.3 going on its original instance and not upgrade it.

All I had to do was install CS 9 in a different directory. So instead of letting it upgrade my CS 1.3 install at \Inmagic\Content Server, I forced it to install at \Inmagic\ContentServer9. I've done this before with DB/Text, and since this portion of the install has nothing to do with the database back-end, I figured I could get away with it for CS, and I was right.

When the time came to tell the CS 9 Admin tool what SQL instance to use, I pointed it at my SQL Express instance (I had previously installed SQL Express months ago). Hey presto. Actually, it wasn't immediate presto, because I had SQL Express configured to use Windows Authentication only and CS Workgroup needs it to use mixed mode (both Windows and SQL Authentication). Once I figured that out, though, truly presto was my name-o.

Now I have CS 1.3 running on MSDE and CS 9 running on SQL Express on my Win XP workstation. Some days after work I make them do little drag races. They also scrap with each other when I drop them into a bell jar.