Changing the WCF Test Client configuration

Today I was testing a service method that returns bigger amount of data with the with wcftestclient. Unfortunately the test client uses a lot of default settings in the generated client configuration, so the message size quota is limited to 65536 bytes. This means that you get the following exception:

The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

Can this be changed easily? The answer is yes!

Having the latest .NET 3.5 SP1 and VS 2008 on my box the test client not only shows the service hierarchy (in the tree on the left hand side) but there is also a “Config File” node for each service. With double-click you can open the client configuration file in a tab in read-only mode (and you can see the default settings causing the problem).

If you right-click the node you get further options. You can copy the full path of the config file if you want to open it with a text editor, or you can choose to edit it with the SvcConfigEditor tool.

Either way, you can just go and change the client configuration according to your needs. The tool watches the configuration file for changes. As soon as you save your changes it offers you the possibility to reload the configuration in a pop window.

There is one more issue that you should be aware of. If you close the tool and run it later again you can easily reopen the recently used services from the menu (File/Recent Services) BUT your configuration changes will be not preserved. If you want your changes to be kept go to the Tools/Options… menu and uncheck the option “Always regenerate config when launching services”.

If you want to revert back to the default configuration again, you can right-click the “Config File” node and select the “Restore to Default Config” command from the context menu.

Query performance in SQL Server Management Studio

I think a lot of developers know the following scenario:

• You have a query that is "slow", e.g. causes timeouts in your application.
• You copy the query into SSMS and execute it. You just want to "see it" yourself dying before you touch it. But it runs within a second on the same server...
• You try it a bit later and you are "lucky" this time, it is very slow in SSMS as well. Maybe it is time to tune the query and see how the response time is changing?
  
• But first you press that F5 again just to make sure that you saw it correctly. And you are out of luck, query returns immediately...

Of course this must be caused by the caching mechanism (plan, data) of the SQL server, which is a good thing in general. However, it is still a bit annoying if you are about to tune the query and you can never know if you can trust the execution time that you see.

The two “magic commands” that can help:

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

If you run these commands before executing the query you will be able to reproduce the slow response time in a more reliable way.

Just don't forget that while this is a good thing for you in that moment it might cause a serious performance hit for all the others at the same time. Definitely don't do this on a production server! And make sure that you know what you are doing: please read the documentation of the commands and decide wisely whether you may do this in your concrete environment.