不算喷，给你点建议。
看了你的类库，如果是为了学习，做类库无可厚非，可以作为经验的积累，但非常不建议你将类库拿来实用，尤其是这个学习阶段。
我公司里就有这种“架构师”非常热衷于写这种类库，被我严厉批评，这不仅对他人无益，而且对自己也非常有害。
一看这种封装的类库的特征，基本上就是把.Net类库中的已有功能再封装一遍，貌似是更适合自己使用，其实不然。
.1、Net类库具有极其丰富的方法重载，适用于各种不同的使用场景，而你封装了以后，实际上只用到了其中一个重载方法，
而且你未来也再没有机会去了解其他重载的方法。结果是本来能写的很简单的代码，封装以后，写的更加复杂了，因为你会发现
你要么需要不断的封装，要么勉强用现在的封装，然后搭配其他方法来达到你的目的，结果本来使用重载的方法，一行代码能解决的，反而写出了10行代码。
2、这种封装的方法，一看里边就只有几行代码的居多，本来封装意义不大。而且随着你技术的深入，最后你往往会发现，你的封装还是复杂化了，你最终可能发现封装的方法里，只有一两行代码是有效代码。封装变得没有意义
3、最有害的就是禁锢了你的思想，觉得自己的类库“好用”了，却不知道你觉得的好用只是你现在这个水平下的理解。而因为“好用”，你自然就失去了继续探索.Net类库的动力。在旁观者看来，就是刚学会5%的技术就沾沾自喜，结果是捡个芝麻，丢了个西瓜。
4、同样，这种类库对开发团队也是非常有害的，大家开发了半天，只是熟悉了你的类库，还是很糟糕的类库，而被禁锢在这种
类库上无法脱身，再过一年两年，都没有可能有技术进步。而真相就是，只有团队技术进步了，效率提升了，后面就会获得技术红利带来的好处。

我写框架，都抱着开放的心态，几乎没有Helper类封装，只使用Extend扩展，封装一般只限于业务层面和架构层面。结果是，原来架构的代码，只要充分利用.Net类库的功能，代码量可缩减三分之二，得到的是更干净更灵活的一个框架。

名字叫 re@son
是一个方法库，通过引用这个东西，可以方便的写出很多东西、 

不算喷，给你点建议。
看了你的类库，如果是为了学习，做类库无可厚非，可以作为经验的积累，但非常不建议你将类库拿来实用，尤其是这个学习阶段。
我公司里就有这种“架构师”非常热衷于写这种类库，被我严厉批评，这不仅对他人无益，而且对自己也非常有害。
一看这种封装的类库的特征，基本上就是把.Net类库中的已有功能再封装一遍，貌似是更适合自己使用，其实不然。
.1、Net类库具有极其丰富的方法重载，适用于各种不同的使用场景，而你封装了以后，实际上只用到了其中一个重载方法，
而且你未来也再没有机会去了解其他重载的方法。结果是本来能写的很简单的代码，封装以后，写的更加复杂了，因为你会发现
你要么需要不断的封装，要么勉强用现在的封装，然后搭配其他方法来达到你的目的，结果本来使用重载的方法，一行代码能解决的，反而写出了10行代码。
2、这种封装的方法，一看里边就只有几行代码的居多，本来封装意义不大。而且随着你技术的深入，最后你往往会发现，你的封装还是复杂化了，你最终可能发现封装的方法里，只有一两行代码是有效代码。封装变得没有意义
3、最有害的就是禁锢了你的思想，觉得自己的类库“好用”了，却不知道你觉得的好用只是你现在这个水平下的理解。而因为“好用”，你自然就失去了继续探索.Net类库的动力。在旁观者看来，就是刚学会5%的技术就沾沾自喜，结果是捡个芝麻，丢了个西瓜。
4、同样，这种类库对开发团队也是非常有害的，大家开发了半天，只是熟悉了你的类库，还是很糟糕的类库，而被禁锢在这种
类库上无法脱身，再过一年两年，都没有可能有技术进步。而真相就是，只有团队技术进步了，效率提升了，后面就会获得技术红利带来的好处。

