返回信息流这几天在打算搞一个公司Intranet环境下的辅助工具系统的框架。
大概设想如下：
每个Utility会以exe的方式发布。
希望在第一运行的时候部署到自动检测本地环境，根据情况自动部署或者升级。
Utility之间可以互相发现（本地互相发现），包括启动起来的和未启动的Utility～
有些Utility启动以后会常驻～
新版本发布时，Utility可以检测到，并可以自动更新。
Utility可以发现远程的Utility，然后建立通信～
存在跨域的问题，因此需要在网关上架设代理服务器，转发数据包～
综上，整个系统类似于一个Intranet环境下的P2P自维护网络，网络里要负责Message的接力、路由和广播，支持连接和非连接，防火墙友好，支持RPC。
这是一个比较复杂的系统，打算一点点的完善。
这是一条镜像帖。来源：北邮人论坛 / dot-net / #2163同步于 2010/7/13
该镜像源已超过 30 天没有更新，可能在源站已被删除。
dotNET机器人发帖
［抛砖引玉］关于LAN环境下的自部署系统
TimNew
2010/7/13镜像同步17 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
今天在处理的问题是依赖注入：
设想的环境需要一种极其松散近乎0耦合的方式来实现Utility之间的依赖。
传统依赖注入，需要发布方和注入方共享某个Contract，于是会导致发布方会和注入方共同依赖于某个DLL。这就违背了设计中每个Utility是单Exe的模式。
因此这种依赖需要摆脱对Contract Interface的依赖。
于是我采取了一种Event Dispatch系统才会运用到的方法级的依赖注入。
即注入的单元不再是类型，Export方的实体是Method体，而Important方的实体则是Delegate类型的Property或者Field～
为了方便注入匹配的实现～
我考虑把引入ExportPoint和ImportPoint的概念～
实现IExportPoint接口，然后根据不同的Method（静态、实例）实现不同的具体ExportPoint～
同理处理IImportPoint接口，根据类型，实现不同的Property和Field（同样区分静态和实例）对应的ImportPoint～
具体的注入的方式是扫描Assembly，反射所有的TypeMember，找出Import和Export Attribute，然后形成合适的ImportPoint和ExportPoint实例，加入到Cache当中～必要的时候生成对象实例，并且储存到对象池中。
Assembler扫描Cache，遍历所有的ImportPoint，试图为其找出一个匹配的ExportPoint实例，匹配上就注入。
今天基本实现了这些功能了，明天稳定后，考虑开始加入利用Proxy实现的远端RPC的注入～明天代码整理以后考虑放一部分到论坛来～供大家探讨
【 在 wks 的大作中提到: 】
: 飞鸽传书？
: --
: 代做C语言作业，男生勿扰，有意者站内联系。
: ...................
不是～是一个基础平台～当然在这个平台上做个飞鸽是很容易的事情～
今天跑代码的时候，遇到一些问题～
嗯～
在依赖注入后，对象的Activation比较复杂～有static、singleton、new per instance以及new per request的情况～实在是有点复杂～
【 在 TimNew 的大作中提到: 】
: : 飞鸽传书？
: : --
: : 代做C语言作业，男生勿扰，有意者站内联系。
: ...................
ExportPoint related Classses：各种ExportPoint
附件(209.9KB) ExportPoint.emf
ImportPoint related Classes：各种ImportPoint
附件(353.5KB) ImportPoints.emf
Scanners: 扫描器，负责扫描各种类型的注入源，产生ImportPoint和ExportPoint
附件(145.4KB) Scanner.emf
Utilities: Extension Methods
附件(52.2KB) Utilities.emf
EMF是矢量图，无损缩放
谈下我对这个问题的看法：
这个task有三部分功能，
1、辅助工具系统的框架：服务器端，客户端。
2、每个utility，每个utility是以exe存在，独立自包含的，它不需要为该辅助工具系统做任何的更改。如果utility互相间要通信，那由单个utility负责。如果utility需要发现是否有程序打开，可以自己简单获取process列表，框架不关心(或者只提供一点小标示)。
3、提供单独的小工具负责网络代理的功能，启动网络代理，这个工具相当于Junifer Network的工具（如果能直接用这个工具，这个步骤可以省略，很多公司会用这个工具进行vpn）。
所以，需要完成的功能是“辅助工具系统的框架”：
1、服务器端
以服务方式存在（WCF），提供软件下载服务、通知client update、更新当前软件列表状态文件。另外，服务器端有一个xml文件，记录所有软件的名字、位置、是否需要框架客户端启动、是否需要客户端update等标识字段。
服务器端如果有文件更新，notify辅助框架客户端方法，自动下载更新软件列表文件并按照。
如果为了保证不下载多余的文件，可以对每个待部署的文件进行md5签名，这样下载时，本地文件跟服务器端的文件md5签名一致，则不下载。
2、辅助框架的客户端，也保存一份xml文件，标识已经部署的utility.exe，记录是否部署成功，以及是否需要更新，当前是否存于运行状态。
然后“客户端”针对这个xml文件，定期更新部署utility.exe，记录utility状态到xml文件中。
下次关机或重启之后，可自动重启辅助框架客户端，根据这个本地xml文件，启动exe，
而启动的方式通过process之类的方法。
如果这样来说的，就是WCF通信的问题了：）
【 在 TimNew 的大作中提到: 】
: 这几天在打算搞一个公司Intranet环境下的辅助工具系统的框架。
: 大概设想如下：
: 每个Utility会以exe的方式发布。
: ...................
【 在 TimNew 的大作中提到: 】
: 这几天在打算搞一个公司Intranet环境下的辅助工具系统的框架。
: 大概设想如下：
: 每个Utility会以exe的方式发布。
: ...................
可否考虑 .net 现有的技术?
终于把Unit Test给跑通了～
真够费劲的～
呵呵～
把完整代码先放上来～回头再解释～
Unit Test用了XUnit～可以到 http://xunit.codeplex.com/ 下载
【 在 TimNew 的大作中提到: 】
: 这几天在打算搞一个公司Intranet环境下的辅助工具系统的框架。
: 大概设想如下：
: 每个Utility会以exe的方式发布。
: ...................
【 在 ahomer 的大作中提到: 】
: 谈下我对这个问题的看法：
: 这个task有三部分功能，
: 1、辅助工具系统的框架：服务器端，客户端。
: ...................
我整理了一下思路：
我觉得框架需要有的功能是
1.方法级别的依赖注入，用于把各个Service和Component耦合起来
2.RPC机能，我在考虑利用依赖注入来实现，已经有一个大概的方案
3.带路由的数据连接，用于传送大规模的数据块或者文件等
4.Service和Component的发现，包括发现未启动的文件或者是内存中的实例
做这个东西目的不在于实现什么功能，或者做出什么东西，而是为了验证一些设计和架构理念～
因此不打算采用任何现有的平台或者工具。
换句话说，这个项目是一个半调研半工程的项目。放到这里是希望能大家一起讨论设计思路，论证方案的可行性。
目前来说，对于整体的构想，我还没有理出一个比较具体的思路来，不过对于一些细节的东西，我已经有一个大致的方案了。