Yield is a feature of C# that is not present in its largest competitor, Java. Many of you have heard of it, but haven’t really used it, or may have dismissed it as “syntactic sugar.” Others might have never heard of it before. In short, it’s a way of replacing this:

So what happened here? First, we’ve opted away from <code>List<int></code> for a more interface-driven <code>IEnumerable<int></code> function return. Also, we’ve reduced the number of lines; by two to be exact. And somehow, we’ve managed to return a list of items without actually allocating a new list. That’s an important point to make, because we have completely avoided instantiating a new object. Read More…

Despite the terms Dependency Inversion Principle (DIP), Inversion of Control (IoC), Dependency Injection (DI) and Service Locator existing for many years now, developers are often still confused about their meaning and use. When discussing software decoupling, many developers view the terms as interchangeable or synonymous, which is hardly the case. Aside from misunderstandings when discussing software decoupling with colleagues, this misinterpretation of terms can lead to confusion when tasked with designing and implementing a decoupled software solution. Hence, it’s important to differentiate between what is principle, pattern and technique.Read More…

I have a Windows Presentation Foundation (WPF) app currently in testing and this week it came back with some weird issues. The app uses the Client Object Model to consume SharePoint 2010 lists and UX is a factor in the design, so we’ve decided to do some metrics recording to see how people interact with the app. We want to know what features people use and which efforts were wasted.

Strangely, we started noticing that the names of the metrics (which were also being written to a SharePoint list) were displaying some incorrect results…names like “ShowAllItemsOpened” were instead “showAllMenuItem_Click.” What’s that you say? Clearly that’s the name of an event handler! Well, you’d be right! But it worked before! What changed in testing? First, some background information …

I recently ran into a problem: How to test some code that was not readily testable without carrying along a database.

It was my own fault, really. I had quickly written a data access layer that was directly dependent on Entity Framework, and was also doing some minor business logic. Because I had a direct dependency on Entity Framework, and had not used dependency injection, I had a problem… How do I write unit tests against those methods that contain business logic that also make direct calls to stored procedures through Entity Framework?

When it comes to the Web Forms vs. MVC debate, the question isn’t “Which is Better?”…but “How to Switch?”

I have been studying and trying to transition to Model-View-Controller (MVC) for about six months and I have come across some fundamental thinking that must be changed and new things that must be learned in order to make the switch. I worked with Web Forms extensively in my previous position, and since joining AIS have made a commitment to myself to embrace the switch. I am still learning, but this is what I have found so far (your results may vary).

One of the most discussed concepts about authentication today is the concept of Single Sign-On, or SSO. SSO is the ability for a user to log into one location, and authenticate across several domains without entering any additional credentials. This saves the user from having to enter several credentials for related websites, as well as possibly prevent the user from having to remember multiple logins.

While developing the Rolling Stone and Vogue Archives, we needed a SSO system that could integrate our ASP.Net based archive with each provider’s existing authentication systems, primarily Apache-based web applications. Our solution was to develop a C# implementation of mod_auth_tkt cookie-and-token based authentication system, which we have since released open source.