我写框架，都抱着开放的心态，几乎没有Helper类封装，只使用Extend扩展，封装一般只限于业务层面和架构层面。结果是，原来架构的代码，只要充分利用.Net类库的功能，代码量可缩减三分之二，得到的是更干净更灵活的一个框架。

Quote: 引用 4 楼 daixf_csdn 的回复:

不算喷，给你点建议。
看了你的类库，如果是为了学习，做类库无可厚非，可以作为经验的积累，但非常不建议你将类库拿来实用，尤其是这个学习阶段。
我公司里就有这种“架构师”非常热衷于写这种类库，被我严厉批评，这不仅对他人无益，而且对自己也非常有害。
一看这种封装的类库的特征，基本上就是把.Net类库中的已有功能再封装一遍，貌似是更适合自己使用，其实不然。
.1、Net类库具有极其丰富的方法重载，适用于各种不同的使用场景，而你封装了以后，实际上只用到了其中一个重载方法，
而且你未来也再没有机会去了解其他重载的方法。结果是本来能写的很简单的代码，封装以后，写的更加复杂了，因为你会发现
你要么需要不断的封装，要么勉强用现在的封装，然后搭配其他方法来达到你的目的，结果本来使用重载的方法，一行代码能解决的，反而写出了10行代码。
2、这种封装的方法，一看里边就只有几行代码的居多，本来封装意义不大。而且随着你技术的深入，最后你往往会发现，你的封装还是复杂化了，你最终可能发现封装的方法里，只有一两行代码是有效代码。封装变得没有意义
3、最有害的就是禁锢了你的思想，觉得自己的类库“好用”了，却不知道你觉得的好用只是你现在这个水平下的理解。而因为“好用”，你自然就失去了继续探索.Net类库的动力。在旁观者看来，就是刚学会5%的技术就沾沾自喜，结果是捡个芝麻，丢了个西瓜。
4、同样，这种类库对开发团队也是非常有害的，大家开发了半天，只是熟悉了你的类库，还是很糟糕的类库，而被禁锢在这种
类库上无法脱身，再过一年两年，都没有可能有技术进步。而真相就是，只有团队技术进步了，效率提升了，后面就会获得技术红利带来的好处。

我写框架，都抱着开放的心态，几乎没有Helper类封装，只使用Extend扩展，封装一般只限于业务层面和架构层面。结果是，原来架构的代码，只要充分利用.Net类库的功能，代码量可缩减三分之二，得到的是更干净更灵活的一个框架。

公司内有N套项目，扣除一些特定业务逻辑所需要的业务代码外，项目的很多非业务层代码其实很多是有公用需求的，我个人觉得封装一些常用类库来作为公司的整体统一框架Utils也没啥一定对或错说法、也没啥严重到害人害己这类程度。。。毕竟项目开发考虑的基础点首先就不是纯为了技术而技术-----老觉得程序猿多手写一行多一行代码就是牛逼哄哄、自豪感，一个项目开发我们要考虑开发周期、维护成本、团队的高低水平等等。假设像楼主提供的类库md5这个来说团队有10个程序猿，不一定每个人都会懂.net 具体怎么个写法，然后呢，每个人开始造轮子又各自项目各写一套？

你们是大神，我们是小学生。既然我们讨论到了这个话题，那就继续下去
话题是：方法库将以什么形态存在
让公司的项目快速开发时，让自己的程序开发便捷时
让全国码农都学习并使用时，比如thinkPHP
难道你说他们错了么……
我也说不好应不应该提倡类库、框架一说
有的人觉得方便，还有人觉得多此一举也正常不过……
你参与讨论的那一段话，只代表你自己的看法难道不是么……
我完全是抛开REASON而说的……

Quote: 引用 21 楼 sheanjohn 的回复:

你们是大神，我们是小学生。既然我们讨论到了这个话题，那就继续下去
话题是：方法库将以什么形态存在
让公司的项目快速开发时，让自己的程序开发便捷时
让全国码农都学习并使用时，比如thinkPHP
难道你说他们错了么……
我也说不好应不应该提倡类库、框架一说
有的人觉得方便，还有人觉得多此一举也正常不过……
你参与讨论的那一段话，只代表你自己的看法难道不是么……
我完全是抛开REASON而说的……

