RIP ANDY IRONS: 1978-2010

by jmorris 3. November 2010 03:25

Bummer for the surfing world, 3x ASP world champion surfer Andy Irons tragically died yesterday reportedly from Dengue fever while returning to Hawaii from Puerto Rica. I never knew him personally, but he was much admired and loved by surfing fans world-wide;  as a fan I have followed his career since he was 17. Unfortunately he leaves a pregnant wife,  father and brother (Bruce Irons another professional surfer) – my regards go out to them. Mahalo Andy, you will be missed!

Tags: , , ,


Design Fail

by jmorris 28. October 2010 13:59

While I am not much of a front end developer or much less a designer,  the design elements of some sites are so poor, that even I shake my head in disbelief. While doing some research for a future post on refactoring and method groups, I came across this site:


Note that the site is all flash and you navigate with that teeny, tiny little menu thing!  As you click the on the menu item squares the flash app moves another layer into focus which contains quotes from various famous people. The problem is, WTF does the company even do? It took me awhile navigating through this maze to find out they are a marketing company…apparently the focus on “creating customers”. Maybe the should focus on “communicating with customers” first.

BTW, here is the “Clients Page”:


Is it any wonder?

Tags: , ,


More VS2008 to VS2010 Blues

by jmorris 21. October 2010 09:32

I ran into another problem today while updating my VS2008 projects to VS2010. Instead of using the typical Visual Studio Conversion wizard, I wanted to refactor some of my projects into a single project so I created the projects first and then manually copied the files over changing namespaces as I went along. After creating a project for a tool that runs as a console application and moving over the file with the main() method, I got the following exception:

“The referenced assembly ‘D:\XXX.Prism.dll’ could not be resolved because it has a dependency on ‘System.Web.Extensions, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ which is not in the currently targeted framework ‘.NETFramework,Version=v4.0,Profile=Client’. Please remove references to assemblies not in the targeted framework or consider retargeting your project.    XXX.Prism.Damsole”

Whoa, kinda strange…I checked Framework Target on the Properties page and saw that it was:


.NET Framework 4 Client Profile? What’s that? A quick google gave me the answer:

“The .NET Framework 4 Client Profile is a subset of the .NET Framework 4 that is optimized for client applications. It provides functionality for most client applications, including Windows Presentation Foundation (WPF), Windows Forms, Windows Communication Foundation (WCF), and ClickOnce features. This enables faster deployment and a smaller install package for applications that target the .NET Framework 4 Client Profile.”



It turns out that the project I was referencing had a reference to System.Web and since by default VS2010 sets the Target Framework for console applications to the .NET 4 Framework Client Profile, which excludes the following features:

  • Advanced Windows Communication Foundation (WCF) functionality
  • .NET Framework Data Provider for Oracle
  • MSBuild for compiling

Resolution was simple, I just changed the Target Framework to .NET Framework Profile and all was good. It seems kind of strange that MS would default that kind of behavior when it seems to me to be more of an optimization more than anything else and can cause quit a bit of confusion.

Tags: , ,

Visual Studio

404 Errors When Upgrading ASP.NET 3.5 Web Sites to ASP.NET 4.0

by jmorris 20. October 2010 16:19

After upgrading our projects from Visual Studio 2008 to Visual Studio 2010 and modifying our deployment scripts to to use the 4.0 compiler, we ran into another issue with HTTP 404 errors after deploying to our development environment:


Running through the checklist:

  • Is ASP.NET 4.0 Installed? Check!
  • Is ASP.NET 4.0 running? Check!
  • Is IIS running? Check!
  • Is the source code deployed? Check!
  • Is the Web site configured properly in inetmgr? Check!
  • Any host file entries causing problems? No. Check!

Blah, what could be causing this? A comrade of mine (thanks Scott) figured this one out: you have to enable IIS to run the ASP.NET 4.0 extension:


To do enable the ASP.NET 4.0 Extensions, do the following:

  1. Fire up intemgr: Start=>Run=>”Inetmgr”
  2. Select the “Web Services Extension” folder
  3. Locate the ASP.NET v4.0.X entry
  4. Right click on it and select “Allow”

That’s it!

Tags: , , , ,


Dynamic Types Make Unit Testing JSON in ASP.NET MVC a Breeze!

by jmorris 18. October 2010 22:57

The new dynamic type in C# 4 was mainly added to offer simpler creation of objects using reflection and the ability to treat objects as they are no matter where they were created: COM interop, DLR, etc. It basically defers static typing until runtime. The object itself is statically typed, however the compiler bypasses compile-time static type checking until runtime.

