我正在尝试使用XmlMassUpdate根据构建版本类型更新我的配置文件.似乎没有关于如何在任何地方更新新的app.config(vs2008)设置格式的文档.
这是配置部分:
<applicationSettings>
<CTC.Mica.ClientService.Properties.Settings>
<setting name="PipeName" serializeAs="String">
<value>\\.\pipe\micaPipe</value>
</setting>
<setting name="CTC_Mica_ClientService_MicaWebService_MicaWebService"
serializeAs="String">
<value>URL</value>
</setting>
</CTC.Mica.ClientService.Properties.Settings>
</applicationSettings>
我正在尝试更新此文件中的URL值:
<Debug>
<setting xmu:key="name" name="CTC_Mica_ClientService_MicaWebService_MicaWebService" serializeAs="String">
<value>DEVURL</value>
</setting>
</Debug>
<Test>
<setting xmu:key="name" name="CTC_Mica_ClientService_MicaWebService_MicaWebService" serializeAs="String">
<value>TESTURL</value>
</setting>
</Test>
<Release>
<setting xmu:key="name" name="CTC_Mica_ClientService_MicaWebService_MicaWebService" serializeAs="String">
<value>LIVEURL</value>
</setting>
</Release>
运行脚本,我可以替换"name"或"serializeAs"属性,但不能替换值节点.
我将如何更换价值节点？
问候
三
每个人都在说如何用WCF取代.NET Remoting,但我想知道它是多么准确.我还没有看到任何关于Remoting被弃用的官方消息,在我看来,Remoting肯定比WCF更有意义.即使在框架的4.0版本中,也没有弃用与Remoting相关的对象或方法.我的理解是3.5和4.0框架中的System.AddIn使用Remoting.
有没有人有任何相反的官方消息？
在文章" 选择.NET中的通信选项(3.0版,因为那是该文章的最新版本)"中,它指出:
8跨应用程序域通信
如果需要在同一进程中支持不同应用程序域中的对象之间的通信,则必须使用.NET远程处理.
现在,这当然不准确,因为WCF当然可以用于跨越appdomain边界,但它是否正在为该场景提供官方建议？
更新:我发送了Clemens Vasters(谁是拥有Remoting和WCF的团队)这个问题:
Clemens,我知道你是拥有远程控制和wcf的团队,我有几个问题,我认为我需要去找源代码.
首先,我有一个关于远程处理是否会消失的问题.具体来说,我们有一个相当大的应用程序,它广泛使用远程处理进行跨域appdomain通信,我想知道远程处理的这种用法是否被认为是"遗留".如果是这样,AppDomain.CreateInstance和朋友会被其他东西取代吗？
这是他的回复:
远程处理是.Net框架的一部分,因此它不会消失.自Windows NT 3.5/Windows 95以来,COM一直在Windows中,并且还没有消失,我也不认为它会很快消失.
也就是说,Remoting的开发投资非常少.WCF是Remoting的继承者,并取代了托管代码的COM/DCOM.
对于进程内,跨域应用程序通信远程处理是CLR的本地通信方式.如果您发现在短时间内抽取大量数据或大量消息的性能问题,您应该认真考虑WCF和NetNamedPipeBinding.
我有一个包含10张图像的页面,我想在下载图像后一个接一个地淡出它们.如何检测图像已加载并准备显示？我应该循环加载图像fadeIn和fadedIn等待下一次加载吗？
我正在尝试在C#中使用AttachmentCollection类,当我尝试创建它的新实例时,它给出了一个错误,说"错误32类型'System.Net.Mail.AttachmentCollection'没有定义构造函数"....这是我正在尝试的,如果没有定义构造函数,如何创建一个新的实例？
AttachmentCollection attachmentCollection = new AttachmentCollection();
谢谢你的帮助!
我有一个对象,其中包含一个通用的IList,它从WCF Web服务方法返回:
[DataContract(Name = "PageableList_Of_{0}")]
public class PageableResults<T>
{
[DataMember]
public IList<T> Items { get; set; }
[DataMember]
public int TotalRows { get; set; }
}
[OperationContract]
PageableResults<ContentItem> ListCI();
当我在服务上调用此方法时,它会很好地执行整个方法,但最后它会抛出System.ExecutionEngineException而不会发生InnerException.我已经尝试返回一个具体的List <>对象,这似乎有效,但不幸的是我需要找到一个解决方法来返回一个IList.我需要输入任何属性来解决这个问题吗？
我的代码的先前版本之一,存储在Subversion存储库中,有敏感信息.如何在保留所有其他版本的同时擦除它？
编辑:存储库是谷歌代码项目托管,所以我无法转储和恢复存储库=(
我将在一段时间内扮演一个魔鬼的拥护者.我一直在想为什么浏览器检测(与特征检测相反)被认为是一种不好的做法.如果我测试某个版本的某个浏览器并确认,某个功能的行为是以某种可预测的方式进行的,那么决定做特殊情况似乎没问题.原因在于它将来会万无一失,因为这部分浏览器版本不会改变.另一方面,如果我检测到DOM元素具有函数X,则不一定意味着:
我只是偷看了jQuery源代码,他们通过在DOM中插入一个精心构建的HTML片段然后检查它的特定功能来进行特征检测.这是一种明智而坚实的方式,但我会说,如果我在我的小小的个人JavaScript(没有jQuery)中做了类似的事情,那将会有点太沉重.它们还具有几乎无限的QA资源的优势.另一方面,你经常看到人们做的是他们检查函数X的存在,然后基于此,他们假设函数将在具有此函数的所有浏览器中以某种方式运行.
我没有说任何意义上的功能检测不是一件好事(如果使用得当),但我想知道为什么浏览器检测通常会立即被解雇,即使它听起来合乎逻辑.我想知道这是否是另一个时髦的事情.
我在我的应用程序中使用的导出工具的任务之一是清理.svn应用程序目录树中的所有目录.我在Linux shell中寻找一个递归命令,它将遍历整个树并删除.svn文件.
我没有使用导出,因为此脚本将用于与SVN无关的其他文件/目录名称.我尝试过类似的东西:
find . -name .svn | rm -fr
它不起作用......