When to use constants, settings.settings and Resources.resx

When developing in Visual Studio (2005 upwards I think), you have several options when it comes to referencing strings in your code (and other types, but I’ll restrict to strings for the sake of conciseness). I think it is safe to say that usually you do not want to hard-code the string directly in the code, but should you create a constant ‘at the top’ of the class? or should you create a class for constants to use throughout the project/solution? or should you use the project settings (settings.settings)? or should you reference it as a resource? Whew, that’s a lot of options!

As I see it my guidelines would be:

• If the string will never need to be changed and is only relevant to the class in question just reference it as a constant within the class. This will keep it proximal to the code using it, whilst concentrating all the class constants in one place.
• If the string will never need to be changed and is relevant to multiple classes define it in a single class at a scope that makes sense (project/solution wide)
• If the string needs to be changeable by the end user at configuration time then settings.settings should be used.
• If the string needs to be changed based on the locale the application is running in (e.g. It contains text displayed to the user) then it should be put in the resources.resx file.
• If the string sensibly fits within a grouping of configurable items that could be applied to the application (e.g. you want to be able to ’skin’ your application so that multiple configurations can be chosen) then it should be put in a resources.resx file.

I think the question of settings vs Resources can be a little tricky, as far as I am aware the differences are:

• Resources.resx file are only modifiable pre-build, the end-user will not be able to change the contents; Settings.settings files are rolled up into the application’s configuration and are therefore customizable by the end user.
• Settings.settings files are not localization aware, they should not be used to make your app localizable. Resources should be used for this.

Strictly mocked operations rather than strictly mocked interfaces?

Recently I’ve been planning to contribute to the rhino mocks wiki. One of the topics I thought I would write about is when I would use the different types of mock (CreateMock, DynamicMock, Stub etc). To this end I was trying to think why you would want to use CreateMock; that is a mock that enforces strict replay semantics.

When would you want strict replay?

- When you don’t want your target (System Under Test) to make calls other than those that you have expressly defined. Usually I don’t think you care, but sometimes these calls will be ‘expensive’, in the sense that they do something like make a web service call, and so we don’t want to make the call un-necessarily. Or that they cause a change of state, that is where making the call would result in incorrect behaviour of the system (e.g. A method that called CreditCardService.TakePayment() twice instead of once would probably be a ‘bad thing’). In these examples what I am really bothered about is that certain mocked operations obey strict replay semantics, rather than the whole interface.

How to use strictly mocked operations in Rhino Mocks

So if we want a mocked operation that obeys strict replay semantics we can simply use a DynamicMock and set individual operations to be restricted using Repeat.Never() or Repeat.Times(), I would also argue that this will result in much more expressive tests as you are expressly saying what operations should not be called rather than hiding this in the type of mock created.

I am not saying that a strictly mocked interface is completely un-necessary, sometimes you know that an interface is full of methods we don’t want to call (such as a web service client), and we don’t want to have to enumerate every method. Rather you should probably think about what you want to restrict calls to.

Suggested rule of thumb:

• If the interface is to an ‘expensive’ class to call use a strictly mocked interface.
• If the interface contains methods which result in a change of state then certain methods should be strictly mocked.

Username message credentials over streamed binding

A little while ago I added username authentication to some WCF services we have. This used message level authentication to hold the username and password, which required an x509 certificate to be used to secure the transport (as we’re sending passwords over it). One flaw was that message level security does not work with streamed bindings (as the message security, which comes before the message hits the service,  depends on the message body, so if it’s streamed you can’t establish security until the stream has finished). So a couple of our services require streamed bindings as they involve sending massive attachments to the WCF service (forget for the moment the dubiousness of sending massive attachments to a WCF service). This caveat was decided to be acceptable as all the other services were secured.

More recently it has become apparent that these streamed binding services also require security… oh dear! So it actually turns out it’s not that difficult, but oddly enough I couldn’t really find any directly related material on the interweb detailing this solution, so here it is.

For any streamed binding that needs to be secured using username message credentials set the security mode to mixed mode (TransportWithMessageCredential), the transport security to certificate and the message credential to username:

binding.Security.Mode = SecurityMode.TransportWithMessageCredential;
binding.Security.Transport.ClientCredentialType = TcpClientCredentialType.Certificate;                binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;

This is a slightly different configuration than username based message security, and the caveat about streamed bindings does not apply. I think the difference is that instead of all security being taken care of at the message level only the credential passing is at the message level, other aspects of security are taken care of at the transport level. Therefore you no longer need the whole message body to establish security as this is taken care of at the transport layer. The disadvantage of using this security mode is that the transport is now essential for establishing security, so over multiple-hop connections the security wont work (I’m guessing). Therefore for non-streamed connections we’re going to stick to message security, degrading to mixed-mode security for streamed bindings.

Why does WCF security have to be so complicated? and how come I keep on getting lumbered with it?