MEF allows your to declare your exports as either singleton or transient. The default policy is to create all parts (aka exports) as a singleton. What this means is that the MEF container will search inside the specified catalogs and providers to find your export. Once it does, it will create an instance of it and reuse it forever. That’s good if your exports aren’t storing any state. But if they are, then you’ll have to override the default policy by making your exports transient. You can do so by adding the below attribute to your class:

[PartCreationPolicy(CreationPolicy.NonShared)]
[Export(typeof(MyType), "MyRuleset")]
public class MyExportClass 
{
}

Hope this saves you the time that it took me to find this little nugget!

Happy Coding!

[SocketException (0x2746): An existing connection was forcibly closed by
the remote host]
[IOException: Unable to read data from the transport connection:
An existing connection was forcibly closed by the remote host.]
[WebException: The underlying connection was closed: An unexpected
error occurred on a receive.]
[CommunicationException: An error occurred while receiving the HTTP
response to http://myservice.mydomain.dk/MyService.svc. This could
be due to the service endpoint binding not using the HTTP protocol.
This could also be due to an HTTP request context being aborted by
the server (possibly due to the service shutting down). See server
logs for more details.]

Of the many reasons why you might see this exception, one is that the return value of a WCF service method cannot be of type System.Collections.IEnumerable or System.Collections.Generic.IEnumerable. If it is, then you’ll see the very informative and totally relevant (yes, I am being sarcastic) exception above when you try to consume the method on the client-side!

The solution of course is to change the service method definition to return an array.

In short, I had to write a method that adds a WCF behavior to a VS-generated WCF proxy class. What I wanted to do is something like the following:

public void AddCommonWcfBehavior(ICommunicationObject wcfClientProxy)
{
    ClientBase wcfClientBase = wcfClientProxy as ClientBase;
    wcfClientBase.Endpoint.Behaviors.Add(new MyCommonWcfBehavior());
}
/* Note that the method is taking in an object to type 
    'System.ServiceModel.ICommunicationObject' which is the base-level 
    interface for all WCF client proxies.
*/

However, I couldn’t do this for the simple reason that ClientBase<> is a generic class and .NET does not provide a non-generic version. Go figure! And no, for reasons that are too detailed to list here, I could not make AddCommonWcfBehavior() a generic method. I wish .NET offered a non-generic ClientBase class. But it doesn’t and thus I was stuck!

It was then that I remembered reading about the dynamic keyword not too long ago. Using the dynamic keyword, the method looks like the following (and works as expected):

public void AddCommonWcfBehavior(ICommunicationObject wcfClientProxy)
{
    dynamic wcfClientBase = wcfClientProxy;
    wcfClientBase.Endpoint.Behaviors.Add(new MyCommonWcfBehavior());
}

So the moral of the story: Keep the dynamic keyword in mind! In some cases, it may be your one and only savior!

These settings/configurations overlap and differ across countries. The goal, of course, is to design/implement the code in a way that enables us to reuse code that is common across countries. Below is the scenario that we are dealing with,

• USCustomer.FeatureA() is the same as CACustomer.FeatureA()
• USCustomer.FeatureB() is the same as KRCustomer.FeatureB()
• CACustomer.FeatureC() is the same as KRCustomer.FeatureC()
• KRCustomer.FeatureA() differs from USCustomer.FeatureA()
• CACustomer.FeatureB() differs from USCustomer.FeatureB()
• USCustomer.FeatureC() differs from CACustomer.FeatureC()

The first attempt was of course to try and solve this via sub-classing. Let’s look at the different options that we have for sub-classing:

1. Make CA & KR sub-classes of US. This allows us to re-use USCustomer.FeatureA() for CA and USCustomer.FeatureB() for KR. But it doesn’t allow us to re-use CACustomer.FeatureC() for KR.
2. Okay, no problem, you say. We’ll just make KR a sub-class of CA. So, CA is a sub-class of US and KR is a sub-class of CA. But then we run into the issue that USCustomer.FeatureB() can no longer to be re-used for KRCustomer.FeatureB().

Now imagine this kind of situation spread across 15 different countries. Ouch! So sub-classing clearly is not the answer.