做一个项目或者产品，框架是必须的，类库也是必须的。关键是大家对类库的理解不同。
我的观念其实是这样：
1、.Net框架做了的事情，我们不需要再做，比如把它们的方法库重新组织后再封装，像你的File，Ini，DateTime等功能，等你真正精通了c#，你会发现.Net已经做到极致了，我已经想不出有任何再封装它的理由，封装它的唯一结果，是弱化它的功能
2、承接第一点，我不赞成通过封装弱化功能。当然有些公司有现实情况，说通过封装降低学习难度，让初级程序员不用思考太多，就能编程，这可能也是一种现实吧
3、我倾向于在.Net框架上进行扩展，多用Extend模式少用Helper模式
4、涉及到框架层面，我同样会封装
5、最后说一个我的准则，我在考虑要封装一个方法时，都会考虑下，.Net框架有没有类似功能？有的话我基本上不会再去封装

虽然我没下载，但估计很烂，或者说没虾米用处——看源文件的文件名就知道个大概了。

Quote: 引用 22 楼 daixf_csdn 的回复:

Quote: 引用 21 楼 sheanjohn 的回复:

你们是大神，我们是小学生。既然我们讨论到了这个话题，那就继续下去
话题是：方法库将以什么形态存在
让公司的项目快速开发时，让自己的程序开发便捷时
让全国码农都学习并使用时，比如thinkPHP
难道你说他们错了么……
我也说不好应不应该提倡类库、框架一说
有的人觉得方便，还有人觉得多此一举也正常不过……
你参与讨论的那一段话，只代表你自己的看法难道不是么……
我完全是抛开REASON而说的……

做一个项目或者产品，框架是必须的，类库也是必须的。关键是大家对类库的理解不同。
我的观念其实是这样：
1、.Net框架做了的事情，我们不需要再做，比如把它们的方法库重新组织后再封装，像你的File，Ini，DateTime等功能，等你真正精通了c#，你会发现.Net已经做到极致了，我已经想不出有任何再封装它的理由，封装它的唯一结果，是弱化它的功能
2、承接第一点，我不赞成通过封装弱化功能。当然有些公司有现实情况，说通过封装降低学习难度，让初级程序员不用思考太多，就能编程，这可能也是一种现实吧
3、我倾向于在.Net框架上进行扩展，多用Extend模式少用Helper模式
4、涉及到框架层面，我同样会封装
5、最后说一个我的准则，我在考虑要封装一个方法时，都会考虑下，.Net框架有没有类似功能？有的话我基本上不会再去封装

我同意你观点，并且也要反驳。
CSS的框架，PHP，甚至JS的框架数不胜数……
bootstrap连菜单都给你定义好了，所有用它默认的方式开发出的前台样式都一样。但是却能通过它编写出不同风格的网站，然而，人们却还乐死不疲的去使用它……
按照你的思路，难道css并不高级，难道CSS本身就很弱化，还是bootstrap把CSS给弱化了……
越深入，越觉得这个话题很有哲理啊，我们应该吃鸡，还是应该吃蛋……
换句话说，是鸡生蛋快，还是蛋孵鸡来的快的问题了……

Quote: 引用 21 楼 sheanjohn 的回复:

最后说一个我的准则，我在考虑要封装一个方法时，都会考虑下，.Net框架有没有类似功能？有的话我基本上不会再去封装

此言有同感。层次吧，每个阶段感受不一样的。

简单的做了个网站，现在可以通过点击链接来下载了……
www.yes-iam.com

Quote: 引用 39 楼 sheanjohn 的回复:

简单的做了个网站，现在可以通过点击链接来下载了……
www.yes-iam.com

域名不错。

楼主可以把这些东西写进一个.h文件里头（封装），添加进编程软件的头文件路径，在进行一些设置，就可以用了。

比如我要写一个test.h

#ifndef _test_h_

int sum(int a,int b){ return a+b; }

#endif  

添进Dev_C++头文件的路径，就可以写出如下代码：
#include <test.h>

int main(){
int a = 5,b = 6,c;
c = sum(a,b);
return 0;
}

我以为分享的是源码，结果是编译好的dll……