c#程序集.docx
《c#程序集.docx》由会员分享，可在线阅读，更多相关《c#程序集.docx（16页珍藏版）》请在冰豆网上搜索。
c#程序集
程序集的定义：
1.程序集是一个或多个托管模块，以及一些资源文件的逻辑集合。
2.程序集是组建复用，以及实施版本策略和安全策略的最小单位。
3.程序集是包含一个或者多个类型定义文件和资源文件的集合。
在程序集包含的所有文件中，有一个文件用于保存清单。
（清单是元数据部分中一组数据表的集合，其中包含了程序集一本分文件的名称，描述了程序集的版本，语言文化，发布者，共有导出数据，以及组成该程序集的所有文件）。
程序集的物理表现：
1.可执行程序集：
存在一个用于表示.EXE的文件，这个文件是程序集的入口点。
2.提供功能的程序集：
存在一个用于表示DLL的文件，这个文件是程序集的入口点。
程序集和托管模块的关系：
1.可以使用 csc /t:
module type1.cs
csc /t:
module type2.cs
这样就可以生成两个托管模块：
module module
2.使用命令将模块集成到程序集中：
csc /out:
xxx.dll /t:
library /addmodule:
modulemodulexxx.cs
这样就有了程序集xxx.dll：
它由xxx.dllmodulemodule组成。
xxx.dll代表了这组程序集。
xxx.dll也可以是xxx.exe。
也可以使用al来创建：
Al/out:
xxx.dll/t:
librarymodulemodule.
3.卫星程序集：
3.1创建资源文件：
MyR.Resx或者MyR.txt
3.2使用命令resgenMyR.resx MyR.resources编译资源
3.3 al.exe/culture:
cn/out:
"cn\HelloWorld.Resources.dll"/embed:
"MyR.resources"/template:
"HelloWorld.exe"
3.4在主程序集HelloWorld中如何访问卫星程序集：
System.Resources.ResourceManagerresources=
newSystem.Resources.ResourceManager（"HelloWorld.Resources.MyResources",
System.Reflection.Assembly.GetExecutingAssembly（））;
//Printoutthe"HelloWorld"resourcestring
Console.WriteLine（resources.GetString（"HelloWorld"））;
//Getthenewculturename
Console.Write（resources.GetString（"NextCulture"））;
3.5部署主程序集和卫星程序集
3.│ HelloWorld.exe
├─ko-kr
│ HelloWorld.resources.dll
├─it
│ HelloWorld.resources.dll
├─fr
│ HelloWorld.resources.dll
├─es
│ HelloWorld.resources.dll
├─en
│ HelloWorld.resources.dll
├─en-us
│ HelloWorld.resources.dll
└─de
HelloWorld.resources.dll
4.通过AL工具来改变一个程序集的各种属性：
可以参见AL的帮助
通过AssemblyInfo.cs文件来改变一个程序集的属性：
这个文件中最重要的几个特性是：
1、AssemblyVersion:
格式：
MajorVersion----Minor Version------Build version------ Revision
2、[assembly:
AssemblyCulture（""）]
3、[assembly:
AssemblyDelaySign（false）]
4、[assembly:
AssemblyKeyFile（""）]
5、[assembly:
AssemblyKeyName（""）]
这几个各个程序集属性的探讨
将程序集组成各种应用程序，进行程序集的部署：
不考虑应用程序的类型，可以将程序集的部署分为私有部署和全局部署。
私有部署：
1.本地应用程序的部署结构
AppDir
|----App.exe
|----App.exe.config
|-----AuxFilesDir
|------xxx.dll
|------yyy.dll
在App.exe.config中可以配置影响CLR寻找程序集路径的选项。
2.A应用程序和XMLWeb服务应用程序
对于Web窗口和XMLWeb服务应用程序，配置文件必须位于Web应用程序的虚拟根目录下，并且名称总是Web.config。
另外子目录也可以包含它们自己的Web.config文件，并继承上一目录的配置设置。
3.对于包含客户方空件、以微软的IE浏览器为宿主的程序集。
（没有见过）
一、程序集的一些基本概念：
程序集是包含一个或多个类型定义文件和资源文件的集合。
它允许我们分离可重用类型的逻辑表示和物理表示.
程序集是一个可重用、可实施版本策略和安全策略的单元。
它允许我们将类型和资源划分到不同的文件中，这样程序集的使用者便可以决定将哪些文件打包在一起部署。
一旦CLR加载了程序集中包含清单的那个文件，它就可以确定程序集的其他文件中哪些包含了程序正在引用的类型和资源。
任何程序集的使用者仅需要知道包含清单的文件名称。
文件的划分对使用者是透明的，并且可以在将来改变，同时又不会破坏现有应用程序的行为。
程序集的特性：
1、程序集定义了可重用的类型。
2、程序集标识有一个版本号。
3、程序集可以包含与之相关的安全信息。
二、多文件集：
使用多文件集的三个原因：
1、可以将类型分别实现在不同的文件中，从而允许文件在互联网环境中进行增量下载。
2、可以按需要向程序集中添加资源或数据文件。
（数据文件可以是任何格式：
文本文件、Excel电子表格、Word表格、或者任何我们喜欢的格式）。
3、可以使我们创建的程序集包含一些用不同编程语言实现的类型。
注意：
VisualStudio.NET集成开发环境（Integrateddevelopmentenvironment，简称IDE）本身不支持创建多文件程序集，如果需要创建多文件程序集，必须求助于命令行工具。
两个源代码文件：
Rut.cs（包含很少使用的类型）Fut.cs（包含经常使用的类型）
csc/t:
moduleRut.cs //生成Rmodule文件
csc/out:
UnionType.dll/t:
library/addmoduleRmodule Fut.cs
//生成UnionType.dll类库文件Rmodule文件作为程序集的一部分来对待
三、程序链接器：
程序链接器：
AssemblyLinker即AL.exe
1、使用前提：
如果我们要创建的程序集包含来自不同编译器生成的模块，而使用的编译器又不支持类似于C#中/addmodule那样的命令行开关，或者生成模块时还不知道程序集的打包需求，这时程序集链接器就显得非常有用。
2、使用实例：
csc/t:
moduleRut.cs
csc/t:
moduleFut.cs
al/out:
UnionType.dll/t:
libraryFmoduleRmodule
四、资源文件的添加
1．使用csc.exe来添加资源文件：
/resource将把指定的资源文件嵌入到产生的程序集PE文件中，并更新ManifestResourceDef表中的内容。
/linkresource将向ManifestResourceDef和FileDef清单表中添加一条目，使其指向一个单独的资源文件。
2．使用AL.exe来添加资源文件：
/embed[resource]：
该命令行接受任何类型的文件，将其内容嵌入到产生的PE文件中。
同时，清单中的ManifestResourceDef表将被更新以反映该资源的存在。
/link[resource]：
该命令将只更新清单中的ManifestResourceDef表和FileDef表，以反映资源的存在，并标识出程序集的哪个文件包含着资源文件。
资源文件本身不会被嵌入到程序集PE文件中，它仍然保持独立，并且须和其它程序一起打包、部署。
3．将Win32资源嵌入到程序集中：
通过AL.exe或csc.exe添加/win32res命令行开关指定一个.res文件路径来实现。
通过AL.exe或csc.exe添加/win32icon命令行开关并指定一个.ico文件路径来实现。
五、程序集版本信息：
版本号由四个部分组成：
主版本号、次版本号、生成版本号、修订版本号
例：
2.5.719.2主版本号与次版本号组成“面向公众”的版本部分，第三个版本号719表示程序集的生成版本，最后一个版本号2表示对生成版本的修订版本。
一个程序集的三个相关版本号：
1、 AssemblyFileVersion：
该版本号存储在Win32版本资源中，它仅仅是一个辅助性的信息。
2、 AssemblyInformationalVersionAttribute：
该版本号也存储在Win32版本资源中，仅辅助性作用。
3、 AssemblyVersion：
该版本号存储在AssemblyDef清单元数据表中。
这个版本号非常重要，它用来惟一地标识一个程序集。
六、语言文化：
不提倡创建包含代码的卫星程序集，但还是有可能做到。
如果我们愿意，仍然可以用System.Reflection.AssemblyCultureAttribute定制特性来代替AL.exe的/culture命令行开关来指定语言文化。
示例如下：
//将程序集的语言文化设置为瑞士德语
[assembly：
AssemblyCulture（“de-CH”）]
通常情况下，我们创建的程序集不应该引用卫星程序集。
也就是一个程序集的AssemblyRef条目指向的都应该是语言文化中性的程序集。
如果想访问一个卫星程序集中的类型或成员，我们应该使用反射技巧。
卫星程序集：
标识着特定语言文件的程序集称为卫星程序集。
七、共享程序集：
1．.NET框架支持的两种程序集：
弱命名程序集：
Weaklynamedassembly
强命名程序集：
Stronglynamedassembly
二者之间的真正区别在于：
强命名程序集有一个发布者的公钥/私钥对签名，其中的公钥/私钥匙对惟一地标识了程序集的发布者。
强命名集包含四个惟一标识程序集的特性：
文件名（没有扩展名）、版本号、语言文化标识和一个公有密钥标识。
例：
”MyTypes,Version=1.0.8123.0,Culture=neutral,PublicKeyToken=b77a5c561934e089”
2．强命名实用工具：
StrongNameUtility即SN.exe和.Net框架SDK，以及Visualstudio.Net一起发布的一个工具。
例：
SN–kMyCompany.keys
该命令告诉SN.exe创建一个名为Mycompany.keys的文件。
Mycompany.keys文件将包含一对以二进制格式存储的公有密钥和私有密钥。
查看公有密钥：
（必须执行下面两步）
SN–pMyCompany.keysMyCompany.publickey
SN–tpMyCompany.publickey
创建强命名程序集：
[assembly:
AssemblykeyFile（“MyCompany.keys”）]
3．程序集的两种部署方式：
即私有部署方式和全局部署方式
私有部署方式将程序集部署在应用程序的基目录及其子目录下，弱命名程序集只能进行私有部署。
全局部署方式将程序集部署在一些CLR确知的地方。
强命名程序集既可以进行私有部署，也可以进行全局部署。
4．System.Reflection.AssemblyName类：
利用它，我们可以很容易地创建一个程序集名称，并获取一个程序集名称的各个部分。
公有实例属性：
如CultureInfo、FullName、KeyPair、Name以及Version.该类提供了几个公有实例方法，如GetPublicKey、GetPublicKeyToken、SetPublicKey、以及SetPublicKeyToken。
八、其他
元数据标识是一个4字节的数值，其高位字节表示标记的类型（0x01=TypeRef,0x02=TypeDef,0x26=FileDef,0x27=ExportedType）
为使我们创建的程序集出现在.NET选项卡的列表中，可以将下面的子键添加到注册表中：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\
C#程序集的定义
程序集是包含一个或多个类型定义文件和资源文件的集合。
它允许我们分离可重用类型的逻辑表示和物理表示。
程序集是一个可重用、可实施版本策略和安全策略的单元。
它允许我们将类型和资源划分到不同的文件中，这样程序集的使用者便可以决定将哪些文件打包在一起部署。
一旦CLR加载了程序集中包含清单的那个文件，它就可以确定程序集的其它文件中哪些包含了程序正在引用的类型和资源。
任何程序集的使用者仅需要知道包含清单的文件名称。
文件的划分对使用都是透明的，并且可以在将来改变，同时又不会破坏现有的应用程序的行为。
程序集的特性：
1、程序集定义了可重用的类型。
2、程序集标识有一个版本号。
3、程序集可以包含与之相关的安全信息。
二、多文件集：
使用多文件集的三个原因：
1、可以将类型分别实现在不同的文件中，从而允许文件在互联网环境中进行增量下载。
2、可以按需要向程序集中添加资源或数据文件。
（数据文件可以是任何格式：
文本文件、excel电子表格、word表格、或者任何我们喜欢的格式）。
3、可以使我们创建的程序集包含一些用不同编程语言实现的类型。
三、程序链接器：
程序链接器：
AssemblyLinker即AL.exe
1、使用前提：
如果我们要创建的程序集包含来自不同的编译器生成的模块，而使用的编译器又不支持类似于C＃中/addmodule那样的命令行开关，或者生成模块时还不知道程序集的打包需求，这时程序集链接器就显示非常有用。
四、程序集的分类：
共享程序集：
程序集可以是共享的，也可以是私有的。
私有程序集位于应用程序所在的目录下，或其子目录下中。
使用私有程序集是，不需要考虑与其他类的命名冲突或版本冲突问题。
在构建过程中引用的程序集会复制到应用程序的目录下。
私有程序集是构建程序集的一般方式，特别是应用程序和组件在同一个公司中建立时，就更是如此。
共享程序集：
在使用共享程序集时，必须遵循一些规则。
程序集必须是惟一的，因此，必须有一个惟一的名称（称为强名）。
该名称的一部分是一个强制的版本号。
当组件由另一个开发商构建，而不是应用程序的开发商构建时，以及一个大应用程序分布在几个小项目中时，常常需要使用共享程序集。
13.1程序集的含义
在引入.NET平台前，我们必须学习程序集之前的技术：
一般的DLL导出全局函数，COMDLL导出COM类。
Microsoft使用短语DLL-Hell来描述与DLL相关的问题。
应用程序中断通常是因为新安装的应用程序重写了另一个应用程序使用的DLL。
有时安装时用一个新DLL替代旧DLL也会发生应用程序中断的情况，因为安装应用程序不能正确的检查版本，或者版本设置不正确。
旧DLL用新版本替代而发生程序中断的情况比较多见。
一般情况下，这不应是一个问题，新DLL应与旧DLL版本向后兼容，但事实是常常出现不兼容的情况。
Windows2000引入了并行特性，允许在应用程序的目录中安装多个DLL。
利用这种并行功能，已安装的共享DLL的不同版本就可以安装在该应用程序的目录中。
重新编写LoadLibrary（）Win30API调用，使它先在应用程序目录中查找.local文件。
如果找到这个文件，API会首先检查DLL是否在应用程序所在的目录下。
再使用其他机制查找共享的DLL，这也会修改注册表中COMDLL的固定路径。
并行是一种事后补救措施，不能解决所有的问题，同时也引入了一些新的COMDLL问题。
Windows2000及以后的Windows操作系统版本处理DLL-Hell的另一个特性是文件保护：
系统DLL不会被未授权的团体重写。
所有这些功能所处理的都是问题本身，而非其源头。
DLL的版本问题产生的原因是不知道每个应用程序需要哪个特定的DLL版本。
使用传统的DLL结构不能跟踪或加强这种依赖关系。
COMDLL似乎可以解决许多DLL问题，因为其执行方式和接口是独立的。
接口是客户机和组件之间的契约，根据COM规则，这是不会改变的，因此不会中断程序。
但是，即使使用了COM，执行方式的改变也会中断现有的应用程序。
并行处理也支持COMDLL。
如果没有试用并行功能的COMDLL，就会以为这仅是一种窃用。
在使用并行的COMDLL时，会产生新的问题。
如果不卸载旧版本，而是用新的DLL覆盖旧版本，当同一组件的两个版本使用不同的线程配置时，会发生什么情况？
配置信息从最后一个安装的版本中调用。
问题的产生是因为COM组件的配置没有存储在组件自身的DLL中，而是存储在注册表中。
13.1.1 DLL-Hell的解决方案
.NET平台对DLLHell及其所有问题的答案是使用程序集。
程序集是自我描述的安装单元，由一个或多个文件组成，一个程序集可以是一个包括元数据的DLL或EXE，也可以由多个文件组成，例如资源文件、元数据、DLL和EXE。
程序集的安装仅是复制所有的文件而已，使用xcopy命令即可完成安装。
程序集的另一个优点是它们可以是私有或共享的。
使用COM，这些区别就不存在了，因为实际上所有的COM组件都是共享的。
如果在注册表中搜索一个COM组件或使用OleView，就必须查看上百个组件，这些组件很少用于多个应用程序，但每个组件都必须有一个全局惟一的标识符（GlobalUniqueIdentifier，GUID）。
私有程序集和共享程序集有很大的区别。
许多开发人员都喜欢只使用私有程序集。
私有程序集没有管理、注册和版本设置等问题，只有用户自己的应用程序在使用私有程序集时才有版本问题。
在这种应用程序中使用的私有组件应与应用程序一起安装。
本地应用程序目录可用于存储组件的程序集，所以不会有版本冲突问题。
其他应用程序都不会重写私有的程序集。
当然，仍可以使用私有程序集的版本号。
这非常有助于代码的修改，但它不是.NET所必须的。
使用私有程序集时，在开发阶段仍会有版本冲突问题。
例如，如果应用程序中使用的一个组件引用了程序集X的版本1，而在应用程序中使用了程序集X的版本2，则应把该程序集的哪个版本复制到应用程序目录中？
答案取决于先引用哪个版本。
版本冲突问题必须在开发阶段解决。
应用程序安装到系统上后，很容易发生用新版本的私有程序集替代旧版本的情况。
这种新版本冲突问题的惟一解决方法是安装新版本，因为这样其他应用程序都不会受影响。
在使用共享程序集时，有几个应用程序都使用这个程序集，且与它有一定的依赖关系。
使用共享程序集时，要遵循许多规则。
共享程序集必须有一个特殊的版本号、惟一的名称，通常安装在全局程序集缓存（globalassemblycache）中。
13.1.2 程序集的特性
程序集的特性可以总结如下：
● 程序集是自我描述的。
不再需要考虑注册表键、从其他地方获得类库等问题，程序集包含描述程序集的元数据，元数据包括从程序集中导出的类和一个清单。
下一节将介绍清单。
● 版本的相互依赖性在程序集的清单中进行了记录。
引用程序集的版本被存储在程序集的清单中，这样就可以确切地了解在开发过程中使用的程序集版本号。
以后使用的引用程序集版本可以由开发人员和系统管理员配置。
在本章后面的一节中，将介绍可利用的版本策略及其工作方式。
● 程序集可以并行加载。
使用Windows2000，就可以获得并行功能，同一个DLL的不同版本就可以在系统上同时使用。
.NET扩展了Windows2000的功能：
现在同一个程序集的不同版本也可以在一个进程中使用！
那么这有什么用呢？
如果程序集A引用共享程序集Shared的版本1，程序集B引用共享程序集Shared的版本2，而用户同时使用程序集A和程序集B，则应用程序需要使用共享程序集Shared的这两个版本，在.NET中，应加载和使用两个版本。
● 应用程序使用应用程序域（ApplicationDomain）来确保其独立性。
使用应用程序域，许多应用程序就可以独立地运行在一个进程中。
一个应用程序中的错误不会影响同一个进程中的其他应用程序。
● 安装非常简单，只需复制一个程序集中的所有文件，一个xcopy命令就足够了。
这个特性称为无干涉部署（no-touchdeployment）。
但是在一些情况下不能进行无干涉部署，而需要正常的
升级会员 