One place where this kind of late bound typing is really useful is unit testing ASP.NET MVC action methods that return JSON via JsonResult. For example, given the following controller action method:


And the following unit test you’ll quickly discover that while you can see the values as a watch in Visual Studio or while debugging, you cannot actual run an assert on any of the members (Assert.AreEqual(1, data.FeedId) will throw an exception:


It should be relatively obvious as to why this will not work, notably anonymous types are internal to the assembly that they were created in and results.Data returns a System.Object. Using the dynamic keyword, one might assume that the we should be able to run asserts on the properties of the JSON result, but unfortunately, it’s not that simple:


The exception gives some subtle hints as to what the problem is:

'MyFantasyFootBallGuruTests.Controllers.AlertsControllerTests.GetCurrentPick2' failed: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException : 'object' does not contain a definition for 'FeedId' at CallSite.Target(Closure , CallSite , Object )  at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0) Controllers\AlertsControllerTests.cs(47,0): at MyFantasyFootBallGuruTests.Controllers.AlertsControllerTests.GetCurrentPick2()

Well it’s somewhat of a hint…the object does not contain a definition for ‘FeedId’ is caused by the fact that while we can see the values with the debugger, the reality is that the ‘object’ is really an anonymous type, which exists in the assembly containing the controller. Since anonymous types by definition are always internal to the assembly they are defined in, the runtime throws an exception. Fortunately, the fix is for this is easy.

When you create a new project (assembly) in Visual Studio, a “Properties” folder with a class called “AssemblyInfo.cs” is automatically created. This class contains attributes that define the metadata of the assembly: the name, description, title, whether or not the assembly is visible to COM components, the version, and other information related to the assembly. There is also another very important attribute to those wishing to test anonymous types in assemblies other than the assembly that the anonymous type is defined in: InternalsVisibleToAttribute.

The InternalsVisibleToAttribute makes types that are normally only visible in the defined assembly to other assemblies specified in the attribute. For instance:


Adding this attribute to the assembly that contains the controller classes, makes any anonymous types visible to the unit test assembly, MyFantasyFootballGuruTests. After adding this attribute, the unit tests will not only compile, but allow the properties of the anonymous type to be tested:



Tags: , , , , , ,

Unit Testing

Upgrading ASP.NET Projects from VS2008 to VS2010

by jmorris 15. October 2010 17:44

I recently upgraded several solutions/projects from VS2008 to VS2010 and ran into a few snags. The following covers some of the issues I have run into and how I fixed them.

First thing I did was use the Visual Conversion  Wizard to convert the solution and projects from VS2008 to VS2010, which is pretty simple. Just write click on the solutions and select “Open with Microsoft Visual Studio 2010”:


You will be prompted with by the Visual Studio Conversion Wizard:


Select “Next” and then “Finish”. You will then be prompted with a dialog wanting to know if you want to upgrade Web sites that were configured to run under the an earlier version of VS (in this case 2008):


What this does is add the targetFramework entry to your Web.Config file to “4.0”, so that IIS knows to which version of .NET to run under:


After you answer “Yes” to these dialogs and assuming nothing went wrong with your conversion, the “Conversion Complete” dialog will appear:


Thus far, for me everything went according to plan, however when I went to build the solution I ran into some errors:


For some reason two of the references were not resolved, so using the “Add References” dialog I added the two references thinking they must have just become “unreferenced” and got the following error:


What the heck? Didn’t I just upgrade those to VS2010 (.NET 4.0)? Well, actually it turns out I did, however the other assemblies (this one included) were still compiling under .NET 3.5. So, pretty easy to fix, just right click on each project and select “Properties” and then on the “Application” tab select the appropriate .NET Framework:


You have to do this for each project in the solution. Now thinking that everything has been resolved, I built the projects and while I was expected a nice “Build succeeded” message, I got:


Yikes, that was not what I expected to see! Notice that all of the error’s were of the form:

“The type name 'X' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.”

All of the errors were related to code referencing ASP.NET’s Membership and Role API’s and the “This type has been forwarded to assembly ‘System.Web.ApplicationServices’ was a huge, massive hint as to what was going on. So I added a reference to System.Web.ApplicationServices:


And then I did another build which completed successfully.


The conversion in my opinion was pretty straight forward, even though I ran into a few scenarios that the Conversion Wizard could not handle. I am pretty experienced with  updating solutions/projects from previous versions of .NET; I could see where a somebody less experienced with VS projects and solutions would run into some trouble, but for the most part it was pain-free. As long as you read the error messages and consider what may be causing them, you shouldn’t run into to many problems.