It sounds like we need some sort of “strategy” that’ll let us swap/differ settings and configurations across countries without all this coupling. Well the strategy is to apply the Strategy design pattern. Below is the overall strategy:

1. Encapsulate the features: Each feature gets its own class. So we end up with the following classes:

   Customer
   CACustomer
   KRCustomer
   FeatureA : IFeatureA
   FeatureB : IFeatureB
   FeatureC : IFeatureC
   FeatureA1 : IFeatureA
   FeatureB1 : IFeatureB
   FeatureC1 : IFeatureC
   

2. Setup the constructor of the Customer class to take in the concrete class that is specific to the feature that they require as a parameter. For instance,

   public class Customer
   {
      public Customer() : 
        this(new FeatureA(), new FeatureB(), new FeatureC())
      {  }
    
      public Customer(IFeatureA a, IFeatureB b, IFeatureC c)
      {
         featureA = a;
         featureB = b;
         featureC = c;
      }
    
      public void DoInitialSetup()
      {
         SetupFeatureA(featureA);
         SetupFeatureB(featureB);
         SetupFeatureC(featureC);
      }
    
      private IFeatureA featureA;
      private IFeatureB featureB;
      private IFeatureC featureC;
   }
    
   public class CACustomer : Customer
   {
      public CACustomer() : 
        base(new FeatureA(), new FeatureB1(), new FeatureC1())
      {  }
   }
    
   public class KRCustomer : Customer
   {
      public KRCustomer() : 
        base(new FeatureA1(), new FeatureB(), new FeatureC1())
     {  }
   }

And voila! We can now swap implementations across countries and add different implementations for different countries as needed.

The above example was simplified to effectively demonstrate the Strategy pattern without confusing the reader. In particular, in the above example, the customer classes directly instantiate the features that they need. This is generally a bad idea in practice for at least two reasons:

1. It makes it difficult to unit test the Customer class.
2. Each type of customer is still coupled to the specific feature-set that it is using. In other words, the features cannot be changed dynamically.

Instead of directly instantiating the classes, we should be using an IOC container to handle the object instantiations and configurations.

For instance, for our application, we are using an XML file to tie concrete implementations with their respective countries. Below is an example:

DefaultLocalization.xml

<interface name="IFeatureA">
  <class name="FeatureA">
</interface>
 
<interface name="IFeatureB">
  <class name="FeatureB">
</interface>
 
<interface name="IFeatureC">
  <class name="FeatureC">
</interface>

CALocalization.xml

<interface name="IFeatureB">
  <class name="FeatureB1">
</interface>
 
<interface name="IFeatureC">
  <class name="FeatureC1">
</interface>

KRLocalization.xml

<interface name="IFeatureA">
  <class name="FeatureA1">
</interface>
 
<interface name="IFeatureC">
  <class name="FeatureC1">
</interface>

Based on the current country, the right classes get instantiated. If we ever need change KR to use FeatureC instead of FeatureC1, all we do is make the change in the XML file and we’re done.

So, in conclusion, the key to the strategy pattern is encapsulation: Remove the logic that differs from the logic that stays the same via encapsulation.

ALTER TABLE SomeTable
	ADD CONSTRAINT unique_key
	UNIQUE (ColumnOne, ColumnTwo, ...)

• Is your blog site returning the infamous “500 – internal server error” more often than not?
• Are you using WordPress as your blog publishing platform?
• Are you using GoDaddy as your website hosting provider?
• Are you using IIS as your web server (as opposed to Linux)?

If yes, continue reading to fix this issue:

There is weird configuration issue with running WordPress with a IIS web server on GoDaddy. Taking the following actions will resolve this issue:

1. Upgrade WordPress to the latest version. Detailed instructions at: Upgrading WordPress
2. Install WP-Super-Cache plugin. Here is the download link for it. In order to enable the plugin, you have to do a little tweaking. Below are the steps you need to follow:
   • First off, extract the ‘wp-super-cache’ folder into your ‘wp-content/plugins’ directory.
   • Log in to your GoDaddy account and navigate to Hosting -> Manage Account.
   • Click on the Content tab and select File Manager.
   • Here you will see all your files and folders. Check the wp-content folder and click the Permissions icon on the top. Uncheck Inherit and check the Read and Write checkboxes. Don’t worry this is only temporary to get your plugin working correctly. Save your changes.
   • Now Enable the plugin by going to your WordPress Plugins page.
   • Next you will have to enable caching. For this, go back to your File Manager and browse to the “wp-content/cache” folder. Change the permissions on this folder to Read/Write as well.
   • Now open up the wp-config.php page that’s in the root directory and add the following line towards the end: define(‘WP_CACHE’, true)
   • Go back to the Settings page for the wp-super-cache plugin and set the status to ON. Make sure to save your settings. You may see a warning about apache mod_rewrite not enable or installed. Don’t worry about this warning. This just means that your caching will only be HALF-ON which is fine because even it being HALF-ON will fix our ’500 – internal error’ issue.
   • Go back to the File Manager and change the permissions on the wp-content folder to Inherit.
   • Your website should now respond faster and stop generating the 500 – internal server error issue.
3. As an additional security measure, I would also recommend installing the WP-SpamFree plugin. This is a very effective plugin that will eliminate virtually all SPAM comments. Thus decreasing the load on your website.

If that still doesn’t fix the “500 internal server error” issue, then try updating your current WordPress theme or switch to a different WordPress theme. If that doesn’t work either, then it’s time to bite the bullet and switch to Linux! ]]> http://nizarnoorani.com/index.php/archives/212/feed 6 http://nizarnoorani.com/index.php/archives/173 http://nizarnoorani.com/index.php/archives/173#comments Mon, 01 Feb 2010 23:01:05 +0000 Nizar http://nizarnoorani.com/?p=173 Imagine the following (which you’ve very likely run into in the past):

You join a new company and inherit a humongous existing code base. You are told to add some new functionalities without of course breaking existing functionality. “No problem”, you say! “I’ve done this before.”

You’ve got clear requirements and complete access to the existing code base. After some investigation, you figure out that you need to add a few methods to an existing class. One of these methods is:

CustomerService.CanPurchaseProduct(int productId)

The existing CustomerService class looks somewhat like the following:

public class CustomerService
{
   public CustomerService(int customerId)
   {
      custManager = new CustomerManager();
      cust = custManager.GetCustomer(customerId);
   }
 
   ...other methods...
 
   private CustomerManager custManager;
   private Customer cust;
}

You will also be utilizing an existing class named ProductService. Below is a bare-bones outline of this class:

public class ProductService
{
   public ProductService(int productId)
   {
      prodManager = new ProductManager();
      prod = prodManager.GetProduct(productId)
   }
 
   ... other methods below .....
 
   private ProductManager prodManager;
   private Product prod;
}

Your requirements state the following:

– Product must be in stock
– Customer must be a member IF product is for members only

Being the good developer that you are, you start, of course, by writing the unit tests. They look something like the following:

[TestCase]
public void CanPurchaseProduct_InStockAndForAll()
{
      int customerId = 123;
      int prodId = 1;
 
      //TODO: Mock this scenario
      CustomerService svc = new CustomerService(customerId); 
     Assert.IsTrue(svc.CanPurchaseProduct(1));
}
 
[TestCase]
public void CanPurchaseProduct_NotInStock()
{
      int customerId = 123;
      int prodId = 1;
 
      //TODO: Mock this scenario
      CustomerService svc = new CustomerService(customerId); 
     Assert.IsFalse(svc.CanPurchaseProduct(1));
}
 
[TestCase]
public CanPurchaseProduct_NotAMember()
{
      int customerId = 123;
      int prodId = 1;
 
       //TODO: Mock this scenario
      CustomerService svc = new CustomerService(customerId); 
     Assert.IsFalse(svc.CanPurchaseProduct(1));
}

Your initial implementation of the CanPurchaseProduct() method looks like the following:

public class CustomerService 
{
    public bool CanPurchaseProduct(int productId)
    {
       ProductService prodService = new ProductService(productId);
       if(!prodService.IsInStock())
         return false;
 
       if(prodService.IsMembersOnly() && !custService.IsMember())
         return false;
 
      return true;
    }
}

