question:Why not to have a Int8 and UInt8 types instead of Byte and SByte in .Net framework

You mean SByte and Byte. Int8 would be signed SByte, UInt8 would be unsigned

Byte.

This also highlights the problem: some languages (notably VB.NET) have no

support for unsigned integers (they're not CLS-compliant). On the other

hand, they do all support Byte. Conversely, they don't have to support SByte

(and, predictably, VB.NET doesn't support it). This is one mismatch that

justifies a different type name: integers are mostly signed, bytes are

mostly unsigned, and language support reflects this.

Although you're technically right that a byte is an unsigned 8-bit integer,

it's rarely considered that way, and a signed 8-bit integer is even less

obvious. For example, you don't often perform arithmetic on bytes -- you

copy them around and manipulate their bits. This is another reason why it's

Byte and not UInt8.

Finally, Java started the tradition with byte, and it's no secret that the

CLR was heavily inspired by the JVM. The difference is that .NET actually

got it right by making "byte" unsigned. Java went for a foolish consistency,

eliminated unsigned types altogether, and made programmers' lives miserable

everywhere by forcing them to deal with signed bytes (which complicate code

for the vast majority of cases).

Of course, I didn't work on the CLR, so this is just my justification. I'd

repeat the decision if I were designing the type system.