解惑

解己之惑,解人之惑

作者:cherami (第18页共82页)

重新接管JR

阔别JR好几年了,没有想到已经沦落到这种地步了,痛心疾首啊。

目前刚刚接管,可能会做些事情,只是还没有思路,现在也没有那么多精力了,唉。

SandCastle使用入门

看了网上的SandCastle入门,但是我使用的时候还是遇到很多问题。
秉承我的一贯作风写个我的入门指南:

  • 下载SandCastle并安装
  • 设置系统环境变量DXROOT指向SandCastle安装的目录,默认是C:\Program Files\Sandcastle\
  • 把SandCastle的productiontools加到系统环境变量PATH里面%DXROOT%\productiontools;
  • 把SandCastle的example的bat文件拷贝出来备用:C:\Program Files\Sandcastle\Examples\sandcastle\build_Sandcastle.bat,建议把bat重命名为generate_chm.bat
  • 如果你使用Visual Studio,那么修改工程的属性,把Build的Output中的XML Documentation File勾中,如果没有使用Visual Studio,那么可以使用csc命令生成这个XML文件 csc /doc:Xxx.xml Xxx.cs,如果编译依赖其他的东西,也需要在命令行中提供。
  • Build工程,把Build生成的bin下的所有内容(debug或者release),注意是所有内容拷贝到其他的新建的目录下,然后把generate_chm.bat也拷贝过去,然后在DOS下进入那个目录: generate_chm vs2005 Xxx。不要直接在Visual Studio的工程下面运行,一个是生成很多中间的目录和文件,二是好像影响正常生成(我开始都是在Visual Studio下弄的,总是不成功)。

看似简单实际很难

这几天搞.NET最大的感受就是看似简单实际很难
先说MSBuild,我们要做Daily Build,看了下文档,好像Visual Studio的编译也是基于MSBuild,所以Daily Build应该很简单,在开发环境下用MSBuild调用Solution的配置文件,顺利完成,但是到了Daily Build的环境下就不行了,我们用的TeamCity,TeamCity也是看似支持MSBuild和Visual Studio Solution2008,但是如果选用那些Runner会提示没有可用的Agent,不得已先用Command Line的方式直接调用MSBuild,基本可行,但是我们有MSTest的Project,这个Project不能编译,复制了份sln文件,把MSTest的工程去掉了,正常过了没有问题,后来仔细看了下,发现那些Installer的工程没有编译出结果,又不支持。下载了个Wix,发现也很麻烦,因为我们的工程师Web的工程,Installer不光要配置需要的文件,还得安装到IIS中去。最后放弃,目前就只是编译整个工程,不做Unit Test和生成Installer。发现TeamCity对第三方的东西反倒支持得更好(NAnt, NUnit)。
再说API Doc,看书的时候说也支持自动文档,我想应该也是抄袭的JavaDoc吧,应该很简单,今天实际一搞,发现不一样,SDK只能帮你生成XML格式的文档,这个没有办法看,然后看了下,说有开源的工具是NDoc,下载了下,发现不支持.net2.0以上版本,仔细一看,2005年就停止开发了,又搜索了下,发现MS自己有个SandCastle,可以生成CHM格式的文档,试了下,一堆的错误,没有心情搞了。

对MS一如既往的失望和鄙视。

Sharp空调的Filter灯一直闪

家里的空调是Sharp的,不是我自己买的,而是买房子的时候房东的,听说还不错,就没有换。
不过有个问题,就是那个Filter灯总是闪,最奇怪的是有两个空调,一个房间里面的总是闪,另外一个房间里面的好像没有闪过,从使用时间上算,那个没有闪过的空调更常使用。
搜索了下,百度和KDS上说那个Filter灯是提示该清洗过滤网了,而且如果空调使用过100个小时以后也会自动提示,把过滤网拆下来发现没有什么问题。奇怪。

重置了下,不闪了,但是还是不明白那个灯到底干嘛的,要留意下了。

GAE+ ZK没有那么成熟

开始的感觉都还不错,把原来为公司做POC的一个项目拷贝过来修改修改就可以跑了,在本地基本可以用,但是有些问题:

  • 添加修改数据的窗口不能用Modal窗口,错误消息是:Event processing thread is disabled(这个是因为ZK+GAE本来就需要把事件线程disable掉,因为GAE里面不能开线程)
  • 把Modal窗口修改成Popup窗口,本地是好的,但是上传到GWT没有反应也没有报错。

电信开始恶心人了

今天Robbin说电信插播全屏广告,我以前也碰到过,但是没有截屏过,刚好今天回来就遇到了。打开FF后刷新我的BLOG,结果:
电信插播全屏广告

经验也会帮倒忙

