Gruntled n' Combobulated

Greetings!  I have a confession to make.  When I learn something, I tend to expect that knowledge to remain inviolate and don't continually check to be sure that it hasn't changed.  This is a Very Bad Thing®© TM in the programming world.  Coding conventions and guidance change all the time.  Still, as humans, we are loath to replace old, time worn techniques with new ones. Disposing done wrong For example, I learned from the .NET Framework 2.0's documentation that the IDisposable pattern consists of a "public void Dispose()" method, a "protected void Dispose(bool disposing)" method, and a finalizer.  The first method calls the second with true and then removes the object from the finalization queue.  The last method calls the second with false.  All actual disposing happens in the protected method. using System; public class ResourceUser : IDisposable {     bool m_disposed;     ~ResourceUser() ...

My team's applications rely on a large array of assemblies, some C++, some VB6, and some C#. The front end is largely a web site that is a mix of ASP and ASP.NET. We also have some Windows services - mostly C++ with a few newer ones in C#. A few of the C# assemblies are COM enabled to be usable from the C++/VB code, ASP pages, and services while others are only used by the ASP.NET. We're trying to migrate away from the VB6 code so I helped compile a list of which of the assemblies are in use by which other components. Our first pass will be to perform a direct port with COM wrappers so existing code can simply point at the new object with no API or behavior change. As we do so, we'll make a note of places where we think there are existing bugs or room for performance improvements. Have you ever performed a massive migration or upgrade? How did your team go about it? What pitfalls did you encounter as you went? With the one assembly we've ported so far, we fo...

I'm sure most experienced programmers already know that using exceptions for flow of control in a program is highly inefficient. The time it takes to unwind the stack alone is ridiculous, let alone the fact that compilers don't tend to optimize for exception paths. The question is then what to replace it with? Do you set status and return an empty or a null? Do you always return a "result" object that includes both the result state and any return types? My team is working on updating our shared components' architecture and are considering this question as we go. We've decided to move towards returning a result object and having "out" parameters for most of the new methods we're writing. While not ideal, this does mean we always use the same type of return value. We could also create subclasses of that return type with more propoerties instead of using out parameters. At the same time, I'm working on creating some unit tests for our new...

As part of my latest updates to my current project, I made a change to the underlying WCF service that provides much of the information to our Silverlight application. In one of my DataContract classes, I started passing a child class to one of its DataMembers (i.e. the DataMember is a property on Foo, I passed in a Bar which is a subclass of Foo). Then, when Silverlight called the asynchronous version of that method, I started getting an ambiguous error: "The remote server returned an error: NotFound" I stepped through both the Silverlight side and my WCF side - no errors apparent either place. However, just after the return statement in WCF and method exit, the Silverlight's service reference would pop up the "NotFound" error. Strange, I thought... what's the problem? Other web searched seemed to direct me to update the buffer size, to delete and re-add the service reference, all to no avail. Finally, I changed the type on my datacontract's datamem...

I'm in favor of test driven development. The sooner you find bugs in the product cycle the less costly the are to fix, afterall. Currently, I'm working with Visual Studio 2008 SP1 with the Silverlight tools installed - my current project is a multi-tier system with DB backend, WCF web services, and a Silverlight client. However, when I added a test project and attempted to navigate to the Code Coverage tab of my test run config, the run config editor simply closed. I tried a few of the usual suspects - devenv /resetsettings, devenv /resetuserdata, repairing my Silverlight VS add-in installation - all to no avail. Then, after one MSDN search, I discovered that this is a known issue . The fix is available here and it's working for me so far. Hooray for test enablement!

I've started my new job and am working on some data access code to IBM's DB2. I came across the following two incongruous pages in the IBM Data Server Provider for .NET reference. First, there's the DB2Connection class. In the remarks, it specifically states: The DB2Connection object uses native resources. You should always explicitly close any open DB2Connection objects by calling Close or Dispose before the DB2Connection object goes out of scope However, on the DB2DataAdapter class reference page, they happily ignore their own advice. They also fail to mention that DB2DataAdapter is disposable and should be handled as such. Here's my recommendation for new sample code: public DataSet SelectDB2SrvRows(DataSet dataset,string connection,string query) { using (DB2Connection conn = new DB2Connection(connection)) { using (DB2DataAdapter adapter = new DB2DataAdapter()) { adapter.SelectCommand = new DB2Command(query, conn); ...