.Net Intellectual Property

[CyberBizsoft Support]

For those interested in .Net code security please check:

http://www.wrox.com/News/viewReview.asp?art_type=new&id=417

As a developer which considers the source code an asset (to us and the
client),
I'll be interested in knowing what is Microsoft doing about it.

[Cowboy]

If you go through the PDC slides, you will see that Microsoft has plans for
a native compile option. The reason they state is for performance, as native
code will run faster than bytecode that has to be turned into native when
run. Since most commercial developers will test code on various platforms
prior to release, the added step of native compilation for these
applications should not be a major burden.

If this goes through, I can see creating a program in IL, creating an
install package that contains the IL and having the install use the CLR on
the machine to natively compile. This will stop the necessity of multiple
versions of the product, as you would only need to call the compiler (this,
of course, will only work seemlessly if there is consistency in the names of
the tools across platforms). Code protected, but shipped as IL.

On Internet and Intranet applications, which is what a great majority of the
.Net Framework is aimed at, there is no problem with IL, unless you hire a
lot of would be hackers as employees and give them the keys to the castle.
You will then only decide to natively compile if it makes sense for
performance reasons. This is probably why MS mentioned performance rather
than security.

Overall, this issue has been blown way out of proportion, esp. when one
considers this is a beta product. I am not saying that we, as developers,
should not voice any concerns, but, if MS follows through with the native
code compilation option, the obfuscator will not be necessary in most
instances.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

"CyberBizsoft Support" <sup...@cyberbizsoft.com> wrote in message
news:#h7dkT$1AHA.1796@tkmsftngp02...

[CyberBizSoft Support]

Thanks for your response Gregory, your point is well taken. But in my
opinion, Microsoft should be a bit more aggressive on this issue since it
could undermine the whole ".Net Revolution."

It is a question of security and they should deal with it ASAP before the
"Oraclites" and "Sunses" ride all over us.

We deliver the source to our internet customers 90% of the time, but I do
not want "Joe Six Pack .Net Competitor" decompiling our apps and reselling
it.

Regards,

Santos

[Eric Gunnerson (MSFT)]

Native compilation (ie preJIT with NGEN) does not address this. The whole
assembly (metadata and IL) is still installed when this is done. The
metadata is needed for class loading and reflection, and the IL is needed in
case configuration changes make the native code outdated.

"Cowboy" <NoSpamM...@home.comNoSpamM> wrote in message
news:uPY5Iy$1AHA.2036@tkmsftngp03...

[Gregory A. Beamer]

Eric:

I had not thought about this. The PDC slides mentioned that you could opt
for native code compilation and have it run in the CLR (albeit not
implemented in the beta).

On the other hand, since the metadata, which describes the interface, etc.,
in the assembly, can be put in a separate file, why would IL have to be
installed on the client? It seems that the metadata file could be installed
and point to a native code library as easily as IL. I guess I need to go
back to the docs and look at this, as I am thinking about some reasons this
might be so as I ask the question.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think outside the box!
***********************************************
"Eric Gunnerson (MSFT)" <eri...@no.spam.microsoft.com> wrote in message
news:ODo$1pK2AHA.1228@tkmsftngp02...

[Tomas Restrepo]

Gregory,

> On the other hand, since the metadata, which describes the interface,
etc.,
> in the assembly, can be put in a separate file, why would IL have to be
> installed on the client? It seems that the metadata file could be
installed
> and point to a native code library as easily as IL.

Yes it could, but that's not enough. The main problem, I think, is that
without having the IL available too you cannot take advantage of the
versioning features of the platform, since they require the ability to
re-jit the code if necessary.

--
Tomas Restrepo
http://www.mvps.org/windev/

[Eric Gunnerson (MSFT)]

"Tomas Restrepo" <tom...@mvps.org> wrote in message
news:u7hqw3T2AHA.1032@tkmsftngp03...

exactly.

[Hans Blomme]

So, actually what you're talking about here is 'caching' native code?
Nothing more than that?

--
Hans Blomme

"Eric Gunnerson (MSFT)" <eri...@no.spam.microsoft.com> wrote in message

news:uTf4JOX2AHA.876@tkmsftngp07...

[Gunnar Skogsholm]

Eric, at one point, you said that MS was working on this problem. Do you
have any updates?

Gunnar Skogsholm

"Eric Gunnerson (MSFT)" <eri...@no.spam.microsoft.com> wrote in message

news:ODo$1pK2AHA.1228@tkmsftngp02...

[Eric Gunnerson (MSFT)]

Nothing yet, but I'll check again...

"Gunnar Skogsholm" <gun...@csi.com> wrote in message
news:uali97d6AHA.1880@tkmsftngp05...

[Eric Gunnerson (MSFT)]

I'm informed that there will be some information in this area around the
time that Beta2 ships.

"Eric Gunnerson (MSFT)" <eri...@no.spam.microsoft.com> wrote in message

news:OtvRLbf6AHA.960@tkmsftngp05...

[Cowboy]

I assume you are talking about assemblies placed in the GAC, as versioning
can be easily worked around in local apps. Of course, the CLR should not
have to JIT on the fly in most apps, not with compiled assemblies. I can see
the argument for versioning, but it still seems that a workaround can be
created when using the Native code gen with the metadata outside the
component. I will have to think for awhile about the versioning aspect you
mention here, but those wanting Intellectual property safety might be
willing to forgo some of the advantages of the .NET platform.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

"Tomas Restrepo" <tom...@mvps.org> wrote in message
news:u7hqw3T2AHA.1032@tkmsftngp03...

[Cowboy]

I assume you are talking about assemblies placed in the GAC, as versioning
can be easily worked around in local apps. Of course, the CLR should not
have to JIT on the fly in most apps, not with compiled assemblies. I can see
the argument for versioning, but it still seems that a workaround can be
created when using the Native code gen with the metadata outside the
component. I will have to think for awhile about the versioning aspect you
mention here, but those wanting Intellectual property safety might be
willing to forgo some of the advantages of the .NET platform.

--

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

"Tomas Restrepo" <tom...@mvps.org> wrote in message
news:u7hqw3T2AHA.1032@tkmsftngp03...

[Cowboy]

I concur with this Santos. I believe they should be a bit more aggresive.
While .NET is aimed for Internet, there is a real danger to those shipping
products. I do not believe, personally, that an obfuscator should be the
only choice. COM Interop is an option for protecting code, but you get a
performance penalty for code safety, which is not good.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

"CyberBizSoft Support" <sup...@cyberbizsoft.com> wrote in message
news:uGtwL1A2AHA.1736@tkmsftngp02...