unity Work Item Rss Feed

Commented Unassigned: NuGet: Could not install package 'Unity 3.0.1304.0'. [12731]

ben555 — Wed, 22 May 2013 10:38:11 GMT

Commented Unassigned: NuGet: Could not install package 'Unity 3.0.1304.0'. [12731]

randylevy — Thu, 16 May 2013 15:27:03 GMT

"Could not install package 'Unity 3.0.1304.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author."

What am I doing wrong? The help file says it supports .Net 4 & VS2010?
Comments: Unity 3 requires .NET 4.5. From the [Release Notes](https://unity.codeplex.com/wikipage?title=Unity3ReleaseNotes): > Supported .NET Frameworks: Microsoft .NET Framework 4.5, .NET for Windows Store Apps (previously known as WinRT). Where did you see the requirement for .NET 4 (so we can fix it up)? ~~ Randy Levy [entlib.support@live.com](mailto:entlib.support@live.com) Enterprise Library support engineer [Support How-to](entlib.codeplex.com/wikipage?title=Support%20How-to)

Created Unassigned: NuGet: Could not install package 'Unity 3.0.1304.0'. [12731]

ben555 — Thu, 16 May 2013 13:43:48 GMT

Edited Unassigned: bug (3.0.1304.0): using InjectionMethodAttribute on virtual method in base and child (when overriden) types results in calling 2+ times when resolving child type [12729]

ylemsoul — Mon, 29 Apr 2013 20:15:35 GMT

Breaking change behavior when using InjectionMethodAttribute:
```
public class Thing
{
[InjectionMethod]
public virtual void InitComponent()
{
}
}

public class Concrete : Thing
{
private static int InvocationCount;

public Concrete()
{
Console.WriteLine(".ctor called");
}

[InjectionMethod]
public override void InitComponent()
{
// Debug.Assert(++InvocationCount == 1); // assertion failed
Console.WriteLine("init called");
}
}

public class Program
{
private static void Main()
{
using (var c = new UnityContainer())
{
c.Resolve<Concrete>();

Console.ReadLine();
}
}
}```

Output in version 3:
.ctor called
init called
init called

Output in version 2:
.ctor called
init called

In version 2 if you comment [InjectionMethod] on child method then InitComponent() never been called (strange too, but can be "workarounded" with attribute), and in version 3 it called once.
In version 2 If you remove override then InitComponent() will be called like expected :-/

So that's why it called two times in v3 when both attributes presented. But IMO it is a bug and method should be called once regardless of this (attribute even has AllowMultiple=false)

Created Unassigned: Missing CommonServiceLocator dependency in Nuget package [12730]

mgrosperrin — Mon, 29 Apr 2013 11:19:32 GMT

Hi guys,

in the package for the v3.0.1304.0, you have removed the dependency to the package CommonServiceLocator which contains the Microsoft.Practices.ServiceLocation classes.
As the Unity assembly depends on it (via the Microsoft.Practices.Unity.UnityServiceLocator class), you should re-add the dependency.
Thanks

Edited Unassigned: bug (3.0.1304.0): using InjectionMethodAttribute on virtual method in base and child (when overriden) types results in calling 2+ times on resolving child type [12729]

ylemsoul — Mon, 29 Apr 2013 09:09:48 GMT

Created Unassigned: bug (3.0.1304.0): using InjectionMethodAttribute on virtual method in base and child (when overriden) types results in calling 2+ times on resolving child type [12729]

ylemsoul — Mon, 29 Apr 2013 09:03:32 GMT

Breaking change behavior when using InjectionMethodAttribute:
```
public class Thing
{
[InjectionMethod]
public virtual void InitComponent()
{
}
}

public class Concrete : Thing
{
private static int InvocationCount;

public Concrete()
{
Console.WriteLine(".ctor called");
}

[InjectionMethod]
public override void InitComponent()
{
// Debug.Assert(++InvocationCount == 1); // assertion failed
Console.WriteLine("init called");
}
}

public class Program
{
private static void Main()
{
using (var c = new UnityContainer())
{
c.Resolve<Concrete>();

Console.ReadLine();
}
}
}```

Output in version 3:
.ctor called
init called
init called

Output in version 2:
.ctor called
init called

In version 2 if you comment [InjectionMethod] on child method then InitComponent() never been called (strange too, but can be "workarounded" with attribute), and in version 3 it called once.
In version 2 If you remove override than InitComponent() will be called like expected :-/

So that's why it called two times in v3 when both attributes presented. But IMO it is a bug and method should be called once regardless of this (attribute even has AllowMultiple=false)

Created Unassigned: UnityDependencyResolver should use child containers [12728]

Citezein — Fri, 26 Apr 2013 17:55:26 GMT

Looking at the new UnityDependencyResolver in Unity 3, I am disappointed to see that it doesn't use child containers per request. This is really considered best-practice at this point and I would like to see it implemented in the default package.

Commented Issue: Array dependency and PerResolveLifetimeManager [8777]

malevy — Mon, 15 Apr 2013 19:29:09 GMT

Because of the logic inside ArrayResolutionStrategy, default array resolution strategy is not compatible with PerResolveLifetimeManager, because it fires container.ResolveAll which resolves instances in new builder contexts.
private static object ResolveArray<T>(IBuilderContext context)
{
 List<T> results = new List<T>(context.NewBuildUp<IUnityContainer>().ResolveAll<T>(new ResolverOverride[0]));
 return results.ToArray();
}
 
One way to fix this is to resolve UnityContainer, take it's Registrations and resolve array items in old context via NewBuildUp.

Comments: This problem still exists in 2.1.505.2. I just spent an hour tracking it down.

Commented Issue: circular dependencies may cause stack overflow [11131]

stesieber — Tue, 09 Apr 2013 15:31:56 GMT

The code sample below, when run, will fail due to a stack overflow. It is caused by Unity's handling of ConsoleLogger, an ILogger, which depends upon another ILogger (the decorator pattern). If you comment out the "RegisterType" line and uncomment the "RegisterInstance" line, it will work. Sometimes these circular dependencies can be hard to find if someone else put them in code some time ago. 
 
Can you make the resolution mechanism detect circular references and throw an informative error message, instead of having us infer the circular reference by a stack overflow?
 
using System;
using Microsoft.Practices.Unity;
using Microsoft.VisualStudio.TestTools.UnitTesting;
 
namespace TestContractPerformance
{
 [TestClass]
 public class UnityRecursionTest
 {
 [TestMethod]
 public void TestMethod1()
 {
 IUnityContainer container = new UnityContainer();
 container.RegisterType<ILogger,ConsoleLogger>();//this will cause a stack overflow due to recursive resolution
 //container.RegisterInstance<ILogger>(new ConsoleLogger());//this works
 Foo foo = container.Resolve<Foo>();
 foo.Go();
 
 }
 }
 
 public class ConsoleLogger : ILogger
 {
 private readonly ILogger _otherLogger;
 
 public ConsoleLogger(ILogger otherLogger)
 {
 _otherLogger = otherLogger;
 }
 
 public ConsoleLogger(){}
 
 public void Log(string message)
 {
 Console.WriteLine(message);
 if (_otherLogger != null)
 {
 _otherLogger.Log(message);
 }
 }
 }
 
 public class Foo 
 {
 private readonly ILogger _logger;
 
 public Foo(ILogger logger)
 {
 _logger = logger;
 }
 
 public void Go()
 {
 _logger.Log("Go");
 }
 }
 
 public interface ILogger
 {
 void Log(string message);
 }
}

Comments: I think this is a rather grave problem in Unity since a StackOverflowException in .Net leads to the termination of the process. IIS just died on me a few days ago and I was not able to find the cause (guess what: no stacktrace). Given that it is possible to detect circular dependencies, why isn't it done?

Commented Issue: Add Portable Class Library support [12706]

dot_NET_Junkie — Fri, 05 Apr 2013 16:58:24 GMT

Users should be able to use Unity everywhere (.NET, Windows Phone, WinRT)
Comments: Since Unity should only be referenced in the Composition Root (the startup path of your application) creating a PCL would be rather useless. The Composition Root is always application specific, and you wouldn't share that code over a Silverlight, Windows Phone and WCF application.

Commented Issue: Add Portable Class Library support [12706]

amaq — Fri, 05 Apr 2013 14:35:11 GMT

Users should be able to use Unity everywhere (.NET, Windows Phone, WinRT)
Comments: PCL is more and more important !

Commented Issue: Unity not respecting HierarchicalLifetimeManager when manually registering IServiceLocator [12727]

rob_levine — Tue, 19 Mar 2013 08:44:44 GMT

I'm seeing some unexpected behaviour in Unity when registering and resolving IServiceLocator using the HierarchicalLifetimeManager.

What I'm seeing suggests that Unity treats the UnityServiceLocator as a static singleton, even when it is configured otherwise. This behaviour seems to be particular to UnityServiceLocator.

Background: I am slowly phasing out the "static" ServiceLocator in a few places in our code where it exists. The first step was going to be to register IServiceLocator in Unity and then have it injected as a dependency into those classes that use it.

In the following code, I register an injection factory to create a new instance of UnityServiceLocator. I also scope it with HierarchicalLifetimeManager to give me one instance per child container:

```
private static void Main(string[] args)
{
var container = new UnityContainer();
container.RegisterType<IServiceLocator>(
new HierarchicalLifetimeManager(),
new InjectionFactory(
c =>
{
Console.WriteLine("InjectionFactory invoked with container: " + c.GetHashCode());
return new UnityServiceLocator(c);
}));

container.Resolve<IServiceLocator>(); // expect to see console output here
container.Resolve<IServiceLocator>(); // don't expect to see console output here

var child = container.CreateChildContainer();
child.Resolve<IServiceLocator>(); // expect to see console output here
container.Resolve<IServiceLocator>(); // don't expect to see console output here

var anotherChildContainer = container.CreateChildContainer();
anotherChildContainer.Resolve<IServiceLocator>(); // expect to see console output here
anotherChildContainer.Resolve<IServiceLocator>(); // don't expect to see console output here
}
```
I would expect the above code to invoke the factory, create the UnityServiceLocator instance and write out console output three times, once for each container. It doesn't - it does it once, as if I'd registered it as a singleton:

InjectionFactory invoked with container: 20903718

It gets worse:

If I now make my own class implement IServiceLocator (literally, implement the interface, one ctor which takes IUnityContainer, and have all methods throw NotImplementedException), and swap the line

return new UnityServiceLocator(c);
with

return new MyUnityServiceLocator(c);
This starts behaving the way I'd expect:

InjectionFactory invoked with container: 20903718
InjectionFactory invoked with container: 51746094
InjectionFactory invoked with container: 41215084

I just cannot understand this behaviour unless Unity treats UnityServiceLocator as a special case.

This feels like a bug to me, or possibly some undocumented special behaviour.

Can someone confirm if this is a bug or by design?
Comments: Thanks Randy, this explains everything. I've gone down the route of implementing IServiceLocator myself, although I think your suggestion to override the registration should work too.

Commented Issue: Unity not respecting HierarchicalLifetimeManager when manually registering IServiceLocator [12727]

randylevy — Sat, 16 Mar 2013 06:35:33 GMT

I'm seeing some unexpected behaviour in Unity when registering and resolving IServiceLocator using the HierarchicalLifetimeManager.

What I'm seeing suggests that Unity treats the UnityServiceLocator as a static singleton, even when it is configured otherwise. This behaviour seems to be particular to UnityServiceLocator.

Background: I am slowly phasing out the "static" ServiceLocator in a few places in our code where it exists. The first step was going to be to register IServiceLocator in Unity and then have it injected as a dependency into those classes that use it.

In the following code, I register an injection factory to create a new instance of UnityServiceLocator. I also scope it with HierarchicalLifetimeManager to give me one instance per child container:

```
private static void Main(string[] args)
{
var container = new UnityContainer();
container.RegisterType<IServiceLocator>(
new HierarchicalLifetimeManager(),
new InjectionFactory(
c =>
{
Console.WriteLine("InjectionFactory invoked with container: " + c.GetHashCode());
return new UnityServiceLocator(c);
}));

container.Resolve<IServiceLocator>(); // expect to see console output here
container.Resolve<IServiceLocator>(); // don't expect to see console output here

var child = container.CreateChildContainer();
child.Resolve<IServiceLocator>(); // expect to see console output here
container.Resolve<IServiceLocator>(); // don't expect to see console output here

var anotherChildContainer = container.CreateChildContainer();
anotherChildContainer.Resolve<IServiceLocator>(); // expect to see console output here
anotherChildContainer.Resolve<IServiceLocator>(); // don't expect to see console output here
}
```
I would expect the above code to invoke the factory, create the UnityServiceLocator instance and write out console output three times, once for each container. It doesn't - it does it once, as if I'd registered it as a singleton:

InjectionFactory invoked with container: 20903718

It gets worse:

If I now make my own class implement IServiceLocator (literally, implement the interface, one ctor which takes IUnityContainer, and have all methods throw NotImplementedException), and swap the line

return new UnityServiceLocator(c);
with

return new MyUnityServiceLocator(c);
This starts behaving the way I'd expect:

InjectionFactory invoked with container: 20903718
InjectionFactory invoked with container: 51746094
InjectionFactory invoked with container: 41215084

I just cannot understand this behaviour unless Unity treats UnityServiceLocator as a special case.

This feels like a bug to me, or possibly some undocumented special behaviour.

Can someone confirm if this is a bug or by design?
Comments: The reason why you are seeing the above behavior is that UnityServiceLocator registers itself in the container with an ExternallyControlledLifetimeManager lifetime: ``` public UnityServiceLocator(IUnityContainer container) { this.container = container; container.RegisterInstance<IServiceLocator>(this, new ExternallyControlledLifetimeManager()); } ``` I would say that this is done by design. As you say if you need a different behavior, then you could create your own locator or potentially override the original lifetime manager registration with another. ``` new InjectionFactory( c => { Console.WriteLine("InjectionFactory invoked with container: " + c.GetHashCode()); var locator = new UnityServiceLocator(c); c.RegisterInstance<IServiceLocator>(locator, new HierarchicalLifetimeManager()); return locator; }) ``` ~~ Randy Levy [entlib.support@live.com](mailto:entlib.support@live.com) Enterprise Library support engineer [Support How-to](entlib.codeplex.com/wikipage?title=Support%20How-to)

Created Issue: Unity not respecting HierarchicalLifetimeManager when manually registering IServiceLocator [12727]

rob_levine — Fri, 15 Mar 2013 12:23:49 GMT

Commented Issue: Unity does not respect lifetime manager for call handler [12726]

randylevy — Tue, 26 Feb 2013 14:00:05 GMT

Commented Issue: Unity does not respect lifetime manager for call handler [12726]

JochenZ — Tue, 26 Feb 2013 08:32:13 GMT

Commented Issue: Unity does not respect lifetime manager for call handler [12726]

JochenZ — Mon, 25 Feb 2013 21:33:13 GMT

Commented Issue: Unity does not respect lifetime manager for call handler [12726]

randylevy — Mon, 25 Feb 2013 18:12:55 GMT

Even if a call handler (interception) is registered as a singleton, multiple instances are generated. This unit test demonstrates the behavior:

```
using System.Diagnostics;
using System.Threading;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.InterceptionExtension;
using Xunit;
using Xunit.Extensions;

namespace UnityTests
{
public class CallHandlerLifetime
{
[Theory]
[InlineData(true)]
[InlineData(false)]
public void UnityRespectsLifetimeManagerForCallhandler(bool useSingleton)
{
TestHandler.ResetInstanceCount();

using (IUnityContainer container = new UnityContainer())
{
if (useSingleton)
container.RegisterType<TestHandler>(new ContainerControlledLifetimeManager());

container.AddNewExtension<Interception>()
.Configure<Interception>()
.AddPolicy("test")
.AddMatchingRule(new NamespaceMatchingRule(GetType().Namespace))
.AddCallHandler<TestHandler>();

container.RegisterType(typeof (IInterface), typeof (Implementation),
new Interceptor<InterfaceInterceptor>(),
new InterceptionBehavior<PolicyInjectionBehavior>());

Assert.Equal(0, TestHandler.InstanceCount);

container.Resolve<IInterface>().Foo();

// interception will have needed to use a test handler
Assert.Equal(1, TestHandler.InstanceCount);

// 2nd resolve for test handler
container.Resolve<TestHandler>();

// did we get singleton behavior as expected?
Assert.Equal(useSingleton ? 1 : 2, TestHandler.InstanceCount);
}
}

public interface IInterface
{
void Foo();
}

private class Implementation : IInterface
{
void IInterface.Foo()
{
}
}

internal class TestHandler : ICallHandler
{
private static int NextId;
private readonly int id;

public TestHandler()
{
id = Interlocked.Increment(ref NextId);
Debug.WriteLine(string.Format("Created instance {0}.", id), GetType().Name);
}

public static int InstanceCount
{
get { return NextId; }
private set { NextId = value; }
}

IMethodReturn ICallHandler.Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
{
return getNext()(input, getNext);
}

public int Order { get; set; }

internal static void ResetInstanceCount()
{
InstanceCount = 0;
}
}
}
}
```
Comments: I believe that when CallHandlers are registered they are registered as <ICallHandler, ConcreteCallHandler>. So under the covers registering TestHandler is different from calling AddCallHandler<TestHandler>. Also, when calling AddCallHandler a LifetimeManager can be supplied. Since in the example no LifetimeManager was supplied the TestCallHandler (as ICallHandler) gets registered with a TransientLifetimeManager. Now usually, one does not want to directly resolve their CallHandler so simply registering the CallHandler with a ContainerControlledLifetimeManager is sufficient: ``` container.AddNewExtension<Interception>() .Configure<Interception>() .AddPolicy("test") .AddMatchingRule(new NamespaceMatchingRule(typeof(Program).Namespace)) .AddCallHandler<TestHandler>(new ContainerControlledLifetimeManager()); ``` If you did want TestHandler to be a true singleton then there are a variety ways of doing that. One way is to directly register the TestHandler singleton instance in AddCallHandler: ``` container.RegisterType<TestHandler>(new ContainerControlledLifetimeManager()); container.AddNewExtension<Interception>() .Configure<Interception>() .AddPolicy("test") .AddMatchingRule(new NamespaceMatchingRule(typeof(Program).Namespace)) .AddCallHandler(container.Resolve<TestHandler>()); ``` Another way would be to register and resolve TestHandler by name and specify the name in the AddCallHandler call: ``` container.RegisterType<TestHandler>(typeof(TestHandler).Name, new ContainerControlledLifetimeManager()); container.AddNewExtension<Interception>() .Configure<Interception>() .AddPolicy("test") .AddMatchingRule(new NamespaceMatchingRule(typeof(Program).Namespace)) .AddCallHandler<TestHandler>(typeof(TestHandler).Name); var testHandler1 = container.Resolve<ICallHandler>(typeof(TestHandler).Name); var testHandler2 = container.Resolve<TestHandler>(typeof(TestHandler).Name); ``` Note, however, if you attempted to resolve TestHandler without a name then you would receive a new instance. But that is always true when resolving concrete types by name. ~~ Randy Levy [entlib.support@live.com](mailto:entlib.support@live.com) Enterprise Library support engineer [Support How-to](entlib.codeplex.com/wikipage?title=Support%20How-to)

Created Issue: Unity does not respect lifetime manager for call handler [12726]

JochenZ — Mon, 25 Feb 2013 15:44:09 GMT