I’m not sure whether it’s the fastest way to convert an enumerable collection of
ints to a comma-delimited list in C#, but it might be the shortest.
If you need a LINQ-free version for backward compatibility, check out Missing Functions on IEnumerable on Steve Cooper’s blog.
With my roots in maintenance programming, I’ve used a wide assortment of programming tools. Maintaining legacy code is not much fun. Anything that makes it easier gets added to my personal collection of productivity applications. I make a point of learning them inside and out.
I carry the tools with me from project to project. I recommend them to coworkers. I’ll use them even if my employer provides alternate tools for free. I’ll complain loudly if the company I work for won’t allow me to use them — for policy reasons, consistency reasons, or security reasons. (Most of my bosses eventually concede the point. After all, they’re interfering with my ability to get things done, which is presumably why they hired me.)
When I heard that version 3 was soon to be released, I was both excited and a bit nervous. What new features would they add? Were they going to break any behavior I relied on?
The website lists the new features, but the best new feature is the polished user interface, which makes it easier to move blocks of text and make inline edits to files.
And no, they didn’t mess up anything in the process.
I played with the beta for several weeks, and recently bought the full version. If you’re not using it already, you should try it.
Sometimes COM Objects return a HRESULT that is outside of the bounds of a C# integer.
Unfortunately, the only way to correctly handle a COM Exception in .NET is to use the ComException Class. But if the HRESULT isn’t an Int, and the ErrorCode Property on the ComException class is an Int, how are you supposed to ever be able to catch that specific HRESULT?
Fear not! Here’s how to handle a COM ErrorCode that can’t be converted to an Int (in this example, it’s unsigned)
The magic happens in the ‘unchecked’ statement – which tells the compiler not to perform the overflow-checking context for integral-type arithmetic operations and conversions.
More on the Unchecked Operator over on MSDN.
The ConfigurationManager class introduced in .NET 2.0 makes it easy to read application settings from an XML file. I especially like the ability to derive a class from ConfigurationSection to hold custom settings for your application. This MSDN tutorial on creating custom configuration sections can help you get started.
I used this to make the configuration files for several of our Infovark add-ins, but ran into a snag with our main API library. In order to interoperate with COM, we had to put out Infovark.Api.dll in the GAC.
This presents a big problem for using *.config files. If your assembly is in the GAC, your configuration file must live in the GAC as well. (By default, configuration files are sidecar files located in the same directory as your *.exe file.) Since the GAC lives in a special place on a Windows machine, it’s difficult to read and write from that location without special permissions. And you can forget about browsing to it using Windows Explorer. This makes it tough for folks to change configuration options, which defeats the whole point of XML-based configuration files.
It’d be nice if we could load the configuration file from an specific spot on the computer. But while the Configuration object has both
SaveAs() methods, there’s no corresponding
Load() method. Huh? According to MSDN, the “right” way to point your application at a different configuration file is to create a whole new app domain with the appropriate settings. Um… sure.
How about we just hack up a workaround instead?
You can fool the configuration object into loading settings from whatever .config file you want, if you don’t mind a hack or two. The Configuration object exposes an
OpenExeConfiguration() method that takes a string. Despite its name, you don’t have to pass it an .exe file. Any file path will do, as long as the path exists.
Since my .dll was in the GAC, I didn’t have a target for the
OpenExeConfiguration() to use. I could have pointed it at another .dll — or at a .txt file for that matter — but that wouldn’t be very intuitive. Instead, I created a temporary file without an extension in the location I wanted to save the configuration file. Then I can open a Configuration object using the dummy target. Saving the Configuration object will cause it to write a file named “[configurationTarget].config” to the path I specified. You can see the code I used below.
Once I’ve opened the Configuration object, I don’t need the dummy file any more. I delete it to avoid have weird extension-less files hanging around.
It’s not pretty, but it gets the job done.