GenXJamerican

Came across this via Larkware.  I’ll have to make sure this code finds its way into our custom base pages.

I didn’t know such a thing existed before today, but thanks to a couple of consultants in my office, now I do. The cleverly-named BizUnit is available at codeplex.

The information on this project indicates no dependencies on any existing unit-testing frameworks (NUnit, MbUnit, etc).  Having not used BizUnit, I’m not sure whether that’s good or bad either way.

How do you unit test an assembly if the vast majority of its methods are declared “internal” (in C#)? Before today, I had no idea. Fortunately for me, one of my consultants had this exact problem last year. The solution:

[assembly: InternalsVisibleTo("UnitTestAssemblyName")]

This is a vastly superior option to cloning the assembly you want to test and making all the internal members public.

Personally, I dislike them. I avoid using them whenever possible. But I came across this excellent post that talks about cursors, alternatives to cursors, and provides a performance comparison between them.

The performance comparison in particular was quite useful.  If I’m able to reproduce the results for myself in a local environment, I may have to revise my current stance on cursors.

We came across this on one of my current projects. It didn’t prevent the application from working, but I didn’t want a bunch of instances of it in our error logs. One of the consultants who works for me found this Knowledge Base article that solved the problem.

The basic fixes are:

• Call Response.Redirect like this:

  Response.Redirect ("nextpage.aspx", false);

• Call Server.Execute instead of Server.Transfer

Last week revealed an interesting difference between C# and VB.NET. C# operators like “and” (&&) and “or” (||) do it automatically. The VB.NET operators “And” and “Or” don’t do this by default. So if you use these, all the conditions are evaluated, regardless of whether or not that’s necessary.

In the .NET 2.0 Framework, instead of making these operators work like the C# ones, VB.NET added two new keywords: AndAlso and OrElse.

It’s good that VB.NET has the facility, I just don’t like the implementation.  It’s another reason to prefer C# at the very least.

It seems clear enough to me which approach is the best way to develop software, but not everyone in my office seems to agree. So I thought I’d do a bit of research on the two approaches and summarize my findings here. I really wanted to find some impartial statistics that compared the productivity of the two approaches. In addition to the usual Google searches, I included information I could find from the Software Engineering Institute (SEI) and the Association for Computing Machinery (ACM).

The first comparison of the methodologies I reviewed was on pages 23-24 of a PDF I found at SEI. The comparison mapped waterfall activities to agile activities and highlighted the key difference–the waterfall methodology lacks an opportunity to demonstrate the output of an iteration and make improvements based on feedback.

The first statistics I could find came from this wiki entry. While they’re specific to a single company, they make a very compelling case for the use of agile methods. Agile methods (specifically SCRUM) delivers more lines of codes, with fewer defects, in less time than waterfall methods.

Another free e-book, this time on C# and VB.NET development standards.  Fair warning, you do have to provide an e-mail address to download it.

We’ve needed something like this at my current employer for a long time.  Come to think of it, my previous employer could have used this too.  I worked with some colleagues to put together a small SQL standards guide to direct our database development.  I wanted to write a companion document for our .NET development efforts but have had far too much other work to do.

Charles Petzold has written a book titled .NET Book Zero.  It’s a guide to implementing application in C# targeted at C and C++ programmers.  I haven’t read it myself yet, but I plan to.  I hope it’s a resource I can use to help build the skills of developers that report to me who aren’t familiar with C#.

The author has made it available in PDF and XPS formats.  There’s source code too.

I wasn’t aware of the existence of SPUnit until a consultant mentioned it yesterday.  I’m not sure how deeply I’ll look into it (if at all) because of how many other testing frameworks that I really need to understand.

I came across this blog post today while researching a problem with one of our applications. The most interesting thing I found about this article was the comparison between VB.NET and C#. It’s one of a few I’ve seen that goes beyond the syntactic differences to deeper issues. The examples in this article show cases where C# wouldn’t even compile code that runs in VB.NET (and throws exceptions at runtime). C# makes you work harder to write code that compiles and throws exceptions at runtime. It’s yet another argument in favor of C# I hadn’t considered before reading this post.

Maybe I should institute this at my office on Monday.