Tags: , , ,

Visual Studio

ViewState Fail…

by jmorris 13. October 2010 01:30


I _really_ despise ViewState…from the page bloat to the innocuous ViewStateException errors that litter my logs: “The state information is invalid for this page and might be corrupted”. For the little bit of good it does persisting state between postbacks, it causes huge amounts of grief…I guarantee I have spent more time circumventing it’s grasp than embracing it’s utility.

Tags: , ,


The Differences between the Average PHP and ASP.NET Developer

by jmorris 5. October 2010 15:47

I have been interviewing for a number of different positions in the company I work for and have begin to notice a number of core differences between “average” PHP and ASP.NET developers.

The positions in most cases are similar: front end web developer. In a nutshell, the following are some of my “hasty generalizations” from interviewing multiple developers from both camps.

PHP Developers

  • PHP developers in general are far better at traditional web developer skills such as CSS, XHTML, JQuery/JavaScript…in general making things look really nice, maintaining Web standards compliance and resolving cross browser issues.
  • PHP developers tend to understand the basics of SEO (importance of URL structure, clean XHTML, importance of H1, H2…, meta description and keywords, etc).
  • PHP developers understand how the Web in general works, they know what REST means and they know why REST is used.
  • PHP developers aren’t too interested software patterns, architecture or software engineering in general…any good means to an end is justification enough.
  • When you ask them about AJAX they say things like “JSON”, “DOM”, “$.ajax()”, and “XHR”
  • Can hand code HTML
  • Will tolerate embedded SQL in their pages
  • Don’t unit test

ASP.NET Developers

  • ASP.NET developers say that the know CSS, but they usually really don’t. The better one’s know that tables are evil and should be avoided at all costs, however some do not. Basically, CSS and HTML are the domain of the Web designer.
  • ASP.NET Developers tend to not understand the basics of SEO; most ASP.NET developers work on intranet style projects or Web applications, not Web sites so they lack this important skill set.
  • ASP.NET developers think that REST is a “buzzword” and therefore must gone on the resume, but they really don’t understand what it means: “Well, I don’t really know the theory, but I know how to Google really well!”.
  • ASP.NET developers tend to know the basics of Agile processes (but often confuse it with any ad-hoc development) and software engineering in general. They tend to have a superficial understanding of patterns, but aren’t hell bent on the practice.
  • When you ask them about AJAX they say “AJAX Toolkit” and “Update Panel”
  • Think that an HTML is the result of dragging something from your toolbox of their IDE.
  • Know Linq2Sql and have heard of the Entity Framework and NHibernate. In general understand the importance of layering applications.
  • Don’t unit test….it takes too much time and is too hard, but they “have read about it” and agree it would be a good thing given they had the time.

Note that this does not apply to all developers; there are definitely some diamonds in the rough, but those are the exception. Also, note that if you are reading this you are probably the exception in that most developers do not read blogs; they reach into their bag of Google for answers and then find the search result that allows them to copy and paste the solution.

Tags: , ,


ActiveMQ via C# Part 3: Simplifying the API using a Provider Pattern

by jmorris 24. September 2010 16:05


In my previous posts I developed simple sender and receiver classes for topics and queues using Apache.NMS and ActiveMQ. In this post I will use the provider pattern to simplify creation and management of NMS connections, senders and receivers. Additionally, I’ll improve the syntax and ease of using NMS by adding fluent-interface behavior to the sender and receiver classes previously developed in part 1 and part 2, as well as a little refactoring to better manage the lifetime of the objects.


Provider Pattern Background

The provider pattern is a software pattern developed at Microsoft during the development of ASP.NET 2.0 and used pretty extensively in that release. The most noticeable implementation was the Membership API, where the data storage of your security was abstracted away from the implementation. The aim is the pattern is loose coupling similar to what is provided by an IoC and DI, such as Ninject or Windsor container via settings in a configuration file as injected parameters.

There has been a bit of debate over whether or not it is a true pattern with most people agreeing that it’s a really several patterns or simply another pattern with a different name; most notable the Factory and Strategy patterns in some circles and the Singleton or Bridge patterns in others. The Bridge pattern definition most closely matches the goals of the pattern:

"decouple an abstraction from its implementation so that the two can vary independently"

- Gamma, Helm, Johnson, and Vlissides (gof)

As far as I am concerned it is a sort of hybrid pattern; a composition of patterns if you will.

Provider Pattern Implementation

