WCF4 error message: server did not provide a meaningful reply

When setting up a WCF service with .Net4 using WCF I encountered the following error when passing large object graphs:
“The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.”

Obviously this error was due to the very minimal default quotas defined by WCF – I thought  I just had to increase the values in the config file to solve my problem. So I immediately went to the app.config file but I was rather surprised discovering that the configuration file was empty.

When inspecting the new features of WCF4 I discovered that Microsoft has put efforts to make the overall WCF experience just as easy as ASMX (this is at least what they claim) . Therefore WCF4 comes with a new “default configuration” model. In my opinion this default configuration scheme only obfuscates the inherent complexity of WCF4 and result is just more confusion.

Of course now your config file is empty but this does not simplify its use because the standard binding & behaviors quota’s are still targeted to minimal values. As soon as you try to do some real work with WCF you will get the error message described here above. This is error message mostly mean that you’ve to increase some of the default configuration values.

Here is an article describing the new configuration model of WCF4: http://msdn.microsoft.com/en-us/library/ee354381.aspx

This is the configuration (using very permissive values) I use when developing WCF3 (to be adapted when you go in production)

Client:

  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="BasicHttpBinding_IGroupService" closeTimeout="00:01:00"
            openTimeout="00:01:00" receiveTimeout="00:30:00" sendTimeout="00:01:00"
            allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
            maxBufferSize="655360000"
                 maxReceivedMessageSize="655360000"
            maxBufferPoolSize="524288"
            messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
            useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
              maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None"
                realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
    <behaviors>
      <endpointBehaviors>
        <behavior name="largeObjectGraphBehavior">
          <dataContractSerializer maxItemsInObjectGraph="214748364" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <client>
      <endpoint address="http://localhost:1763/GroupService.svc" binding="basicHttpBinding"
          bindingConfiguration="BasicHttpBinding_IGroupService" contract="GroupService.IGroupService"
          name="BasicHttpBinding_IGroupService" behaviorConfiguration="largeObjectGraphBehavior" />
    </client>
  </system.serviceModel>

Server:

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding maxBufferSize="655360000" maxReceivedMessageSize="655360000" >
          <readerQuotas maxArrayLength="1000000" />
        </binding>
      </basicHttpBinding>
<!-- notice there’s no name attribute -->
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
          <serviceMetadata httpGetEnabled="true" />
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="true" />
          <dataContractSerializer
                 maxItemsInObjectGraph="1000000" />

        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
  </system.serviceModel>

Why should we test?

I plan to write some articles regarding how to write good unit tests but before providing what my guidelines are regarding unit testing it’s important to first understand what are the reasons why we want to unit test and what are the drivers for depicting these guidelines. Because my objective is to encourage developers to practice unit testing, I choose to address the main oppositions I encounter today on the field.

 

Unit testing is not productive!

If we take a closer look to how productivity is optimized in classical manufacturing process, we can envision why well written, well maintained unit tests have exactly the opposite effect.

The productivity of a factory is measured by the speed at which products flaws from the production line and the effectiveness of the production line. As one may think, the speed at which products flaws out of the factory is not the average speed of each part of the production line but it depend mostly on of the number of things to process in the production line. So if you want to increase the overall production capacity of a factory you’ve to synchronize every part of the production line and make sure that each part works at a constant peace and that every part is working at a sustainable piece for him and his neighbor. The worsted thing that can happen in a production line is that a defect is caused in a part of the line and is paced at the next part. The defect will not only cause the part of the line where the defect is detected to stop but the defect part has also to be resent to the part of the line where the defect was made. This will desynchronize the overall production line and diminish the overall productivity of the factory. When we produce software the same is true, if a bug is detected by the testing team or worse in production it will generate a lot of waste. The bug will need to be described precisely; the developers will need to switch from their ongoing task to the bug resolution. A lot of time will be loosed in understanding the problem. The bug resolution will need to be tested. Finally a patch will need to be deployed in production potentially causing a service interruption. There is also a consequent risk to repeat this process the defect was not corrected adequately or because a new defect is caused by the resolution. An important side effect for unit test is also that they reduce the risk of a project. Each unit test is an insurance that the system works. Having a bug in the code means carrying a risk. Utilizing a set of unit tests, engineers can dramatically reduce number of bugs and the risk with untested code.

Unit tests will also decrease the maintenance cost because they provide a living documentation. This is called "Test as documentation". Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit and how to use it can look at the unit tests to gain a basic understanding of the unit.  Unit tests embody characteristics that are critical to the success of the unit. These characteristics can indicate appropriate/inappropriate use of a unit as well as negative behaviors that are to be trapped by the unit. A unit test case documents these critical characteristics.

So it’s true that unit tests are generally doubling the initial cost of the implementation phase because it tends to cost the same amount of time as writing production code. But this cost is more than re-gain because the other steps of the production process shorten. The amount of defects detected by the Q&A team is drastically falling and a lot of time is won because the Q&A team can work faster. Even the overall throughout put of the development teams increases at the end because a time is not loosed anymore in correcting a lot of defects detected by the Q&A team. The project manager is far better at estimated the project status. At the end the trust of the business increases because they get features build on a constant pace and because the overall delivered quality increases.

 