If you’re familiar with unit tests, you’ll recognize an issue right away: The way the implementation currently stands, it is impossible to mock out the different scenarios that we have coded for in our test cases. The reason for this is tight coupling and lack of abstraction. The CustomerManager, ProductService and ProductManager classes are being directly instantiated by the classes that use them – an example of tight coupling. Furthermore, the classes do not implement an interface thus making it impossible to substitute mock versions for them – a direct result of lack of abstraction. So how do we fix this with minimal changes to the existing classes? Below is one strategy:

1. Account for dependencies

The first step is figure out the dependencies. A dependency is any class, resource file, configuration file, etc. that your code is using either directly or indirectly. In our case, we have the following dependencies:

- CustomerManager
- ProductService
- ProductManager (used by ProductService).

2. Make the dependencies “plug-and-play”

Now that we know what the dependencies are and the places where they exist, our next step is to remove all the “knots” so that we can make them plug and play. By “knots”, I refer to statements like the following:

   - custManager = new CustomerManager()
   - productService = new ProductService()  
   - prodManager = new ProductManager()

Instead of the classes directly instantiating dependencies, the idea is to provide it to them. This technique is know as Dependency Injection. There are multiple ways of doing this. Keeping in mind that we need make a minimum number of changes to the existing code base, we’ll go with the simplest one:

Modify the constructors/methods to take in the dependencies as parameters.

This is illustrated below:

public class CustomerService
{
   //Instead of directly instantiating, we pass in the dependency.
   //All new classes can now start using this one to allow for unit      
   //testing.
   public CustomerService(int customerId,  
     CustomerManager custManager)
   {
      cust = custManager.GetCustomer(customerId);
   }
 
   //Original constructor becomes empty.  
   //We still need to keep it around since it is probably used other
   //existing classes
   public CustomerService(int customerId) : 
       this(customerId, new CustomerManager())
   { }
 
   ...
 
   //Note that the method is now taking ProductService as a parameter
   //instead of directly instantiating it.
   public bool CanPurchaseProduct(int prodId, 
        ProductService prodService)
   {...}
}
 
public class ProductService
{
   //Instead of directly instantiating, we pass in the dependency.
   //All new classes can now start using this one to allow for unit      
   //testing.
   public ProductService(int productId, ProductManager prodManager)
   {
 
   }
 
   public ProductService(int productId) : 
     this(productId, new ProductManager()) {}
}

Note: When it comes time to re-factor/re-design/re-architect (whatever you want to you call) your entire application, you should go with a better alternative to handle dependency injection instead of the approach shown here. I would recommend using a tool such as Spring .NET.

3. Abstract them away!

The final step then is create an interface for each of the concrete classes and replace all references to the concrete classes with their associated interfaces.

public interface ICustomerService
{
  bool CanPurchaseProduct(int customerId, IProductService  
    prodService);
}
 
public interface ICustomerManager {...}
 
public interface IProductService {...}
 
public interface IProductManager {...}
 
public class CustomerService : ICustomerService 
{
  public CustomerService(int customerId, ICustomerManager)
  {...}
 
  public bool CanPurchaseProduct(int prodId, IProductService 
    prodService) 
  {...}
}
 
public class CustomerManager : ICustomerManager {...}
 
public class ProductService : IProductService 
{
  public ProductService(int prodId, IProductManager) 
  {...}
}
 
public class ProductManager : IProductManager {...}

Now, we can finally substitute our mocks for the dependencies in our unit tests as shown below. Note that in the test cases below I am using the Moq Unit Testing Framework to setup the mocks but you could use any other framework that you’d like or none at all (if you wish to create the mocks manually).

[TestCase]
public void CanPurchaseProduct_InStockAndForAll()
{
   int customerId = 123;
   int prodId = 1;
 
   //create mocks
   Mock<ICustomerManager> custManager = 
     mockFactory.Create<ICustomerManager>();
 
   Mock<IProductService> prodService = 
      mockFactory.Create<IProductService>();
 
   Customer cust = new Customer(123);
   cust.IsMember = false;
 
   //setup mocks
   custManager.Setup(cm => cm.GetCustomer(123)).Returns(cust);
 
   prodService.Setup(ps => ps.IsInStock()).Returns(true);
   prodService.Setup(ps => ps.IsMembersOnly()).Returns(false);
 
   //run test
   CustomerService svc = new CustomerService(customerId, custManager.Object); 
   Assert.IsTrue(svc.CanPurchaseProduct(1, prodService.Object));
}
 
