1

I have a Service created with ServiceStack. I am using Funq for my Dependency Injection as it comes with ServiceStack by default, but this may be behaviour exhibited by other DI containers.

I register my types on startup: 

this.AppContainer.RegisterAs<ConcreteDownloadServices, IDownloadServices>();`

I have this constructor in a class:

private readonly IDownloadServices downloadServices;

public ExampleService(IDownloadServices downloadServices)
{
    this.downloadServices = downloadServices;
}

And the constructor of my concrete implementation is:

public ConcreteDownloadServices()
{
    this.ArbitraryProperty = "ArbitraryString";
}

Everything resolves fine and I can step into the code and see things working as expected. However, AbritraryProperty does not get set properly. I can step through and see it set to the string value, but as soon as the code returns to the calling code (in this example, it would be the constructor of ExampleService) ArbitraryProperty is now null.

  1. Is this behaviour by design?
  2. If it is by design, does using DI mean that I shouldn't be doing anything in the constructors of my concrete implementations?
  3. If it is by design, what's the correct way to set default values for auto properties?
  4. If it is not by design, then what's going on?
thudbutt
  • 1,481
  • 1
  • 19
  • 32

2 Answers2

4

Edit:

I've decided this is never desired behavior so I've just checked in a commit to enforce that Funq doesn't autowire string (and ValueType) properties. The new behavior will be available in the next version of ServiceStack (v3.9.34).

Existing behavior

RegisterAs is an Autowired API, i.e:

Container.RegisterAs<ConcreteDownloadServices, IDownloadServices>();

This tells ServiceStack's IOC to populate every public property with dependencies resolved by the IOC. Which because it is a string public property will try to resolve the registered string from the IOC. In code terms, this is happening under the hood:

new ConcreteDownloadServices { 
    ArbitraryProperty = Container.TryResolve<string>()
};

Which because you don't have any "string" registered will override the property with null. Only public properties are auto-wired so you can avoid this behavior by changing it to an protected, private or internal property.

Otherwise you can override the default IOC behavior by registering a custom delegate factory which gives you full control over the construction of your dependency, e.g:

container.Register<IDownloadServices>(c => new ConcreteDownloadServices());
mythz
  • 141,670
  • 29
  • 246
  • 390
  • Amazing info, thanks for that mythz :) Changing the property modifier is out as it implements an interface so has to be a public property. Using Register with the delegate factory looks like the answer. However, does this indicate that I shouldn't be using value type properties if I want to use RegisterAs or another Autowired API? For my particular scenario it makes sense to me to have something in the Interface to force the implementation of this string but I can only do that with a public property (I think!). – thudbutt Jan 25 '13 at 16:46
  • Meant to add - I guess I would need to create an Interface and concrete implementation which contains my dependant string and inject it to use RegisterAs? – thudbutt Jan 25 '13 at 16:59
  • @thudbutt decided this isn't ideal behavior, so Funq will no longer try to resolve string properties in the next version of ServiceStack that I'll publish to NuGet on the weekend. – mythz Jan 25 '13 at 17:21
1

Some members of our devteam just spent some time debugging a similar issue.

A RegisterAs class used in one of our unittests has a public member: public List Mails { get; set; }

When this class is resolved through Funq, the member is set to null, even though it is was set in the constructor.

Our teammembers agree that it is wierd that this member is set to null by Funq, when the member isnt of a type that is registered as a Container.RegisterAs<>.

We are using ServiceStack version 4.0.33

Markus Foss
  • 335
  • 4
  • 14