Unit testing does not catch all bugs!

Unit testing and other forms of automated testing serve the same purpose as the automated testing devices in manufacturing. Unit tests will enable to detect rapidly a defect when code is changed or added. The automated tests are not made to detect malfunctions in production but to prevent that defects could enter into our assembly line.  The real value of Unit testing & TDD is not that they can detect defects but that they overcome defects to happen!  Unit testing will not only improve the quality perceived by the business because lesser defects will slip through it will also improve the internal quality attributes of the code itself because the developer will tend to refactor a lot more and will design his code more loosely coupled. (see Design for testability). 

Nevertheless Unit testing alone is not sufficient, testing should happen on all levels but unit tests decrease the amount of other kind of testing that is needed. Because unit testing helps to eliminate uncertainty in the units themselves they enable a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.

 

Testing is for the testers!

Unit testing and other forms of automated testing serve the same purpose as the automated testing devices in manufacturing. Unit tests will enable to detect rapidly a defect when code is changed or added. The automated tests are not made to detect malfunctions in production but to prevent that defects could enter into our assembly line. The real value of Unit testing & TDD is not that they can detect defects but that they overcome defects to happen! Unit testing will not only improve the quality perceived by the business because lesser defects will slip through it will also improve the internal quality attributes of the code itself because the developer will tend to refactor a lot more and will design his code more loosely coupled.

When software is developed using a test-driven approach, the Unit-Test may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior. By writing your tests you are performing an act of design and all professional developers should aim for good design.

 

Unit testing is a waste of time because they tend to break and we constantly have to fix them!

Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly. The unit tests enables refactoring because they provide a safety net that allows us to practice refactoring. The procedure is to write test cases for all methods so that whenever a change causes a fault, it can be quickly identified and fixed. Readily-available unit tests make it easy for the programmer to check whether a piece of code is still working properly. They enable us to constantly improve our SUT by adhering to the DRY principles. This principle does not only apply to our SUT but also to our test code. By constantly keeping our testsDRY by eliminating duplication we improve the maintainability of our tests and make sure that these tests stay efficient. When you spent too much time in fixing tests you should consider to review your test design. Have a look at the following articles these will provide some guidelines that will help you in increasing the maintainability of your tests.

 

This code is too difficult to test! 

Because unit tests forces us to exercise our code in another context as the context in which the code will run in production – the tests forces us to design our code so that it is more loosely coupled. Loose coupling tend to improve reusability and robustness. Reusability and robustness are certainly desirable goals. So Unit testing is a way to assert that our code is robust and reusable – if your code is hard to test this is mostly because there is something wrong with your design and you should not try to test bad design but you should fix it!

 

kick it on DotNetKicks.com

 

 

 

 

How to distinguish an integration test from a unit test?

 

 

Although unit & integration tests serve different purposes, we’ve a tendency to confuse both types of testing. In fact most of the tests we write tend to be integration tests.  In my opinion the main reason why we confuse both is because we use the same test automation framework (e.g. NUnit) to write unit tests and integration tests. Nevertheless we should always separate our unit tests from our integration tests because Integration tests tend to be more fragile, slower and require more maintenance as unit tests.

As described in Wikipedia integration tests, test the integration between modules. Unit Tests targets atomic (indivisible) units/modules.  In my opion the notion of module is not enough to separate Unit from integration tests because a module is a subjective concept, it can be a applied for many things; a class, a Layer, a Component...  Therefore I prefer to make the distinction based on the fact that the test is dependent or not on some infrastructure.  When our tests are dependent on some infrastructure we can’t pretend anymore that our test is exercising a single module.  So as soon as our test is dependent on some sort of infrastructure like a DB, file, Web Service, COM component… it’s depend on at least two units (our code & the infrastructure) and it should be qualified as an Integration test.    

 

 

Keyboard support for Menu control Sylverlight 4

 

Today I tried to validate an  Architecture by creating a POC.  The architecture is an N-Tier using Silverlight for the client.  The customer as one particular request that, I thought, was reasonable: all actions – including menu navigation – has to be available through keyboard.  

When I tried Silverlight 4 I was surprised not to find any menu control so I downloaded several open source and commercial menu controls.  I was very disappointed, after having searched for a couple of hours I didn’t manage to find any control providing a decent keyboard support.  Most controls provides some basic support but not one control enabled to gain focus on the first item through the keyboard.  You are able to use the keyboard (arrow keys) but you need first to select the control with the mouse!  Not one control provided support for Keyboard shortcut. 

This is my shortlist of open source Sylverlight controls:

Codeproject free Menu : http://www.jebishop.com/2009/11/18/implementing-a-contextmenu-in-silverlight-4-beta/

Codeplex free Menu : http://www.codeproject.com/KB/silverlight/SL2DropDownMenu.aspx

 

Cannot start Microsoft Office outlook. Cannot open the outlook window

It’s now the third time I experience the same problem, for a strange reason outlook refuse to start anymore and I get the following error message: “"Cannot start Microsoft Office outlook. Cannot open the outlook window". Because I don’t want to google for it anymore I decided to put the resolution on my blog so that I can find it later.  

The solution is simple run:  Outlook.exe /resetnavpane