The possibilities are endless.

Dear Customer,Hrm...this really makes me wonder what the hell happened to my card number. They have attached an FAQ section to the bottom of the letter stating, "Due to an ongoing investigation, we are not able to specify how, when, or where your card was compromised, however, we can confirm that it was not at MasterCard."
At MasterCard, we are constantly working to protect our cardholders from credit card fraud. In connection with a recent investigation, we have reason to believe that your MasterCard #---- ---- ---- ---- may have been compromised. This means that your card number may have become known to an unauthorized person(s).
Although there is no evidence of fraud on your account, we feel it prudent to replace your existing card to avoid any potential misuse. Attached please find a replacement card with a new number. We sincerely apologize for any inconvenience this matter may cause you and appreciate your understanding.
My new professional blog: | |
www.SteveDinn.com | |
![]() | |
My new personal blog: | |
blog.SteveDinn.com | |
![]() | |
My photos on Flickr.com: | |
flickr.com/photos/stevedinn | |
![]() | |
My links on del.icio.us: | |
del.icio.us/stevedinn | |
![]() |
My weekly podcast: | |
SpineRadio.com | |
![]() | |
My monthly podcast: | |
zunior.blogspot.com | |
![]() |
My new professional blog: | |
www.SteveDinn.com | |
![]() | |
My new personal blog: | |
blog.SteveDinn.com | |
![]() | |
My photos on Flickr.com: | |
flickr.com/photos/stevedinn | |
![]() | |
My links on del.icio.us: | |
del.icio.us/stevedinn | |
![]() |
My weekly podcast: | |
SpineRadio.com | |
![]() | |
My monthly podcast: | |
zunior.blogspot.com | |
![]() |
Like my co-worker, Brent, I have recently been in the process of designing an writing components of a prototype for the next version of the project I work on. I haven't been this excited about going to work in quite a while. There's nothing like designing and building something new, rather than testing and fixing bugs, and maintaining legacy code. However, today was the first full day that I had experienced the full onslaught of compiler errors that is FxCop. I felt like I was in university again. For the newbies out there, FxCop is an add-on for your .NET compiler that will check your assemblies for non-conformity and smack them down if they step out of line. It's kind of like the Borg, if the Borg had assimilated an hard-nosed, ruler-smacking elementary school teacher.
I was writing code that I thought was pretty good, but FxCop had other things to say about that. Everything from telling me not to initialize member variables to null (something that was ingrained in me to DO from an early age) for performance reasons, to standards of naming any public members of your classes, to globalization, to security considerations, to suggestions for maintainability, it really has something to say about all aspects of my code. At first, it seemed like it was pointless, like I was never going to get through the nearly-endless stream of errors produced by the tool, but slowly and surely, they dwindled to practically nothing. The only ones that remain (and I've since changed the settings so they only report as warnings) are ones that tell me that nothing is using a certain class or a particular method. Well no shit. We're in the process of building a prototype!
This was one of my favourites...take the following class:
public class FooThe compiler with FxCop tells me that I shouldn't return arrays because it could impact performance. Instead, I should return a strongly-typed collection...of bytes.
{
private Byte[] privateBytes;
public Byte[] Bytes{ get{ return privateBytes; } }
}
Whatever.
But I'm bashing a little too hard, perhaps. On the whole, it's right on the money. I think I only suppressed two or three instances of errors in all the projects that I worked on. I want to have FxCop fully turned on (does that sound dirty?) during the entire development process. Nothing makes you feel better than when what you've created conforms to just about the strictest standards out there, not just of functionality, but of aesthetics. And because nothing is worse than going back and fixing errors in reams and reams of non-compliant code.However, it can be difficult when your compiler is nudging you, nay, forcing you to implement more, and MORE just to stop the errors. FxCop is like a ghetto pusher, "Just one more method, man...come on, you can fix those errors. Just one more method." Everyone else left the office around 5:30 or so, but I stuck around until 7:15 because I couldn't stand seeing errors. And I enjoyed it.
I think FxCop and I are going to have a love / hate relationship.About a year and a half ago, I was writing a piece of software that did a lot of things in Active Directory, with Group Policy Objects specifically, but that's not relevant here. What is relevant is that I wanted to pop up a dialog to allow the user to select one or more user objects from active directory. I had used the IDSObjectPicker interface before, however, all the other times I had used it were in unmanaged C++. This was the first time I would attempt it in managed code.
For the uninitiated, IDSObjectPicker is a goddamn miserable interface. If I met its author on the street, I would punch balls first and ask questions later. It looks unassuming with only two exposed methods, but those methods belie a seething underbelly of complex nested structures and obscure enumerations. You could write a whole page of code just filling out all the required bit masks, creating arrays of other structures to assign to the previous structures, etc.
I honestly thought, given my previous fantastic experiences with C# (especially with COM interop) that this was going to be easier than before. I would reference the COM DLL in which the interface resided, and everything would be marshaled for me.
I was mistaken.
It turns out that this was my first time using COM interop with a COM interface that didn't stick to automation types (BSTR, VARIANT, etc.) for its parameters -- They would just get marshaled across the interop boundary as Objects. I spend about two days writing tedious C# code to re-create enumerated types and manually marshal as much of the parameters and return values as I needed until I got to one particular structure that vexed me.
DSOP_INIT_INFO.apwzAttributeNames
It's not even really a complicated structure. MSDN describes it as a "Pointer to an array of null-terminated Unicode strings". As simple as that sounds, I went as far as manually allocated the array's memory using the Marshal.Alloc* methods, and attempting to binary-copy the memory in an attempt to get it to take that value, but it just wouldn't.
Giving up when it comes to something I'm pretty sure is possible is not something I usually do, but I was ready to punch my monitor at this point (and it was the big, heavy, 19" CRT kind). I eventually threw in the towel and wrote a wrapper COM object in unmanaged C++ for IDSObjectPicker which translated the input parameters from automation-types to pass in, and the return values back to automation-types to pass back. That was the only way I managed to get the IDSObjectPicker working in .NET.
I recently stumbled upon this guy who had the exact same problem that I did, which is what prompted me to make this post. We're not alone.
So WHY isn't there an equivalent, .NET-ified version of this godforsaken interface?