[请教]关于 .NET 应用的几个问题请教！！！
0
悬赏园豆：100
[已关闭问题]
关闭于 2008-05-15 16:44
1—— <BR>在.NET应用中，假如一个DLL想给多个应用程序共享，常规方案是注册到GAC，但这个方案很麻烦，需要注册，容易产生垃圾。 <BR>（比如在 ASP.NET 中，如果更新注册到GAC中的DLL非常不方便，特别是大型网站使用负载均衡时代码同步）。 <BR><BR>问题： <BR><BR>能否不注册到 GAC 也能让多个应用共享DLL？比如：某些项目可以把 DLL 放置到 PROGRAM FILES 文件夹的 COMMON 中来实现。 <BR><BR>2—— <BR>同问题1，在ASP.NET应用中，多个WEB站点使用了很多相同的DLL模块，能否让这些站点从相同的文件夹中获取？（不使用GAC方案）。 <BR><BR>3—— <BR>在 .NET 应用中，某个类具备一个 VIRTUAL 或 ABSTRACT 的方法或属性，其好处显而易见。 <BR><BR>问题： <BR>如何让派生的子类不能重载原本可以重载的方法或属性。
所有回答(3)
0
不使用GAC好象比较困难. 放在一个地方理论上好象是可行的. Assembly.Load方法可以指定路径. 但是使用起来还是不方便吧....
3. 这个应该是有确定性的吧，如果需要被覆写才作标记，如果不需要覆写那就不要标.
0
1,我更推荐每个程序都复制一份自己的私有程序集.这样部署起来更简单,单独升级也更容易.这也正是.Net的一个目标:XCopy部署.
如果一定要共享,我觉得还是放到GAC比较合适,因为GAC不仅仅是一个文件夹,它还有版本管理的功能,能在很大程度上避免dll hell.
2,可以,通过反射(Assembly.Load***),动态加载程序集. 不过这样一来就失去了"程序集一旦被修改,就自动重启AppDomain"的好处,可能还有很多其它方面需要注意和处理.
3,添加一个中间类,里面用new关键字重新定义一个与父类相同签名和访问公开性的非虚拟方法.
其实,这样的需求,倒不如不用继承,而是把父类拆分为几个接口,然后用Extension methods分别给不同的接口添加不同的方法.博客园前一段有人讨论过这种设计方法.
0
对于问题一和二，其实都没必要，增加开发成本，同时这也是一种耦合的加强而已。
问题三
如果子类和父类不在一个dll中，比如
子类 class child 在child dll中，父类 class father 在 father.dll
那么只需要把father 里面的 virtual 方法定义个一个只有father.dll可见的类型。abstract方法则是必须实现的，否则编译都通不过的。
如果在同一个dll中，做这件事情是没有意义的，如果一个类不能继承，其他类都不能继承，那还virtual 什么？为了降低性能？