[TestCase]
public void CanPurchaseProduct_NotInStock()
{
   int customerId = 123;
   int prodId = 1;
 
   //create mocks
   Mock<ICustomerManager> custManager = 
      mockFactory.Create<ICustomerManager>();
 
   Mock<IProductService> prodService = 
      mockFactory.Create<IProductService>();
 
   Customer cust = new Customer(123);
   cust.IsMember = false;
 
   //setup mocks
   custManager.Setup(cm => cm.GetCustomer(123)).Returns(cust);
   prodService.Setup(ps => ps.IsInStock()).Returns(false);
 
   //run test
   CustomerService svc = new CustomerService(customerId, custManager.Object); 
   Assert.IsFalse(svc.CanPurchaseProduct(1, prodService.Object));
}
 
[TestCase]
public CanPurchaseProduct_NotAMember()
{
   int customerId = 123;
   int prodId = 1;
 
   //create mocks
   Mock<ICustomerManager> custManager = 
      mockFactory.Create<ICustomerManager>();
 
   Mock<IProductService> prodService = 
      mockFactory.Create<IProductService>();
 
   Customer cust = new Customer(123);
   cust.IsMember = false;
 
   //setup mocks
   custManager.Setup(cm => cm.GetCustomer(123)).Returns(cust);
 
   prodService.Setup(ps => ps.IsInStock()).Returns(true);
   prodService.Setup(ps => ps.IsMembersOnly()).Returns(true);
 
   //run test
   CustomerService svc = new CustomerService(customerId, custManager.Object); 
   Assert.IsFalse(svc.CanPurchaseProduct(1, prodService.Object));
}

And there you have it. We were able to take an existing code base that had no support for unit-testing and re-factor it so that the additional methods that we added could be unit-tested. Furthermore, we did this without requiring us to make any sweeping architectural changes to the existing code base.

One could argue if the additional work is really worthwhile. If you’re already a test-driven developer then I don’t need convince you that it is definitely worthwhile. But if you’re not then I’ll highlight a few long-term benefits that result from the additional work:

- The code base is now more extensible. It can work with other implementations for ICustomerManager and IProductService.
- At any given time one can run the test cases and know if anything has been broken.
- Unit-testing forces us to think about the dependencies and code in a manner that leads to clean and easy-to-understand code.
- The test cases serve as an up-to-date documentation on what the code does and how it is being used.

I hope that the above points will encourage you to investigate the pros/cons of test driven development more fully.

CodeProject

Error: Cannot add the transport element 'httpTransport'. Another transport eleme
nt already exists in the binding 'System.ServiceModel.Configuration.HttpTranspor
tElement, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=
b77a5c561934e089'. There can only be one transport element for each binding.

Upon investigation, I realized that when deploying a WCF web service over HTTPS, you must set the ‘Security’ mode to ‘Transport.’. Below are the steps to do this:

1. Add the following inside the section:

<bindings>
  <wsHttpBinding>
     <binding name="webBinding">
       <security mode="Transport"></security>
     </binding>
  </wsHttpBinding>
</bindings>

2. Add the following attribute to the element:

bindingConfiguration="webBinding"

That should be all.

Below is a sample section:

<system.serviceModel>
  <services>
    <service name="MyWebService"
        behaviorConfiguration="ServiceBehavior">
	<!-- Service Endpoints -->
	<endpoint address="" binding="wsHttpBinding"
           bindingConfiguration="webBinding" contract="IMyWebService">
	</endpoint>
       <endpoint address="mex" binding="mexHttpBinding" 
         contract="IMetadataExchange" />
   </service>
</services>
<bindings>
  <wsHttpBinding>
     <binding name="webBinding">
       <security mode="Transport" />
     </binding>
  </wsHttpBinding>
</bindings>
<behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
      <serviceMetadata httpGetEnabled="true"/>
    </behavior>
  </serviceBehaviors>
</behaviors>
</system.serviceModel>

Below is an approach that’s worked quite well for me:

Tells me where I left off