The provider pattern itself is deeply ingrained within .NET itself; there is even a namespace with base classes supporting the pattern – System.Configuration.Provider. This namespace contains the following base classes, BaseProvider and ProviderCollection which are the building blocks of configuration based providers. System.Configuration adds another abstract class that makes working with .NET configuration files easier. Note that you could in theory create your own provider implementation without using these classes, but they provide an easy to follow framework for making providers using .NET.

The following diagram illustrates the entire provider implementation:


Here is a rundown of the various classes required:

  • NmsProvider – derives from BaseProvider and provides initialization for the provider plus factory methods for creating NMS senders and receievers. Only one instance of a configuration should exist for an AppDomain or process and all operations should be thread safe.
  • NmsProviderCollection – derives from ProviderCollection and maintains a list of configured providers. For example you could have providers configured for multiple ActiveMQ servers i.e. receive from one server and send to another.
  • NmsProviderConfigurationSection – provides a defined section in your configuration file for each provider implementation.
  •  NmsProviderService – a singleton ‘service’ for maintaining the collection of providers while your application is running. Note that providers are long lived objects, hence the need for a singleton to maintain the list.

The NmsProvider class is really a façade encapsulating the interaction between the JMS broker and the client’s it services. From a client perspective it manages the connection between the client and the JMS broker, the sessions that are generated per conversation, as well as the creation of objects for sending JMS messages to receiving messages from destinations (queues and topics). An important point to remember is that JMS Connections are heavyweight, long lived objects and are typically created 1:1 with clients, which “fits” well with the lifecycle of providers.

All providers use configuration files to store the type of provider to initialize and any additionally information that must be injected into the newly created instance. Note that this is a form of Dependency Injection (DI). The configuration file may contain configurations for multiple instances of each provider configured differently. For example, each provider may be using a different broker to send or receive messages. Here is a listing of a configuration that lists several provider instances using the same broker:


When the NmsProviderService is created, it will read the contents of NmsProviderConfigurationSection and construct providers for each entry in the “providers” section; in this case two providers are listed: NmsProvider0 and NmsProvider1. The System.Configuration namespace contains a special class to help in creating the providers called ProvidersHelper. After the providers are created they are added to the NmsProviderCollection, which is a thread safe collection of providers.

When the provider is created by the ProvidersHelper.InstantiateProviders method in the NmsProviderService class, the overriden ProviderBase.Initialize method will be called in the NmsProvider class. The Initialize method will assign the values stored in the configuration file to their respective properties on the NmsProvider class and then create an instance of the Apache.NMS.ConnectionFactory class.


As previously discussed, the NmsProvider is façade encapsulating the interaction between the JMS server and the clients that it services. It is also a factory in that it offers methods for creating objects for sending and receiving messages. Notable it hold references to Apache.NMS.IConnection and Apache.NMS.IConnectionFactory objects. The IConnectionFactory class is a factory for creating IConnection instances based on the configuration supplied.

Clients use providers by name via and indexer on the NmsProviderService after calling the Start() method on the provider to create the connection between the client and the JMS server:



The Start() method creates a new IConnection if the provider does not have one already initialized. Then it checks to see if the IConnection is started, if not then the IConnection’s Start() method is called which establishes the connection with the JMS server.  Additional methods on the provider allow the IConnection to be temporarily stopped or permanently closed:


Once the provider has been initialized, the usage is quite simple:


**Make sure you have ActiveMQ running and your configuration file is configured with the appropriate uri. See for details on how to get ActiveMq up and running on a windows box.




Tags: , ,

Apache.NMS, JMS

Two Questions that Most ASP.NET Developers Cannot Answer

by jmorris 10. September 2010 13:44

After interviewing approximently 30 applicant's for mid-level to senior level ASP.NET positions, nearly all cannot answer the following two questions:

  1. Describe the following access modifiers:
    1. private
    2. protected
    3. internal
    4. public
  2. What is the difference between an ASP.NET Literal control and a Label control

If they answer one of the two questions above, we bring them in for a more in-depth test and then subsequent interviews if they get a passsing score on the test. The first question is among the most basic of questions you can ask someone regarding the language we use, C#. The other is a simple question regarding the output of two ASP.NET WebForms controls...note that the average applicant has multiple years experiance (per their resume) on the WebForms platform. Also, before you say "why aren't you using MVC?", that statement is irrelevent to the questions.

Would you believe 1 in 10 developers (that I interviewed) cannot answer both questions? Sad, really...



Jeff Morris

Tag cloud

Month List

Page List