The various levels of /CLI

[Peter Oliphant]

My program works great in 'vanilla' /CLI, so I tried both '/CLI pure' and
/CLI 'safe'. My program continues to compile and run fine in 'CLI pure' (I
also use error level 4 and don't even get warning errors), but generates
almost 400 compile time errors in '/CLI safe'.

So, more out of curiosity, what are the advantages and disadvantages to each
'level' of /CLI? Since mine will compile and run in '/CLI pure' what am I
'getting' I wouldn't get if it only worked under 'vanilla' /CLI? Since my
program doesn't compile as in '/CLI safe', what am I not 'getting' because
of this?

Thanks in advance for responses!

[==Peter==]

[=?Utf-8?B?Y29kZWthaXplbg==?=]

"Peter Oliphant" wrote:

Since my
program doesn't compile as in '/CLI safe', what am I not 'getting' because
of this?

CLI / Safe means that the resulting program is pure managed (only containing
IL instructions, and no native CPU instructions), which is the same as CLI /
Pure. The "extra" thing Safe adds is that the program is _verifiable_ by the
runtime.

Verifiable code has certain advantages because it can be proven that claims
about types and methods are always true. In unsafe code, you can't verify
that a program won't access a type or memory location in a way that it wasn't
designed to do, and therefore may have unpredictable effects. Native code is
inherently unverifiable (since the runtime can only prove IL code compiled by
the JIT [or NGen'd]), and pointers are also unverifiable (since you can do
arbitrary arithmetic on them). Other languages which target the runtime (C#
and VB) produce verifiable code by default or even exclusively. C++/CLI is
much harder to do this with, and in my opinion isn't well suited for this
task - native / managed interop is by far its greatest strength.

The big "loss" is that you have to run your app in "fully trusted" mode,
which means that the code gets all the privileges the current logon session
has been granted. If it were verifiable, it could also be made to run in a
"partially trusted" mode, which gives the code less privileges than the logon
session, making the system more secure, and therefore potentially useful in a
wider variety of scenarios, such as from a partially trusted website.

[Peter Oliphant]

Cool! Thanx, codekaizen! :)

[==Peter==]

"codekaizen" <co********@discussions.microsoft.comwrote in message
news:35**********************************@microsof t.com...

>

"Peter Oliphant" wrote:

>Since my
program doesn't compile as in '/CLI safe', what am I not 'getting'
because
of this?

CLI / Safe means that the resulting program is pure managed (only
containing
IL instructions, and no native CPU instructions), which is the same as CLI
/
Pure. The "extra" thing Safe adds is that the program is _verifiable_ by
the
runtime.

Verifiable code has certain advantages because it can be proven that
claims
about types and methods are always true. In unsafe code, you can't verify
that a program won't access a type or memory location in a way that it
wasn't
designed to do, and therefore may have unpredictable effects. Native code
is
inherently unverifiable (since the runtime can only prove IL code compiled
by
the JIT [or NGen'd]), and pointers are also unverifiable (since you can do
arbitrary arithmetic on them). Other languages which target the runtime
(C#
and VB) produce verifiable code by default or even exclusively. C++/CLI is
much harder to do this with, and in my opinion isn't well suited for this
task - native / managed interop is by far its greatest strength.

The big "loss" is that you have to run your app in "fully trusted" mode,
which means that the code gets all the privileges the current logon
session
has been granted. If it were verifiable, it could also be made to run in a
"partially trusted" mode, which gives the code less privileges than the
logon
session, making the system more secure, and therefore potentially useful
in a
wider variety of scenarios, such as from a partially trusted website.