unity配置文件问题

[idot]

最近开始学习Unity框架，刚一开始就遇到配置文件问题：

App.config内容如下：

<?xml version="1.0"?>
<configuration>
<configSections>
<section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>
</configSections>

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
<assembly name="mscorlib, 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<assembly name="winApp"/>
<namespace name="System.Windows.Forms"/>
<namespace name="winApp"/>
<container>
<register type="Form" name="startup" mapTo="Form1"/>
</container>
</unity>
</configuration>


Program.cs内容如下：

using System;
using System.Windows.Forms;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;

namespace winApp {
static class Program {
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main() {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);

IUnityContainer unityContainer = null;
unityContainer = new UnityContainer().LoadConfiguration();
Application.Run(unityContainer.RegisterType<Form>().Resolve<Form>("startup"));
}
}
}

希望熟悉Unity框架的同仁帮解决一下，谢谢。

[idot]

这个配置文件是参考官方的文档写的，原文如下：

CLR Type Names
You can specify a type name by using the CLR standard type name syntax, as shown in the following example:

<namespace>.<typename>, <assembly>

You can use either partial assembly names or fully qualified assembly names which include the culture, version, and public key token. These names are straightforward for simple types.

In order to specify a name for a type that is in the global assembly cache, you must use the fully qualified assembly name for the type to be correctly loaded. For example, for System.String, a type in mscorlib, you cannot use System.String, mscorlib. You must use the fully qualified assembly name, System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.

CLR type names can be very verbose, especially when working with generic types. For example, compare the following simple dictionary in C# or Visual Basic with the CLR example:

C# Copy Code
Dictionary<string, int>

Visual Basic Copy Code
Dictionary(Of String, Integer)

CLR Copy Code
System.Collections.Generic.Dictionary`2[[System.String, mscorlib, 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089], [System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089


In order to expedite the process and make type names less error prone, Unity configuration provides two options you can use in the configuration file: aliases and automatic type lookup.

Type Aliases
An alias is simply a shorthand name that will be replaced with the full type name when configuration is applied to the container. You specify an alias in the configuration file inside the section, but outside any <container> elements, as shown in the following example:

XML Copy Code
<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
<alias alias="MyAlias" type="full type name" />
...
</unity>


There are the following rules for using aliases:

You can have an arbitrary number of <alias> elements in the configuration file.
Anywhere you can give a type name you can use an alias instead.
There are no recursive aliases, which means that you cannot use an alias to define the type for an alias.
Alias names are case sensitive: <alias alias="int" /> and <alias alias="Int" /> are two different aliases and are not interchangeable.

Note:
Aliases only exist at configuration time. They are not available at run time.



Automatic Type Lookup
In many cases, like for ILogger in the Format of the Unity Configuration File example, the name of a type is all that is required. But given Unity's dependence on types and the large number of types typically involved in a configuration, the ability to perform automatic type lookups further expedites the process. By incorporating automatic type lookups, Unity also eliminates the need to define an alias for every type in an assembly, which saves effort and serves to reduce the chance for error from repeatedly typing the namespace and assembly name.

The Unity configuration system can search for types. However, it will only look for types if the type name specified is not a full type name and it is not an alias. You can provide the configuration section with the namespaces and assemblies to look through by using the <namespace> and <assembly> elements, as shown in the following example.

XML Copy Code
<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
<namespace name="MyApp.Interfaces" />
<namespace name="System" />
<assembly name="MyApp” />
<assembly name="mscorlib, 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

...
</unity>


With the configuration shown in the previous example, when the configuration system hits a name it does not recognize as a type name or alias, it will then search through the assemblies and namespaces for a match. So, to find ILogger, it will try to match the following names in order:

MyApp.Interfaces.ILogger, MyApp
System.ILogger, MyApp
MyApp.Interfaces.ILogger, mscorlib, 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.ILogger, mscorlib, 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
The search will stop at the first matching type.

The system uses simple string concatenation to create the type name it attempts to load. However, you cannot specify a namespace qualified name plus the type, MyApp.Interfaces.ILogger, MyApp, if you have any namespace elements in your configuration section, <namespace name="System" />.The namespace from the configuration section will be appended to the namespace, resulting in a search on the wrong name, System.MyApp.Interfaces.ILogger. You should put namespaces in the <namespace> elements instead of on the type names in the configuration file to avoid this possibility.

If you have a large number of assemblies and namespaces, then the system type search could take a significant amount of time to complete. Normally, containers are only configured at application startup, so this time hit will not be significant during the operation of your application. If you find it becomes a significant issue, then you should consider using an explicit alias for the types that take the greatest search times, since aliases are matched first.

When matching a name with a type, the configuration system performs the following steps in order. The first one to succeed stops the process:

Attempt to load a type using the name directly (treated as a full type name)
Attempt to match a name to an alias
Do automatic type search

[idot]

启动程序后出现错误，提示：The type name or alias Form could not be resolved. Please check your configuration file and verify this type name.

[shclhs]

type="Form"

对于这个类，你没有指定它的assembly
<assembly name="...." />

这样就好了

[reformer]

[Quote=引用 3 楼 的回复:]
type="Form"

对于这个类，你没有指定它的assembly
<assembly name="...." />

这样就好了
[/Quote]

我也碰见这个问题，麻烦给个完整点的配置文件例子，谢谢了。