所以看起来
.NET performance counter type有一个令人讨厌的问题：它暴露了很长的计数器RawValue,而windows中的实际perf计数器值是无符号的,不能为负数.例如,如果您有一个NumberOfItems64计数器API将非常高兴接受一个负值,然后将其静默地转换为一个非常大的数字.事实上,在计数器的一半值范围内,设置它的唯一方法是找到正确的负值传入！
我假设这里发生的是他们从长处获取原始位,并将其视为无符号的64位数字.来自二进制补码的负值只是作为计数器的直线数字读取.
所以我试图弄清楚如何强制C#,只是将ulong直接放入长时间,因为这就是API所要的.但是C#在这里太有用了…你不能使用Convert.ToInt64(ulong)来抛出溢出异常,因为它的值太大了.我以这种转换方式偶然发现：
Convert.ToInt64(myULong.ToString(“X”),16)
当它从非基数10中的字符串转换时,它假定数字是二进制补码,并且我需要它.但是这不是理想的,因为它需要为每个转换分配一个对象并解析一个字符串,这个API将是性能关键的.在C#中有更好的方法吗？
解决方法
一个简单的演员像
ulong value1 = 0xFEDCBA9876543210UL; // 18364758544493064720 long value2 = (long)value1; // -81985529216486896 ulong value3 = (ulong)value2; // 18364758544493064720
保留数值中的位.
