置顶随笔
#
微软的Visual studio从一开始就提供对项目的国际化和本地化的支持。 其核心思想是把本地化信息独立到资源文件里。 Visual studio2003就已经提供支持了， 随着 Visual studio2005 的发布， 微软在对国际化和本地化的支持的实现发生了很大的变化。 对于Windows应用， 简化了资源读取的代码， 原来自动生成的代码一行只读取一个资源属性， 这样读取资源的代码就很多。 虽然这些代码都是有IDE来维护的， 但毕竟使代码不简洁。 Visual studio 2005只需要使用一行代码就将整个控件的所有资源读取完毕， 代码简洁多了。 当然， 对于开发人员来说，这个变化不是很重要， 因为Windows应用的资源都是有IDE来维护的， 不需要开发人员去维护。
对于Web应用， 资源文件的位置和读取都发生了很大的变化。 在Visual studio 2003里， 一个界面文件里会自动生成一个空的资源文件， 但资源信息如何分离到资源文件和将资源信息从资源文件里读出来， 还是需要由开发人员来完成， 这部分的工作量其实还是很大的。
Visual studio 2005改变了这种做法， 首先， 资源文件独立存放在一个叫做App_LocalResources的目录。 并且通过执行Tool.GenerateLocalResource来支持自动分离， 现在的情况是需要一个一个页面的去做，并且需要将页面切换到设计态， 期待下一个版本能够支持批量分离。当然这个分离只是页面资源信息的一个副本，当页面文件里的资源信息被修改时， IDE是不会自动同步的， 还需要在一次手工操作。 这一点与Windows类型的应用是不同的， Windows应用只有一份资源信息， 不存在同步问题。但WEB控件中的资源信息支持自动读取，不需要开发人员在编写任何代码。
Visual studio 2003 提供了对资源文件的基本管理能力， Visual studio2005 则在Visual Studio 2003的基础上， 基本完成了界面元素资源信息的自动分离和读取，当然自动化程序还可以继续提高 ， 还有就是自动分离用户界面的资源信息现在只实现最基本的资源信息的分离，事实上，还有更多的资源信息类型需要分离，比如Web的图片资源等待。
但资源信息不仅仅存在与界面元素中， 同时也存在于代码中， 只不过不象界面文件中那么集中罢了。 但这也是国际化和本地化必须关注的。 还有一个问题是Web应用的一个页面文件中不仅仅包含服务器控件， 同时也包括一些Html元素， 特别是一些标签，一般在设计的时候不会特别的去做成服务器控件。但这些Html元素也包含一些必须分离的本地化信息。现在的Visual Studio 对上述两个资源信息的分离和读取没有提供支持， 是不是后续版本会支持支持， 现在来看， 可能性不是太大。
本地化，国际化与应用的业务应该是无关的， 既然本地化和国际化与业务没有关系， 那么我们是不是可以将业务与本地化分开来开发呢。 答案是肯定的。分开开发， 可以简化整个应用程序的复杂程度， 特别是业务部分的复杂程序，因为业务往往是最复杂的。同时在简化复杂程度的同时， 可以提高效率和质量， 提高软件的可维护性。
如果业务与本地化分开来开发， 首先需要完成业务方面的开发。当然在业务开发时候适当的为本地化和国际化做考虑， 是可以大大简化后面的开发的， 比如不要使用代码动态的创建控件， 特别是创建那些包含本地化资源的控件， 同时建议缺省的资源信息使用英语语言。 一般来说， 绝大部分翻译工具都支持英语和其他语言的互译， 但并不一定支持任意两个语言的互译， 当然如果就只需要两个语言的版本， 这条就无关紧要了。还有就是需要适当的主要控件的布局， 特别是要防止字符显示不全的问题， 因为不同语言下资源需要占用的屏幕区域很可能是不同的， 还需要注意不用使用本地化资源信息作为判断的依据。当然， 实际上需要特别留意的地方还是很小的， 除了不要使用代码创建控件外， 几乎就没有实质的限制了。
按到正常流程开发完一个项目后， 就可以进行国际和和本地化的开发了，国际化和本地化需要完成一系列的工作， 首先需要分离资源， 并适当的修改代码， 并添加不同语言的切换功能。 然后就是需要翻译了， 翻译完了之后， 需要进行整合和测试 ， 如果使用工具来完成的话， 应该说效率会很高， 不需要花费什么精力，也几乎不会引入回归错误。。
既然国际化和本地化需要一系列的步骤， 一个集成的开发工具就显得很有必要了。因为集成的开发工具可以大大的提高效率。
现在市场上的国际化和本地化没有很好的集成开发工具， 对于.Net类型的应用， 早期使用Visual Studio 来进行开发， 然后使用Trdos之类的翻译工具。
集成的国际化和本地化的开发与翻译和分离的本地化开发与翻译工具相比较， 具有如下特点
1： 集成的效率要比分离的效率高很多。首先， 分离的翻译过程， 翻译完后， 需要将翻译好的资源再次进行集成，哪怕是一次很小的修改。 事实上， 一个成熟的软件， 不论是翻译， 还是开发，修改总是频繁的，所以， 集成就会占去很大的一块时间。在本地化和国际化的过程中， 很有可能需要修改原来已经开发好的代码。分离的过程会使这个过程很耗费时间。
2：集成的翻译能够更好的集成资源， 支持即使语言切换。 现在市场的很多产品， 都是以汉化包的形式进行本地化；即使部分软件能够在安装的时候选定语言， 但一旦安装以后， 就不能在进行语言的切换。 包括本地化和国际化工具本身， 都不能轻易的进行语言切换，这实际上是本地化的一个很大的遗憾。
3：集成的本地化和国际化开发需要源代码，与分离的翻译相比，不利于知识产权的保护。 集成的工具， 在翻译过程中， 是可以脱离源文件工作的。
一个集成的.Net国际化和本地化工具， 应该具备如下特性
1： 与Visual studio集成， 并且与Visual Studio保持一致的风格。
2： 必须支持代码文件中资源信息的自动分离。
3： 必须能够集成一系列的翻译功能。
4： 翻译功能应该与Visual Studio 集成。
湛蓝.Net国际化与本地化工具的特征
1： 与Visual Studio的紧密集成。能够直接调用Visual Studio本身的一部分功能。 比如调用Visual Studio自身的界面原始资源的自动分离， 项目的资源文件的管理等功能。
2：能辅助识别代码文件中的资源， 并支持自动分离。 代码文件中的资源信息识别别界面元素中资源信息的识别难度大很多， 事实上是不可能完全自动识别的， 但工具应该能够识别绝大部分的资源， 并且不能漏识， 但可以比实际的多，但识别的准确程度应该很高。 漏识会导致开发人员需要重新阅读代码， 这不可取。 即宁可多识， 也不可漏识。 识别真正的资源后， 需要能够自动将资源分离到资源文件。 自动分离资源到资源文件， 可能会导致代码的修改。 代码的修改量应该最小， 并且不能导致任何可能的错误。
3：提供对缺省资源的修改和统一管理功能，在开发过程中， 经常会出现提示信息和标签文本不正确， 不统一的情况， 并且很有可能也被测试所漏过。到国际化的时候， 就会发现这些问题， 因此， 湛蓝.Net国际化和本地化工具提供了对缺省资源的统一管理， 能够集中的将这些资源呈现在开发人员面前，并提供修改， 替换等快速维护功能。
4：支持Web页面中Html资源信息的自动分离及其他适应性修改。
5：支持语言自动切换功能，这虽然简单但却很重要。
6：集成的资源文件管理。在完成国际化和本地化的过程中， 需要增加很多的资源文件， 这些资源文件应该能够自动集成到Visual Stuaio的项目文件， 并且被工具自动管理。
7： 编码的自动识别及相关的管理。 由于国际化和本地化会涉及到多种不同的语言文化， 也不同的语言文化也会有自己对应的编码规则。 工具应该能够正确识别所有文件中的编码， 并且可以以任意指定编码的来保存。
8： 一个国际化和本地化工具的核心功能是翻译和对翻译的支持。 翻译主要包括翻译的自动化和翻译的准确程度。 当然翻译不可能完全自动化， 但是工具确实需要尽量的提供翻译的自动化和准确的程度。 如何提高翻译的自动化和准确程序， 关键是翻译词库的大小和翻译的智能化程度， 一般好的国际化工具都有自己的词库， 并且有比较好的智能化算法。其实，关于如何提高翻译的自动化和准确程序， 我个人认为， 国际化和本地化工具并不需要在这方面做太多的工作。 因为网络上有很多的免费翻译资源， 比如Google ， Yahoo， 金山， WorldLingo等等， 他们在这方面的投入很大， 应该说做的很专业了。并且软件的本地化和国际化， 一般都是短语翻译，其翻译的准确度应该说是很高的。不过微软的免费翻译资源不支持自动化接口，比较遗憾。 湛蓝国际化和本地化工具就是集成了上述免费的网络翻译资源的，并且做了一些智能化处理。
现在网上的在线翻译工具主要有Google， Yahoo ， Windows Live ， WorldLinq ， KingSoft。Google 应该说是在线翻译做得最好的， 无论是翻译的质量还是支持的语言。 Yahoo相对来说就差一些；Windows Live现在还处于Beta, 暂时不允许自动获取； WorldLingo不支持中文翻译， 也不支持自动获取，所以暂时意义不大。金山和Google使用同一个翻译引擎，翻译结果与Google完全相同， 就不单独讨论了。 现在来看， 在线翻译这一块， Google是最牛的， 应该以Google的翻译作为首选参考，Yahoo可以作为一个候选的翻译资源；Windows Live现在还不完善， 但凭着微软强大的技术实力， 我们有理由认为Windows Live在不远的将来有良好的表现。
现在的版本已经集成了Google， Yahoo， Windows Live， 金山。 WorldLingo暂时还没有。
现在发布的这个版本已经完成了好几个Windows和Web类型的应用， 应该说在已经完成的应用上继续进行本地化国际化改造， 效率是非常高的， 同时操作也很简单。 如有需要的同仁 ， 可以到
http://www.dotnetcoding.net/ResourceCenter/BlueSky.GlobalTool.zip下载
2008年6月5日
#
2008年6月2日
#
微软的Visual studio从一开始就提供对项目的国际化和本地化的支持。 其核心思想是把本地化信息独立到资源文件里。 Visual studio2003就已经提供支持了， 随着 Visual studio2005 的发布， 微软在对国际化和本地化的支持的实现发生了很大的变化。 对于Windows应用， 简化了资源读取的代码， 原来自动生成的代码一行只读取一个资源属性， 这样读取资源的代码就很多。 虽然这些代码都是有IDE来维护的， 但毕竟使代码不简洁。 Visual studio 2005只需要使用一行代码就将整个控件的所有资源读取完毕， 代码简洁多了。 当然， 对于开发人员来说，这个变化不是很重要， 因为Windows应用的资源都是有IDE来维护的， 不需要开发人员去维护。
对于Web应用， 资源文件的位置和读取都发生了很大的变化。 在Visual studio 2003里， 一个界面文件里会自动生成一个空的资源文件， 但资源信息如何分离到资源文件和将资源信息从资源文件里读出来， 还是需要由开发人员来完成， 这部分的工作量其实还是很大的。
Visual studio 2005改变了这种做法， 首先， 资源文件独立存放在一个叫做App_LocalResources的目录。 并且通过执行Tool.GenerateLocalResource来支持自动分离， 现在的情况是需要一个一个页面的去做，并且需要将页面切换到设计态， 期待下一个版本能够支持批量分离。当然这个分离只是页面资源信息的一个副本，当页面文件里的资源信息被修改时， IDE是不会自动同步的， 还需要在一次手工操作。 这一点与Windows类型的应用是不同的， Windows应用只有一份资源信息， 不存在同步问题。但WEB控件中的资源信息支持自动读取，不需要开发人员在编写任何代码。
Visual studio 2003 提供了对资源文件的基本管理能力， Visual studio2005 则在Visual Studio 2003的基础上， 基本完成了界面元素资源信息的自动分离和读取，当然自动化程序还可以继续提高 ， 还有就是自动分离用户界面的资源信息现在只实现最基本的资源信息的分离，事实上，还有更多的资源信息类型需要分离，比如Web的图片资源等待。
但资源信息不仅仅存在与界面元素中， 同时也存在于代码中， 只不过不象界面文件中那么集中罢了。 但这也是国际化和本地化必须关注的。 还有一个问题是Web应用的一个页面文件中不仅仅包含服务器控件， 同时也包括一些Html元素， 特别是一些标签，一般在设计的时候不会特别的去做成服务器控件。但这些Html元素也包含一些必须分离的本地化信息。现在的Visual Studio 对上述两个资源信息的分离和读取没有提供支持， 是不是后续版本会支持支持， 现在来看， 可能性不是太大。
本地化，国际化与应用的业务应该是无关的， 既然本地化和国际化与业务没有关系， 那么我们是不是可以将业务与本地化分开来开发呢。 答案是肯定的。分开开发， 可以简化整个应用程序的复杂程度， 特别是业务部分的复杂程序，因为业务往往是最复杂的。同时在简化复杂程度的同时， 可以提高效率和质量， 提高软件的可维护性。
如果业务与本地化分开来开发， 首先需要完成业务方面的开发。当然在业务开发时候适当的为本地化和国际化做考虑， 是可以大大简化后面的开发的， 比如不要使用代码动态的创建控件， 特别是创建那些包含本地化资源的控件， 同时建议缺省的资源信息使用英语语言。 一般来说， 绝大部分翻译工具都支持英语和其他语言的互译， 但并不一定支持任意两个语言的互译， 当然如果就只需要两个语言的版本， 这条就无关紧要了。还有就是需要适当的主要控件的布局， 特别是要防止字符显示不全的问题， 因为不同语言下资源需要占用的屏幕区域很可能是不同的， 还需要注意不用使用本地化资源信息作为判断的依据。当然， 实际上需要特别留意的地方还是很小的， 除了不要使用代码创建控件外， 几乎就没有实质的限制了。
按到正常流程开发完一个项目后， 就可以进行国际和和本地化的开发了，国际化和本地化需要完成一系列的工作， 首先需要分离资源， 并适当的修改代码， 并添加不同语言的切换功能。 然后就是需要翻译了， 翻译完了之后， 需要进行整合和测试 ， 如果使用工具来完成的话， 应该说效率会很高， 不需要花费什么精力，也几乎不会引入回归错误。。
既然国际化和本地化需要一系列的步骤， 一个集成的开发工具就显得很有必要了。因为集成的开发工具可以大大的提高效率。
现在市场上的国际化和本地化没有很好的集成开发工具， 对于.Net类型的应用， 早期使用Visual Studio 来进行开发， 然后使用Trdos之类的翻译工具。
集成的国际化和本地化的开发与翻译和分离的本地化开发与翻译工具相比较， 具有如下特点
1： 集成的效率要比分离的效率高很多。首先， 分离的翻译过程， 翻译完后， 需要将翻译好的资源再次进行集成，哪怕是一次很小的修改。 事实上， 一个成熟的软件， 不论是翻译， 还是开发，修改总是频繁的，所以， 集成就会占去很大的一块时间。在本地化和国际化的过程中， 很有可能需要修改原来已经开发好的代码。分离的过程会使这个过程很耗费时间。
2：集成的翻译能够更好的集成资源， 支持即使语言切换。 现在市场的很多产品， 都是以汉化包的形式进行本地化；即使部分软件能够在安装的时候选定语言， 但一旦安装以后， 就不能在进行语言的切换。 包括本地化和国际化工具本身， 都不能轻易的进行语言切换，这实际上是本地化的一个很大的遗憾。
3：集成的本地化和国际化开发需要源代码，与分离的翻译相比，不利于知识产权的保护。 集成的工具， 在翻译过程中， 是可以脱离源文件工作的。
一个集成的.Net国际化和本地化工具， 应该具备如下特性
1： 与Visual studio集成， 并且与Visual Studio保持一致的风格。
2： 必须支持代码文件中资源信息的自动分离。
3： 必须能够集成一系列的翻译功能。
4： 翻译功能应该与Visual Studio 集成。
湛蓝.Net国际化与本地化工具的特征
1： 与Visual Studio的紧密集成。能够直接调用Visual Studio本身的一部分功能。 比如调用Visual Studio自身的界面原始资源的自动分离， 项目的资源文件的管理等功能。
2：能辅助识别代码文件中的资源， 并支持自动分离。 代码文件中的资源信息识别别界面元素中资源信息的识别难度大很多， 事实上是不可能完全自动识别的， 但工具应该能够识别绝大部分的资源， 并且不能漏识， 但可以比实际的多，但识别的准确程度应该很高。 漏识会导致开发人员需要重新阅读代码， 这不可取。 即宁可多识， 也不可漏识。 识别真正的资源后， 需要能够自动将资源分离到资源文件。 自动分离资源到资源文件， 可能会导致代码的修改。 代码的修改量应该最小， 并且不能导致任何可能的错误。
3：提供对缺省资源的修改和统一管理功能，在开发过程中， 经常会出现提示信息和标签文本不正确， 不统一的情况， 并且很有可能也被测试所漏过。到国际化的时候， 就会发现这些问题， 因此， 湛蓝.Net国际化和本地化工具提供了对缺省资源的统一管理， 能够集中的将这些资源呈现在开发人员面前，并提供修改， 替换等快速维护功能。
4：支持Web页面中Html资源信息的自动分离及其他适应性修改。
5：支持语言自动切换功能，这虽然简单但却很重要。
6：集成的资源文件管理。在完成国际化和本地化的过程中， 需要增加很多的资源文件， 这些资源文件应该能够自动集成到Visual Stuaio的项目文件， 并且被工具自动管理。
7： 编码的自动识别及相关的管理。 由于国际化和本地化会涉及到多种不同的语言文化， 也不同的语言文化也会有自己对应的编码规则。 工具应该能够正确识别所有文件中的编码， 并且可以以任意指定编码的来保存。
8： 一个国际化和本地化工具的核心功能是翻译和对翻译的支持。 翻译主要包括翻译的自动化和翻译的准确程度。 当然翻译不可能完全自动化， 但是工具确实需要尽量的提供翻译的自动化和准确的程度。 如何提高翻译的自动化和准确程序， 关键是翻译词库的大小和翻译的智能化程度， 一般好的国际化工具都有自己的词库， 并且有比较好的智能化算法。其实，关于如何提高翻译的自动化和准确程序， 我个人认为， 国际化和本地化工具并不需要在这方面做太多的工作。 因为网络上有很多的免费翻译资源， 比如Google ， Yahoo， 金山， WorldLingo等等， 他们在这方面的投入很大， 应该说做的很专业了。并且软件的本地化和国际化， 一般都是短语翻译，其翻译的准确度应该说是很高的。不过微软的免费翻译资源不支持自动化接口，比较遗憾。 湛蓝国际化和本地化工具就是集成了上述免费的网络翻译资源的，并且做了一些智能化处理。
现在网上的在线翻译工具主要有Google， Yahoo ， Windows Live ， WorldLinq ， KingSoft。Google 应该说是在线翻译做得最好的， 无论是翻译的质量还是支持的语言。 Yahoo相对来说就差一些；Windows Live现在还处于Beta, 暂时不允许自动获取； WorldLingo不支持中文翻译， 也不支持自动获取，所以暂时意义不大。金山和Google使用同一个翻译引擎，翻译结果与Google完全相同， 就不单独讨论了。 现在来看， 在线翻译这一块， Google是最牛的， 应该以Google的翻译作为首选参考，Yahoo可以作为一个候选的翻译资源；Windows Live现在还不完善， 但凭着微软强大的技术实力， 我们有理由认为Windows Live在不远的将来有良好的表现。
现在的版本已经集成了Google， Yahoo， Windows Live， 金山。 WorldLingo暂时还没有。
现在发布的这个版本已经完成了好几个Windows和Web类型的应用， 应该说在已经完成的应用上继续进行本地化国际化改造， 效率是非常高的， 同时操作也很简单。 如有需要的同仁 ， 可以到
http://www.dotnetcoding.net/ResourceCenter/BlueSky.GlobalTool.zip下载
2008年5月4日
#
最近由于在做一个国际化的工具，必须要确切知道源代码文件的编码(Encoding)
但是System.Text下面没有相应的Class和Function支持， 虽然读取文件时使用的是System.Io.StreamReader, 但试用了好几个构造器，
System.Io.StreamReader(string Path) , System.IO.StreamReader.New(string path, detectEncodingFromByteOrderMarks)等方法， 有时读出来的还是乱吗，
使用制定的Encoding(System.Text.Encoding.Default,System.Text.Encoding.UTF* )来读文件 ,还是不行。
但VisualStudio总是能正确读出来， 那说明办法总是有的。 在Encoding问题上， 我相信许多程序员都在此花费了不少的精力， 这都要归责于微软， 一是FrameWork应该提供自动检测文件Encoding的支持， 还有就是StreanReader的构造器没有正确实现。既然提供了detectEncodingFromByteOrderMarks参数， 读出来的就不应该是乱码。
好了， 废话不说了， 上网找了一通。 在CodeProject中找到了一个自动检测Encoding的开源类库，不过一试，EncodingTools.DetectInputCodepages读出来的Encoding有时还是不对， 通过跟踪代码， 发现了一个小Bug, 我已经修改了此Bug, 读出来的就对了。 相关源码我将发布在
www.dotnetcoding.net网站上
2008年4月28日
#
我们在进行Web开发时， 经常会遇到需要输入日期， 日期时间和数字的时候， 可惜是的是微软在Visual Studio2005时增加了很多的服务器控件， 可却没有增加Web 类型的数字和日期控件。如果直接采用TextBox， 用户界面即不友好， 同时需要在服务端增加很多不必要的验证代码， 肯定是不可取的。
虽然我们可以采用嵌入Java Script的办法来引导用户输入， 但是需要为每一个数字和日期控件增加Java Script代码， 同时也需要管理各种图片及Java Script 文件， 其实每个数字和日期的设置都是一样的， 即使是在不同的项目里，很是烦恼。 是不是有很好的解决办法呢。
答案是肯定的， 那就是做成Web服务器控件， 分别是Web 日期控件和Web 数字控件。
Web 日期控件和Web 数字控件需要解决一下问题
1： 用户友好。 要有明确的提示引导信息， 操作要方便快捷。 同时不能有太多的限制。
2： 开发友好。 所需要的图片， JavaScript 应该打包到Assembly ， 开发人员不需要去管理这些资源。 同时， 应该支持简单的设计太， 即在设计的时候应该和运行时看到的样子基本一致。
主要的技术：
JavaScript
服务器控件离不开JavsScript；日期控件一般采用弹出Layer的办法来实现， 弹出一个小窗口的办法不好， 主要是弹出一个小窗口的速度慢 ， 有一个明显的等待过程。 弹出Layer 的办法一般是采用PopCalenday.Js, Layer 的Html是采用JavaScript 动态生成的， 其原型应该是一个法国作者，现在网上的Web日期控件大都是在此基础上做少量修改而成的。 由于Layer Html 是采用JavaScript 动态生成的， 因此， 修改的难度比较大。这也是Web 日期控件最核心的技术部分了。
正在表达式
日期控件应该既能选取， 同时也能直接输入， 数字控件一般采用直接输入的方式来实现。日期和数字控件都有特定的格式， 并且这种格式式可以采用正在表达式来验证的。 数字和日期控件应该引导用户按到正确的格式进行输入， 限制不正确的格式输入。
具体实现为在服务端根据属性设置来生成正则表达式， 然后传递到客户端， 客户端根据正则表达式来引导用户输入。
资源嵌入
Web日期控件需要有图片和JavaScript文件的支持；一般的做法式将这些资源放在Web站点特定的目录， 但这样做比较麻烦。微软在Vs2005开始支持资源嵌入，因此， 我们需要将这些资源嵌入到Assembly， 以简化Web 日期数字控件额的部署。
多语言支持
数字和日期的表达形式一般与特定的语言文化联系在一起，因此， 数字和日期控件应该支持多语言。多语言的支持可以考虑如下三种形式， 一是直接指定显示的格式，这样比较简单， 适合于只需要在一种语言文化的环境下使用。 二是根据客户端的的语言文化来决定日期和数字的格式， 这样做比较符合用户的使用习惯。 还有就是根据服务器当前线程的语言文化， 这样做的好处是支持多语言切换。
强类型的值属性
TextBox 只有Text属性， 根据Text属性可以推算出数字和日期的值 ， 但这需要额外的代码， 因此， 服务器控件应该有自己的强类型的值属性； 因为现在Linq已经开始流行， 因此支持Nullable的值类型也就很有必要了。
Web DateBox还应该支持日期时间格式。 虽然日期时间格式不是经常需要， 但作为一个通用的控件， 还是应该支持的。
1： 支持日期控件的图片， Java Script ， CSS等文件全部与DLL一起打包， 因此， 使用本控件库时， 只需要简单的添加引用， 然后就可以从工具箱上拖到Web Form就可以了。
2：数字控件改善了对齐，ClipBoard访问功能
3：全面支持Nullable()属性
4:日期控件不仅支持日期， 同时也支持日期时间格式， 所有辅助文件全家打包到DLL, 支持多种日期格式，
5： 日期控件使用Layer技术， 选取日期时不是弹出一个新的小Page, 而是弹出一个Layer, 与页式日期控件相比，极大的改善了用户友好性。
6： 数字控件采用在服务端自动生成正则表示式的形式
这两个小控件， 能够极大的改善Web application 的开发速度， 同时提供了very cool的用户体验
下载地址 http://www.bluetechchina.com/ResourceCenter/DotNetCodingControls2.0.Zip
g
此新版本只由于使用微软Visual studio2008而发布的一个更新版本
1： 全面采用 FrameWork3.5的技术， 全面支持Visual Studio2008
2: 移除了nHibernate, gentle等第三方ORM代码自动生成的支持。
3：新增了利用Linq技术自动生成应用程序的生成器
2007年7月3日
#
本人准备在10月1日正式公布湛蓝.net应用生成器的所有源码
支持多种日期表示格式
支持长时间日期格式
支持空值表示
详情请访问湛蓝科技主网站(
www.dotnetcoding.net)
支持整型表示
支持正负数表示
支持千分位表示
请访问
湛蓝科技网站
不需要安装windows服务,
不需要对原有的程序代码做任何修改
支持部分更新下载
支持文件压缩
支持安全传输下载
请访问湛蓝科技主网站