L'Unité peut être faite de ne pas jeter SynchronizationLockException tout le temps?

Je suis sûr qu'il ya beaucoup de façons de code pourrait appeler SynchronizedLifetimeManager, ou d'un descendant comme ContainerControlledLifetimeManager, mais il y avait deux scénarios, en particulier, qui ont été me causer des problèmes.

La première était de ma faute - j'ai été en utilisant le constructeur de l'injection de fournir une référence au conteneur, et dans ce constructeur, j'ai été également l'ajout de la nouvelle instance de la classe pour le conteneur pour une utilisation future. Cette rétro approche ayant pour effet de modifier la durée de vie du gestionnaire de Transitoire à ContainerControlled de sorte que l'objet de l'Unité appelée GetValue n'était pas le même objet, qu'il appelle SetValue sur. La leçon est ne rien faire pendant la phase de construction qui pourrait changer la vie de l'objet gestionnaire.

Le deuxième scénario, c'est que chaque fois RegisterInstance est appelé, UnityDefaultBehaviorExtension appels SetValue sans appel GetValue premier. Heureusement, l'Unité est suffisamment extensible que, avec assez sanglante d'esprit, vous pouvez contourner le problème.

De commencer avec un nouveau comportement de l'extension comme ceci:

///<summary>
///Replaces <see cref="UnityDefaultBehaviorExtension"/> to eliminate 
///<see cref="SynchronizationLockException"/> exceptions that would otherwise occur
///when using <c>RegisterInstance</c>.
///</summary>
public class UnitySafeBehaviorExtension : UnityDefaultBehaviorExtension
{
    ///<summary>
    ///Adds this extension's behavior to the container.
    ///</summary>
    protected override void Initialize()
    {
        Context.RegisteringInstance += PreRegisteringInstance;

        base.Initialize();
    }

    ///<summary>
    ///Handles the <see cref="ExtensionContext.RegisteringInstance"/> event by
    ///ensuring that, if the lifetime manager is a 
    ///<see cref="SynchronizedLifetimeManager"/> that its 
    ///<see cref="SynchronizedLifetimeManager.GetValue"/> method has been called.
    ///</summary>
    ///<param name="sender">The object responsible for raising the event.</param>
    ///<param name="e">A <see cref="RegisterInstanceEventArgs"/> containing the
    ///event's data.</param>
    private void PreRegisteringInstance(object sender, RegisterInstanceEventArgs e)
    {
        if (e.LifetimeManager is SynchronizedLifetimeManager)
        {
            e.LifetimeManager.GetValue();
        }
    }
}

Alors vous avez besoin d'un moyen de remplacer le comportement par défaut. L'unité ne dispose pas d'une méthode pour supprimer une extension spécifique, de sorte que vous avez à tout supprimer et mettre les autres extensions de retour à nouveau:

public static IUnityContainer InstallCoreExtensions(this IUnityContainer container)
{
    container.RemoveAllExtensions();
    container.AddExtension(new UnityClearBuildPlanStrategies());
    container.AddExtension(new UnitySafeBehaviorExtension());

#pragma warning disable 612,618 //Marked as obsolete, but Unity still uses it internally.
    container.AddExtension(new InjectedMembers());
#pragma warning restore 612,618

    container.AddExtension(new UnityDefaultStrategiesExtension());

    return container;
}

Avis que UnityClearBuildPlanStrategies? RemoveAllExtensions efface toutes les conteneur des listes internes de politiques et de stratégies, sauf une, j'ai donc dû utiliser un autre poste pour éviter l'insertion de doublons quand j'ai restauré les extensions par défaut:

///<summary>
///Implements a <see cref="UnityContainerExtension"/> that clears the list of 
///build plan strategies held by the container.
///</summary>
public class UnityClearBuildPlanStrategies : UnityContainerExtension
{
    protected override void Initialize()
    {
        Context.BuildPlanStrategies.Clear();
    }
}

Maintenant, vous pouvez utiliser en toute sécurité RegisterInstance sans crainte d'être au bord de la folie. Juste pour être sûr, voici quelques tests:

