clr

Literals and implicit narrowing conversions

怎甘沉沦 提交于 2020-01-04 17:51:50
问题 a) Shouldn’t the following assignment cause an error, since number 100 is a literal of type int and since compiler doesn’t allow implicit narrowing conversions? byte b = 100; b) If compiler doesn’t complain about implicit narrowing conversion from int literal to type byte , then why doesn’t it also allow an implicit narrowing conversion from double literal to type float ( I realize we could avoid this error by specifying float literal using F/f suffix )? byte b=16; //OK float f1=16.9; //error

Mixing .NET 3.5 with 4/4.5 assemblies in the same solution/project

↘锁芯ラ 提交于 2020-01-04 12:42:10
问题 I have a solution that most projects are compiled in .net 4.5 (I use async and tasks). There are couple of projects that need to be compiled in .net 3.5 since they use SDK that support only .net 3.5. If my "Common" project is compiled in 4.5, and I have a project with target framework 3.5 that needs it, Is it possible to add reference to the Common ? (e.g my logger interface is at Common and i get it with DI). Thanks. Output: could not be resolved because it was built against the "

.net runtime 2.0 instead of the newest version?

二次信任 提交于 2020-01-04 09:16:08
问题 On my computer I have installed .NET Framework 2.0 then later .NET Fratmeworkt 3.0. However recently i get an exception from one program saying "Event 1000, .NET Runtime 2.0 Error Reporting". I'm wondering, why this program is still using .NET Runtime 2.0 instead the new version. How could I check which version of .NET Runtime a specific program uses? Is possible to change it? 回答1: The ".NET runtime" actually means the "Common Language Runtime" (CLR), which has been version 2.0 for the .NET

Favour Verbose Linq expressions?

一个人想着一个人 提交于 2020-01-04 07:59:05
问题 It occurred to me that I write out linq statements in a simple, but what others may define as verbose manner; A simple example: return _entries .Where(x => x.Context.Equals(context)) .Where(x => x.Type == typeof (T)) .Select(x=>x.Value) .Cast<T>() .Single(); can be simplified to: return _entries .Where(x => x.Context.Equals(context) && x.Type == typeof (T)) .Select(x=>(T)x.Value) .Single(); [Question] In the long run, which is the better coding practice? i.e. long (and simple) linq chains or

Calculating file offset from RVA in .NET Assembly

笑着哭i 提交于 2020-01-04 06:24:10
问题 I'm trying to calculate the CLI Header file offset using the optional header, I manually checked a sample .NET Assembly and noticed that the optional header gives me the RVA for the CLI Header which is 0x2008 and the file offset of the CLI Header is 0x208 . How can I calculate the file offset from the RVA? Thanks. 回答1: The PE file contains a bunch of sections that get mapped to page aligned virtual addresses using the section table (just after the optional header). So to read the CLI Header,

Why is creating a new thread expensive?

霸气de小男生 提交于 2020-01-03 17:10:19
问题 I read lots of .Net resources telling me that I should be using a thread pool thread rather than instantiating a new thread myself. They say you should do this because instantiating a new thread is an expensive operation. What happens during thread creation that makes it an expensive operation? 回答1: Everything is relative. Creating a new thread is expensive... relative to not creating one. If you're not doing a lot of work per thread, the work involved in building and tearing down the threads

Compiler evaluation of explicit null-check vs. null-coalescing operator?

五迷三道 提交于 2020-01-03 16:24:51
问题 Consider the following code, which uses two slightly different methods to check _instance and assign it when not already set. class InstantiationTest { private Object _instance; public void Method1() { if(_instance == null) { _instance = new Object(); } } public void Method2() { _instance = _instance ?? new Object(); } } Either VS or Resharper keeps underlining my explicit null checks, and prompting me to refactor using the null-coalescing operator. I wondered whether the compiler is smart

x64 .NET compilation / Process Explorer oddity

谁说胖子不能爱 提交于 2020-01-03 14:43:29
问题 Apologies if any of what I'm about to say makes no sense or overlooks something obvious - my knowledge of CLR internals is spotty. If I understand correctly, then if I just build a solution for 'AnyCPU' in VS2K5 (or point MSBuild at that .sln file with those settings) then the binaries only compile as far as MSIL. They then get JITted to 32-bit if executed on a 32-bit platform or 64-bit code if executed on x64...right? The DLLs are used for a web app and hosted in the W3WP.exe process.

Compiler Version vs. NET Framework Version - Scenario with ASP.NET applications

核能气质少年 提交于 2020-01-03 13:35:30
问题 Scenario: I have VS 2010 (C# 4 compiler) targeting 3.5 on my client machine. I am developing ASP.NET applications. I use optional parameters (C# 4 supported) in a class file and compile the code everything appears to work fine. Later on an issue that is discovered at Runtime where an old (classic I believe) ASPX is using the function. No function accepts only x arguments where x is one less than the optional parameter is the runtime error. Does this mean normal classes and such use the C#

Effect of properties or get/set methods on object size

时光毁灭记忆、已成空白 提交于 2020-01-03 10:21:17
问题 In terms of object size, how do properties instead Get/Set methods affect object size if the exposed properties do not represent a state but simply delegate its getter and setter calls to another entity? For example, consider the following classes: public class Person { Address _address = new Address(); public string AddressName { get{ return _address.Name; } set { _address.Name = value; } } public string GetAddressName(){ return _address.Name; } public void SetAddressName(string name){