阔别JR好几年了,没有想到已经沦落到这种地步了,痛心疾首啊。
目前刚刚接管,可能会做些事情,只是还没有思路,现在也没有那么多精力了,唉。
阔别JR好几年了,没有想到已经沦落到这种地步了,痛心疾首啊。
目前刚刚接管,可能会做些事情,只是还没有思路,现在也没有那么多精力了,唉。
看了网上的SandCastle入门,但是我使用的时候还是遇到很多问题。
秉承我的一贯作风写个我的入门指南:
这几天搞.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灯总是闪,最奇怪的是有两个空调,一个房间里面的总是闪,另外一个房间里面的好像没有闪过,从使用时间上算,那个没有闪过的空调更常使用。
搜索了下,百度和KDS上说那个Filter灯是提示该清洗过滤网了,而且如果空调使用过100个小时以后也会自动提示,把过滤网拆下来发现没有什么问题。奇怪。
重置了下,不闪了,但是还是不明白那个灯到底干嘛的,要留意下了。
开始的感觉都还不错,把原来为公司做POC的一个项目拷贝过来修改修改就可以跑了,在本地基本可以用,但是有些问题:
本来打算那个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已经一个多月了,最开始的时候很轻视,因为C#和Java语法相差不多,真正开始写代码开发应用以后才发现很多的不同:
现在还是刚刚对.NET有点感觉,没有被搞得头晕脑胀。
最后说一下,如果不是逼不得已,不要转向.NET,Java乱是乱了点,但是资源是大把大把的,而搞.NET,还是跟紧MS吧。
如果直接引用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就可以了。
希望在脱离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提供 — 向上 ↑