[TestClass]
public class UnitySafeBehaviorExtensionTests : ITest
{
private IUnityContainer Container;
private List<Exception> FirstChanceExceptions;
[TestInitialize]
public void TestInitialize()
{
Container = new UnityContainer();
FirstChanceExceptions = new List<Exception>();
AppDomain.CurrentDomain.FirstChanceException += FirstChanceExceptionRaised;
}
[TestCleanup]
public void TestCleanup()
{
AppDomain.CurrentDomain.FirstChanceException -= FirstChanceExceptionRaised;
}
private void FirstChanceExceptionRaised(object sender, FirstChanceExceptionEventArgs e)
{
FirstChanceExceptions.Add(e.Exception);
}
///<summary>
///Tests that the default behavior of <c>UnityContainer</c> leads to a <c>SynchronizationLockException</c>
///being throw on <c>RegisterInstance</c>.
///</summary>
[TestMethod]
public void UnityDefaultBehaviorRaisesExceptionOnRegisterInstance()
{
Container.RegisterInstance<ITest>(this);
Assert.AreEqual(1, FirstChanceExceptions.Count);
Assert.IsInstanceOfType(FirstChanceExceptions[0], typeof(SynchronizationLockException));
}
///<summary>
///Tests that <c>UnitySafeBehaviorExtension</c> protects against <c>SynchronizationLockException</c>s being
///thrown during calls to <c>RegisterInstance</c>.
///</summary>
[TestMethod]
public void SafeBehaviorPreventsExceptionOnRegisterInstance()
{
Container.RemoveAllExtensions();
Container.AddExtension(new UnitySafeBehaviorExtension());
Container.AddExtension(new InjectedMembers());
Container.AddExtension(new UnityDefaultStrategiesExtension());
Container.RegisterInstance<ITest>(this);
Assert.AreEqual(0, FirstChanceExceptions.Count);
}
}
public interface ITest { }

La réponse à votre question est malheureusement pas. J'ai suivi ce projet avec l'équipe de développement d'ici à Microsoft modèles & les pratiques de groupe (j'étais le dev y mener jusqu'à récemment)et nous avons eu cela comme un bug à prendre en compte pour EntLib 5.0. Nous avons fait quelques recherches, et en vint à la conclusion que c'était causé par certains des interactions inattendues entre notre code et le débogueur. Nous ne considérons un correctif mais cela s'est avéré plus complexe que le code existant. Dans la fin ce que cela a priorité ci-dessous d'autres choses et la barre n'était pas pour 5.

Désolé je n'ai pas de meilleure réponse pour vous. Si c'est une consolation, je la trouve trop irritant.

Rory solution est une grande grâce. Résolu un problème qui m'ennuie tous les jours!
J'ai fait quelques modifications mineures à Rory de solution pour qu'elle traite quelles que soient les extensions sont enregistrés (dans mon cas, j'ai eu un WPF Prisme/Composite extension)..

    public static void ReplaceBehaviourExtensionsWithSafeExtension(IUnityContainer container)
{
var extensionsField = container.GetType().GetField("extensions", BindingFlags.Instance | BindingFlags.NonPublic);
var extensionsList = (List<UnityContainerExtension>)extensionsField.GetValue(container);
var existingExtensions = extensionsList.ToArray();
container.RemoveAllExtensions();
container.AddExtension(new UnitySafeBehaviorExtension());
foreach (var extension in existingExtensions)
{
if (!(extension is UnityDefaultBehaviorExtension))
{
container.AddExtension(extension);
}
}
}

L'unité 2.1 - août 2012 mise à jour corrigera le bug

1. L'adressage d'un thread d'un problème de sécurité:
   http://unity.codeplex.com/discussions/328841

2. Amélioration de l'expérience de débogage sur le Système.Le filetage.SynchronizationLockException:
   https://entlib.uservoice.com/forums/89245-general/suggestions/2377307-fix-the-system-threading-synchronizationlockexcep

3. Amélioration de l'expérience de débogage grâce à de meilleurs messages d'erreur quand un type ne peut pas être chargé:
   http://unity.codeplex.com/workitem/9223

4. Soutenir un scénario de l'exécution d'une Accumulation de() sur une instance d'une classe qui ne possède pas de constructeur public:
   http://unity.codeplex.com/workitem/9460

À faire la mise à jour de l'expérience aussi simple que possible pour les utilisateurs et pour éviter la nécessité pour l'assemblée de liaison des redirections, nous avons choisi de n'augmente que l'assemblée de version de fichier, pas le .NET version de l'assembly.