解惑

解己之惑,解人之惑

分类:.net (第4页共4页)

看似简单实际很难

这几天搞.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一如既往的失望和鄙视。

从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文件了。

Windows平台应用的运行身份

现在开始做.net的应用了,在Visual Studio里面开发的Web Service直接Debug运行是没有问题,但是publish到IIS以后有问题,在创建的时候出现错误,怀疑是权限问题。
看了下资料,发现IIS应用最终运行的用户是Network Service,而我们的Web Service调用了本地的COM组件,那些组件还会再访问数据库,前面的调用没有问题,但是数据库调用部分就会出错,根据那些资料,有一个所谓的身份模拟的功能,就是说IIS应用最终可以以使用我们的应用的用户身份去调用COM,配置也很简单,在web.config文件的system.web里面添加:
<identity impersonate="true"/>

更新:
这种方式不是非常好,因为会导致传导依赖,以我们自己的项目为例,我们是ASP应用调用另外一个Web Service,那个Web Service再调用我们这个Web Service,如果按照上面配置,那么就得要求有运行COM访问数据库的用户访问ASP,然后ASP以及另外那个Web Service都得配置身份模拟,为了打断这个依赖链条,我们可以在上面的配置的基础上指定一个有COM访问数据库权限的用户,这样其他的应用就不必依赖这个机制了:
<identity impersonate="true" userName="domain\username" password="password"/>

ReSharper不错

ReSharper是JetBrains出品的Visual Studio的插件,秉承JetBrains的一贯风格,ReSharper做得确实很不错,在开发应用的时候的提示功能给人的感觉非常的不错,强烈推荐开发.Net应用的人使用。

愚蠢的Visual Studio

创建了一个Class Library的工程,加了几个类,然后想写个客户端调用编译后的dll,或者直接调,竟然不行,说什么这个类型的工程不能直接运行,如果需要debug,要另外建一个可执行的工程调用这个工程!天哪,STUPID!
visual_studio_error

另外一个简单的情况是,我写一个简单的命令行程序,如果点击运行,那个DOS窗口稍纵即逝,解决方案有:

  1. 在程序的最后加:Console.ReadLine()(这个是网上最流行的答案,包括微软官方网站的教学视频都是使用的这个方式,很多例子也是)
  2. 开一个DOS自己运行编译后的EXE(愚蠢的主意)
  3. 用CTRL+F5运行(这个才是比较可以接受的答案,但是也有副作用,因为这个是不能调试的(Start without debugging),但是相对Java的那些IDE自动截获输出窗口,不得不再骂一句:STUPID)

开始学.NET

我加入EMC本来是做Documentum的SaaS的,所以需要使用Java作为主要开发语言,但是我们的那个项目最终没有立项,现在SaaS的目标改为SourceOne了,而SourceOne是使用.net开发的,我们现在要做一个原型,最快的方法当然也是使用.net开发了,所以我们也就顺理成章的需要学习.net了。
还好我对windows平台并非一无所知,大学以及工作的前半年都在搞vc++和VB,对微软的东西还是有点基础的。
搞了8年的Java,看了两天c#的语法,最初的印象就是c#的语法太杂,虽然c#号称对c++进行了简化,但是我的感觉是完全没有简化,c#只是取消了c++的多重继承、指针以及内存管理,其他的东西并没有减少,相反还有一些新的东西出来,例如事件、对象索引器以及域和属性的分离。另外一个感觉就是c#的保留字太多了,以java的final为例,c#在不同的情况下需要使用readonly,const, sealed等关键字对应。
现在对c#还不是很清楚,需要再看看更好的书学习一下语法方面的精髓,特别是有书能够讲讲为什么那么设计就好了(也许仅仅是为了兼容性?)
最后推荐一个比较好的java和.net的对比的文章。

更新的文章

© 2024 解惑

本主题由Anders Noren提供向上 ↑