I have received several e-mails asking me about the real use of Generics. Why I like them so much and what makes them such an interesting feature in .NET 2.0. Programmers who use one of many other languages may not have had contact with anything similar to Generics, so I guess that’s quite a legitimate question. Generics are one of the features of the next version of the CLR (Common language runtime), as delivered by Microsoft with .NET 2.0. They can currently be used in the beta and CTP releases of Visual Studio .NET 2005, as well as (in part) in the Mono Project. Now, to explain the use of Generics I thought I’d just use a small and simple sample. If there’s enough interest, I may write other articles on more advanced topics surrounding Generics.
In a project of mine, I used to have some methods that were able to restrict values to a specific range, given as a bottom and a top value. The methods I had looked like this:
As I mentioned in a previous post, Copernic Desktop Search 1.5 beta is currently available to the public. One of the most important new features was for me the introduction of an extensibility API. When I wrote that first announcement, I hadn’t had a close look at the API. By now I’ve found out that it’s about extracting data from new file types, nothing more or less than that. I’d wish, and maybe I should add that to my list of things I’d like to see in CDS, they would extend that extensibility support to other areas, like creating plugins for file type preview, or even introducing completely new ranges of searchable objects. Well, maybe that’s in the future. For now, I’ve taken the plunge and tried to implement a custom extractor for CDS. And while I was at it, I wanted to do it in in C#. I succeeded and these are the results, maybe somebody will find this useful to implement a custom extractor that really does something worthwhile 😃
In this post, Dave Templin explains the purpose of the
.vshost.exe that gets created automatically by Visual Studio Whidbey. What it also mentions is the fact that the application domain my code runs in is of course different when I run in the debugger. I found a problem with this where the
FriendlyName is concerned. I’ve been using the
FriendlyName to construct names based on my application’s
exe name, the same way the normal
app.config files work. The problem is, as soon as I run the app in the debugger, the
FriendlyName is no longer the same and the config file that’s already there isn’t found.
To solve this, I was looking for a way to find out the “real” base name of my application’s
exe file, without the
vshost. part. Apparently, there’s no special property or anything that would let me access this information directly… maybe that would be a useful extension to the