添加到.NET 4 的ExpandoObject类允许您在运行时任意设置对象的属性.
使用a Dictionary<string, object>或者甚至是Hashtable有什么优势吗？据我所知,这只是一个哈希表,您可以使用稍微简洁的语法访问.
例如,为什么这样:
dynamic obj = new ExpandoObject();
obj.MyInt = 3;
obj.MyString = "Foo";
Console.WriteLine(obj.MyString);
真的比以下更好,或者大不相同:
var obj = new Dictionary<string, object>();
obj["MyInt"] = 3;
obj["MyString"] = "Foo";
Console.WriteLine(obj["MyString"]);
使用ExpandoObject而不是仅仅使用任意字典类型可以获得什么真正的优势,除了不明显你正在使用将在运行时确定的类型.
.NET的一个好的混淆器工具有哪些选项可以支持.NET 4.0中的WPF？
特别是,哪些混淆工具处理WPF程序集中的BAML重写,并处理BAML中的跨程序集引用？
虽然大多数混淆器列出了"WPF"和".NET 3.5"或".NET 4"支持,但实际上,它们无法重写嵌入式BAML引用,导致使用WPF的跨程序集调用被不正确地处理.这可以防止它们在大规模WPF应用程序中使用.
我理解并欣赏.NET框架中System.WeakReference类的用处,但我对实现细节很好奇.
WeakReference是如何在.NET中实现的？MSDN详细讨论了WeakReference的用法,但是我已经看到了一些关于它如何工作的细节.
CLR如何跟踪引用并知道在收集目标时将内部句柄清空,而不会阻止GC？它是否需要CLR本身的特殊处理？
我主要担心的是,使用WeakReferences(特别是如果使用其中许多)与使用标准对象引用时的性能有关.
.NET框架完全支持部分类,接口和方法.有没有令人信服的理由支持部分构造函数没有以同样的方式添加？
这似乎会简化部分类中的类构造.例如,由Windows Forms中的设计者构建的表单构造函数可以直接在构造函数中使用表单构造代码,并将其拆分为两个文件.部分"Initialize()"方法似乎是一种有点常见的模式,在这种情况下可以简化.
我能看到的唯一潜在缺点是构造函数调用顺序缺乏确定性,但在许多情况下,部件的顺序无关紧要.如果是这样,你总是可以避免部分构造函数.
对于我当前的项目,我们使用了一些基于CLR 2的混合模式程序集.
为了在.NET 4目标程序集中使用这些,我知道你必须添加useLegacyV2RuntimeActivationPolicy=true到<startup>app.config中的元素.
据我所知,这会更改激活策略,导致使用CLR支持的最高版本加载这些混合模式程序集.
但是,这样做会有副作用吗？启用非默认激活策略时,我应该注意哪些潜在问题？
我正在尝试在两个字符串列表上实现自定义比较器,并使用.Except()linq方法来获取那些不是列表中的一个.我正在做自定义比较器的原因是因为我需要进行"模糊"比较,即一个列表上的一个字符串可以嵌入到另一个列表中的字符串中.
我做了以下比较
public class ItemFuzzyMatchComparer : IEqualityComparer<string>
{
bool IEqualityComparer<string>.Equals(string x, string y)
{
return (x.Contains(y) || y.Contains(x));
}
int IEqualityComparer<string>.GetHashCode(string obj)
{
if (Object.ReferenceEquals(obj, null))
return 0;
return obj.GetHashCode();
}
}
当我调试时,唯一的命中断点是在GetHashCode()方法中.Equals()永远不会被触及.有任何想法吗？
.NET中的受保护或私有(非静态)事件真正起作用的目的是什么？
似乎任何私有或受保护事件都可以通过虚拟方法更轻松地处理.我可以(有点)在静态事件中看到这个需要,但不能用于正常事件.
您之前是否有过一个用例,可以清楚地表明非静态保护或私有事件的需要或优势？
正确实现IDisposable时,大多数实现(包括框架指南)都建议包含一个private bool disposed;成员,以便安全地允许多次调用Dispose(),Dispose(bool)并在适当时抛出ObjectDisposedException.
这适用于单个类.但是,当您从可支配资源中继承子类,并且子类包含其自己的本机资源和唯一方法时,事情会变得有点棘手.大多数示例都展示了如何Dipose(bool disposing)正确覆盖,但不要超出处理范围ObjectDisposedException.
在这种情况下,我有两个问题.
第一:
子类和基类都需要能够跟踪处置状态.我知道有几个主要选项 -
1)声明私人布尔处置; 在这两个班级.每个类跟踪它自己的this.disposed,并根据需要抛出.
2)使用protected bool Disposed {get; 私人集; 而不是一个字段.这将让子类检查处置状态.
3)提供一些受保护的辅助方法来检查处理状态,如果对象被处理,则通过反射拉动当前类型名称来抛出.
我看到每个选项的优点是:
1)这对我来说"闻到",因为它包含重复的布尔值,但似乎工作正常.我经常在子类化其他代码时使用它.
2)这取出了重复的布尔值,但不是设计指南书的编写方式等.这是我通常使用的,因为它使状态保持单一点.
3)这对我来说似乎是最干净的选择,但没有出现在标准指南中.对于来自该类用户的其他方法,可能对方法的预期稍差.
在某些方面,我尝试过使用这三种方法.我想知道这三种方法的优点和缺点,以及任何其他想法,以更清洁,更好的方式来处理这个问题.你在处理这个问题时会做出什么选择？为什么？
第二:
抛出时ObjectDisposedException,你对name参数使用了什么？我知道"典型"方法调用是:
throw new ObjectDisposedException(GetType().FullName);
Microsoft员工在此页面上发表评论,建议实施具体类的全名是适当的用法.
在上面的第三个选项中,这将是唯一有意义的选择.但是,如果类实现了throw本身,则可能会返回定义被调用方法的类的名称.(即:基类可以返回基类的名称,而不是具体的子类)
我认为这不是一个好主意 - 但我在其他人编写的代码上遇到了这个问题.使实现方法的类的名称返回有优缺点吗？
在64位JIT和32位JIT下运行.NET应用程序时,在性能,内存等方面出现了不寻常的意外后果？我对好事感兴趣,但对人们遇到的令人惊讶的糟糕问题更感兴趣.
我正在编写一个新的.NET应用程序,它将部署在32位和64位.关于移植应用程序的问题有很多问题 - 从编程/移植的角度来看,我并不关心"陷阱".(即:正确处理本机/ COM互操作,嵌入在结构中的引用类型,更改结构的大小等)
然而,这个问题和它的答案让我思考 - 我还有什么其他问题可以忽略？
有很多问题和博客文章绕过这个问题,或者涉及到它的一个方面,但我还没有看到任何编制了一个很好的问题清单.
特别是 - 我的应用程序非常受CPU限制并且具有巨大的内存使用模式(因此首先需要64位),以及本质上是图形化的.我关心在64位Windows上运行的CLR或JIT中可能存在的其他隐藏问题(使用.NET 3.5sp1).
以下是我目前了解的一些问题:
我想知道人们在64位Windows上的JIT中发现了哪些其他具体的问题,以及是否有任何性能方面的解决方法.
谢谢你们!
- - 编辑 - - -
只是为了澄清 -
我知道尝试早期优化通常很糟糕.我知道第二次猜测系统通常很糟糕.我也知道64bit的可移植性有其自身的问题 - 我们每天在64位系统上运行和测试以帮助解决这个问题.等等
但是,我的应用程序不是典型的业务应用程序.这是一个科学的软件应用程序.我们有许多流程可以在所有核心(高度线程化)上使用100%CPU,每次数小时.
我花了很多时间来分析应用程序,这会产生巨大的差异.但是,大多数分析器都会禁用JIT的许多功能,因此当您在分析器下运行时,内存分配,JIT中的内联等小细节可能很难确定.因此我需要这个问题.
如何正确的代码提供给一个ProvidedConstructor的InvokeCode在生成型提供商,其会做以下的相同呢？
鉴于:
module Utils =
let someFun (s : string) (inst : obj) =
// Does something here...
()
我需要有效地生成类型:
type NewGeneratedType () as self =
inherit BaseType ()
do
Utils.someFun "Foo" (box self)
我调用基础构造函数,但不知道如何在实例中正确切片并获取调用的函数:
let ctor = ProvidedConstructor([])
let ci = baseType.GetConstructor(BindingFlags.Public ||| BindingFlags.Instance, null, [| |], null)
ctor.BaseConstructorCall <- fun args -> ci, args
// I do not know how to properly call this to match the constructor above
ctor.InvokeCode <- fun args -> …