本来打算那个Notes-all用Google的全套解决方案的,就是用GWT + Google App Engine,看了下GWT的Sample,发现还是比较麻烦,但是感觉思路和ZK还是很像的,就打算比较下GWT和ZK,结果发现有人说可以把ZK成功发布到Google App Engine,试了下,果然是可以的,有兴趣的可以试试(在ZK网站可以下载zk-gae的sample,基于这个很容易建立自己的工程)。
基于我玩过一段时间的ZK,当然用ZK更方便了。
今天把原来的东西复制过去了,在做国际化的时候,用Eclipse编辑properties文件,里面有中文,不能保存,只能保存ISO-8859-1编码的内容。后来想着应该装个插件,下载了,好使,但是运行起来发现并没有把转码的内容显示为正确的中文,很奇怪。后来怀疑ZK读取properties文件的时候和Java读取国际化文件不一样,把properties文件的编码修改为UTF-8,然后直接用文本编辑器输入中文内容,运行测试,正常!
这个就是一般的国际化处理的经验造成的问题。
最后说一下,对ZK的这个违反Java惯例的方式赞一下,因为我一直对Java的这个需要把properties国际化文件用native2ascii转换的过程很鄙视,不知道谁这么设计的。ZK是以UTF-8读取properties文件的,不做任何转换。

更新:
可以修改Eclipse,让它对properties文件不强制使用ISO-8859-1编码保存:
eclipse –> window –> Preferences –> General –> Content Types –> Text –> 单击 Java Properties File,把底部的Default edcodng从ISO-8859-1改成utf-8,然后update。

从Java转向.NET需要注意的问题

从Java转向.NET已经一个多月了,最开始的时候很轻视,因为C#和Java语法相差不多,真正开始写代码开发应用以后才发现很多的不同:

  • 开发工具几乎没得选:Visual Studio,既然用了MS的东西就得都用,否则遇到问题很难得到帮助,因为别人都是用的这一套。
  • Visual Studio给你封装了很多东西,有些开发因此变得很容易,但是也因此不能很灵活可控。而且你很难也往往不需要知道很多底层细节(例如写Web Service的客户端程序,添加一个Service ReferenceVS就会生成代码,根本不需要懂SOAP的细节)。
  • 你需要了解Windows平台的很多东西,例如安全机制,ODBC,Profile等等,而Java是跨平台的,这些配置以及安全等等都是作为jar包的方式引用和使用的,根本不应该依赖Windows内置的机制。
  • .NET有时候会使用很多遗留的东西,例如DLL,COM,而且因为版本不一样不见得好用,而Java比较简单,几乎只有jar,虽然也有版本问题,但是要知道jar里面包含那些类还是很容易的,但是DLL和COM之类的就很麻烦,似乎没有很好的工具帮助你查找哪个DLL或者COM有你需要的类。

现在还是刚刚对.NET有点感觉,没有被搞得头晕脑胀。

最后说一下,如果不是逼不得已,不要转向.NET,Java乱是乱了点,但是资源是大把大把的,而搞.NET,还是跟紧MS吧。

单元测试以Windows集成方式认证的Web Service

如果直接引用Web Service写单元测试,运行以Windows集成方式认证并且不允许匿名访问的Web Service,那么运行的时候会报错,因为权限不够,可能是因为Visual Studio在运行的时候是以匿名用户的身份运行的,而非OS的用户身份,这样的情况需要写些代码来使用OS的用户身份:
        [TestInitialize]
        public void SetUp()
        {
            var basicHttpBinding = new BasicHttpBinding();

            basicHttpBinding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;

            basicHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;

            var endpoint = new EndpointAddress("http://localhost/IntegrationService/IntegrationService.asmx");

            _client = new IntegrationServiceSoapClient(basicHttpBinding, endpoint);
            _client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;

            _client.ChannelFactory.Credentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
        }
代码中的EndpointAddress和IntegrationServiceSoapClient要换成你自己的Web Service的对应内容。

更新:
如果按照 Windows平台应用的运行身份的更新中所说的指定用户,那么这里的单元测试就不需要这样麻烦了,直接new一个Client就可以了。

MSBuild没有那么难

希望在脱离Visual Studio的情况下也可以编译我们的.Net工程,根据网上的资料发现MSBuild可以使用sln和*.*proj文件,而sln就是Visual Studio的Solution文件,而每个project都有一个csproj文件,最开始的时候使用MSBuild编译发现不行,说MSBuild支持的文件版本不对,后来发现MSBuild配置的路径是.Net2.0.5的路径,而我们现在使用的其实是3.5版本的.Net,修改MSBuild的路径后发现可以了。
所以如果使用Visual Studio创建的工程,其实它就是用的MSBuild在进行Solution和Project的编译,不用自己再手工写build文件了。

更早的文章 更新的文章

© 2025 解惑

本主题由Anders Noren提供向上 ↑