latest

.vscode/tasks.json

@@ -12,11 +12,6 @@
                 "reveal": "silent"
             },
             "problemMatcher": "$msCompile"
-        },
-        {
-            "type": "gulp",
-            "task": "serve",
-            "problemMatcher": []
         }
     ]
 }

articles/features.md

@@ -4,15 +4,21 @@ uid: Article.Unity.Features
 
 # Features
 
-### Setup
+## General Features
+
+* No registration required for simple POCO types
+* Registration/updates at any time (no builder required)
+* Support registration metadata
+* Support generic types
+* Register existing objects
+* Custom Type factories
+* Register Type
+* List all registrations
+* Check existing registrations
+
+## Setup
 
 * Registration
-  * No registration required for simple POCO types
-  * Registration/updates at any time (no builder required)
-  * Support registration metadata
-  * Support generic types
-  * Register existing objects 
-  * Custom Type factories
   * Type mappings
     * Register as a `Type`
     * Support `Type` polymorphism

articles/history.md

@@ -0,0 +1,18 @@
+---
+uid: Article.Unity.History
+---
+
+# The Unity Container History
+
+| Year | Release | Authors and Contributors |
+|:-----| :-----------: | :----- |
+| | | |
+| October 2017 | Unity 5 | GitHub Community Site |
+| October 2015 | Unity 4 | GitHub Community Site |
+| April 2014 | [Unity 3.5](https://archive.codeplex.com/?p=unity) | CodePlex Community Site |
+| April 2013 | [Unity 3](https://docs.microsoft.com/en-us/previous-versions/msp-n-p/dn170416(v%3dpandp.10)) | CodePlex Community Site |
+| Aug 2012 | [Unity 2.1](https://docs.microsoft.com/en-us/previous-versions/msp-n-p/hh237492(v%3dpandp.10)) | CodePlex Community Site |
+| April 2010 | [Unity 2.0](https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff663144(v%3dpandp.10)) | Grigori Melnik, Bob Brumfield, Chris Tavares, Fernando Simonazzi, Nicolas Botto, Olaf Conijn, Carlos Farre, Masashi Narumoto, Rohit Sharma, Lavanya Selvaraj, Magdelene Sona, Mani Krishnaswami, Meenakshi Krishnamoorthi, Santhosh Panneerselvam, Ravindra Varman, Erik Renaud, François Tanguay, Rick Carr, Alex Homer, Dennis DeWitt, RoAnn Corbisier, Steve Elston, Nancy Michel, Patrick Lanfear, Tom Draper, Richard Burte, Jennifer Burch, Tracy Emory |
+| October 2008 | [Unity Application Block 1.2](https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff647347(v%3dpandp.10))  | Grigori Melnik, Chris Tavares, Fernando Simonazzi, Vijaya Janakiraman, Carlos Farre, Dennis DeWitt, Alex Homer, Nelly Delgado, RoAnn Corbisier, Tina Burden McGrayne, Richard Burte |
+| May 2008 | [Unity Application Block 1.1](https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff649080(v%3dpandp.10))| Grigori Melnik, Scott Densmore, William Loeffler, Chris Tavares, Fernando Simonazzi, Nicolas Botto, Hanz Zhang, Carlos Farre, Naveen Guda, Pooja Parate, Pravin Pawar, Ronita Acharya, Sai Pasumarthi, Venkata Appaji Sirangi, Vijaya Janakiraman, Alex Homer, Nelly Delgado, RoAnn Corbisier, Tina Burden McGrayne |
+

gulpfile.js

@@ -43,7 +43,6 @@ const paths = watched();
 const watch = () => gulp.watch(paths, gulp.series(build, reload));
 
 exports.default = gulp.parallel(watch, serve);
-exports.watch = watch;
 exports.serve = serve;
-exports.build = gulp.series(build, reload);
+exports.build = build;
 exports.develop = exports.default;

tutorials/Annotation/annotation.md

@@ -1,9 +1,9 @@
 ---
 uid: Tutorial.Annotation
-title: Type Annotation
+title: Attributed Injection Model
 ---
 
-# Type Annotation
+# Attributed Injection Model
 
 One of the most useful and powerful techniques when using Unity is to take advantage of dependency injection for the parameters of class constructors and methods, and for the values of fields and properties. This approach allows you to resolve and populate the entire hierarchy of objects used in your application based on type registrations and mappings defined in the container, with the subsequent advantages this offers.
 

tutorials/Annotation/overview.md

@@ -1,25 +0,0 @@
----
-uid: Tutorial.Annotation.Overview
----
-
-# Using Injection Attributes
-
-One of the most useful and powerful techniques when using Unity is to take advantage of dependency injection for the parameters of class constructors and methods, and for the values of fields and properties. This approach allows you to resolve and populate the entire hierarchy of objects used in your application based on type registrations and mappings defined in the container, with the subsequent advantages this offers.
-
-You can specify constructor, field, property, and method call injection information in configuration or by adding registrations to the container at run time. You can also apply attributes to members of your classes to indicate injection targets. When you resolve these classes through the container, Unity will generate instances of the dependent objects and wire up the injection targets with these instances.
-
-Normally, Unity performs selection of the constructor automatically by choosing the most complex constructor it can satisfy with dependencies and populating these parameters with resolved values when it constructs the object. In some cases, for various reasons, the constructor could not be selected successfully and container may throw an exception.
-
-To disambiguate selection or to override automatic behavior you could specify which constructor Unity should use to construct the object by marking it with [InjectionConstructor](xref:Unity.InjectionConstructorAttribute) attribute.
-
-Property, field, and method call injections do not occur automatically unless registered with appropriate injection members at run time. To enable automatic member injection for types you can add attributes to the members of your classes to force injection of dependent objects when the target class is resolved.
-
-Fields, Properties, and Parameters could be annotated with either [Dependency](xref:Unity.DependencyAttribute) or [OptionalDependency](xref:Unity.OptionalDependencyAttribute) attributes to indicate that these require values to be injected. For annotating methods you wish to be called during initialization you could use [InjectionMethod](xref:Unity.InjectionMethodAttribute)
-
-For more information, see:
-
-* [Annotating types for **Constructor** invocation](xref:Tutorial.Annotation.Constructor)
-* [Annotating types for **Method** invocation](xref:Tutorial.Annotation.Method)
-* [Annotating **Parameter** for injection](xref:Tutorial.Annotation.Parameter)
-* [Annotating types for **Field** injection](xref:Tutorial.Annotation.Field)
-* [Annotating types for **Property** injection](xref:Tutorial.Annotation.Property)

tutorials/Annotation/property.md

@@ -1,5 +1,6 @@
 ---
 uid: Tutorial.Annotation.Property
+title: Property Injection Annotation
 ---
 
 # Annotating Objects for Property Injection

tutorials/hierarchies.md

@@ -7,35 +7,38 @@ title: Container Hierarchy
 
 Unity container provides a way to create child containers (other systems refer to it as resolution scopes) and allows building sophisticated scope trees of registrations. There are just a few simple rules to follow when dealing with container hierarchies:
 
-### Types registered in predecessor containers always available in descendant containers
+* Types registered in predecessor containers always available in descendant containers. This is a very simple concept, each registration is like a public virtual declaration in cs types. Every descendant inherits it and can use at will.
 
-This is a very simple concept, each registration is like a public virtual declaration in cs types. Every descendant inherits it and can use at will.
+* Types registered in descendant containers override the same registration of predecessors. Following the same analogy with public virtual declarations, each override registration installs its own declaration and hides the one in predecessor containers.
 
-### Types registered in descendant containers override the same registration of predecessors
+## Using Container Hierarchies
 
-Following the same analogy with public virtual declarations, each override registration installs its own declaration and hides the one in predecessor containers.
-
-# Using Container Hierarchies
 Unity supports nested containers, allowing you to build container hierarchies. Nesting containers enables you to control the scope and lifetime of singleton objects, and register different mappings for specific types. This topic contains the following sections that describe how you can create container hierarchies and use them in your applications:
+
 * Constructing and Disposing Unity Containers
 * Controlling Object Scope and Lifetime
-* Registering Different Mappings for Specific Types
+* Overriding registrations
+
+### Constructing and Disposing Unity Containers
+
+The following methods enable you to create a new default UnityContainer, create a child container that has a specified UnityContainer as its parent, and dispose an existing container.
 
-## Constructing and Disposing Unity Containers
-The following methods enable you to create a new default UnityContainer, create a child container that has a specified UnityContainer as its parent, and dispose an existing container. 
 | Method | Description |
-|:-----|-----|
+|:-----| ----- |
 |`new UnityContainer()`|Creates a root UnityContainer. Returns a reference to the new container.|
 |`CreateChildContainer()`|Creates a new nested UnityContainer as a child of the current container. The current container first applies its own settings, and then it checks the parent for additional settings. Returns a reference to the new container.|
 |`Dispose()`|Disposes this container instance and any child containers. Also disposes any registered object instances whose lifetimes are managed by the container.|
 
-## Controlling Object Scope and Lifetime
+### Controlling Object Scope and Lifetime
+
 When the container creates singleton objects, it manages the lifetime of these singletons. They remain in scope until you (or the garbage collector) dispose the container. At this point, it disposes the registered singleton instances it contains. In addition, if you dispose the parent container in a nested container hierarchy, it automatically disposes all child containers and the registered singletons they contain.
 
 Therefore, if you require two separate sets of such objects that must have different lifetimes, you can use hierarchical containers to store and manage each set. Register instances that you want to be able to dispose separately in one or more child containers that you can dispose without disposing the parent container.
 
 The following code demonstrates the use of a child container to manage the lifetime of specific singleton instances while maintaining the singleton instances in the parent container.
+
 ```cs
+
 // Create parent container
 IUnityContainer parentCtr = new UnityContainer();
 
@@ -64,7 +67,9 @@ childCtr.Dispose();
 // Dispose parent container
 parentCtr.Dispose();
 ```
-## Overriding registrations
+
+### Overriding registrations
+
 You can use nested containers when you have slightly different dependency injection requirements for specific objects but want to provide a fallback facility for objects that implement a specific interface or are of a specific type. For example, you may have a general requirement for objects that implement the IMyObject interface to map to the type MyStandardObject. However, in specific parts of the application code, you may want the IMyObject interface to map to the type MySpecialObject.
 
 In this case, you can register the general mapping in the parent container and register the specific case in a child container. Then, when you want to obtain an instance of the object, you call the Resolve method on the appropriate container. If you call the method on the child container, it returns an object of type MySpecialObject. If you call the method on the parent container, it returns an object of type MyStandardObject.
@@ -72,6 +77,7 @@ In this case, you can register the general mapping in the parent container and r
 However, the advantage with nested containers is that, if the child container cannot locate a mapping for the requested interface or type, it passes the request to its parent container and onward through the hierarchy until it reaches the root or base container. Therefore, for objects not mapped in the child container, the mapping in the parent container (or in an ancestor container where there are more than two levels in the hierarchy) defines the object type returned.
 
 The following code shows how you can implement the preceding scenario.
+
 ```cs
 // Create parent container
 IUnityContainer parentCtr = new UnityContainer();

tutorials/toc.yml

@@ -1,11 +1,11 @@
 - name: Terms and Definitions
   uid: Tutorial.Terms
+- name: Attributed Injection Model
+  href: Annotation/toc.yml
+  topicUid: Tutorial.Annotation
 - name: Registration
   href: Registration/toc.yml
   topicUid: Tutorial.Registration
-- name: Type Annotation
-  href: Annotation/toc.yml
-  topicUid: Tutorial.Annotation
 - name: Resolution
   href: Resolution/toc.yml
   topicUid: Tutorial.Resolution