日期:2013-10-11  浏览次数:20595 次

Is Your Code Safe?

VS.NET's use of Microsoft Intermediate Language creates big advantages, but exposes VB.NET on the desktop.

by Dan Fergus
URL: http://www.vbpj.com/upload/free/features/vbpj/2001/05may01/df0501/df0501-1.asp


In the Visual Studio.NET (VS.NET) Framework, compilers such as VB, Visual C++, and C# compile their source programs into Microsoft Intermediate Language (MSIL), which is subsequently Just-In-Time (JIT)-compiled into native machine code before execution. But you might not know exactly what happens in VS.NET when you click on the Build button, or whether your proprietary code and information are safe from prying eyes and tampering when you ship IL code to your customer. I'll step through the inner workings of the .NET Framework to show you what's new and explain what concerns you should have with MSIL under VB.NET.
What you need:
VB.NET beta 1
You need to be clear about several points. First, .NET is designed for client/server and Web apps. Software is moving to the Internet and to client/server-based applications, so many applications now look more like browsers than the old-style interface. .NET follows this trend.
Also note that .NET isn't suitable for desktop applications if you care about protecting your intellectual property because you can't protect it in managed MSIL code on the desktop. This is a shocker to me. Although MSIL's premise is good and the .NET Framework and Common Language Runtime (CLR) are stable, they're just not feasible or workable in a standalone desktop application from a security standpoint. As a VB programmer, or even a C# programmer, you have no way to write anything but this unprotected managed code in .NET.
Because of this limitation, you must write unmanaged C++ code if you want to protect the code in your desktop app. The only sure way to protect intellectual property: Wrap the code into an unmanaged C++ component and use the COM interoperability interface to call it from .NET managed code. Unfortunately, this isn't a workable option for VB or C# programmers.
You also should know that Active Server Pages.NET (ASP.NET) applications are safe because they run entirely on the server. This is the nirvana of .NET—running code that's buried away on a protected server, far from the reach of any party interested in looking at your code. ASP.NET makes Web development incredibly easy, and Visual Basic.NET (VB.NET) is a good tool for writing ASP.NET apps.
VB.NET has a steep learning curve, and .NET as a whole will experience slow acceptance. Migrating from VB6 to VB.NET is not easy, and you'll need to support VB6 applications for some time before porting them. VB6 might now be the Microsoft stepchild, but many developers will use it for a long time to come.
MSIL is Old—But New
See what happens when you build a project in VB.NET: Create a sample project you can use as you generate code and assemblies. Open VS.NET, create a new Visual Basic project, add a Label control to the form, and change its Text property to "Good Bye Visual Basic 6.0" (see Figure 1). Instead of the standard Hello World app, you'll write a GoodByeVB6 app. Figure 1 | Create an App Under .NET. Click here.


You need to know some boundaries and terms before diving into .NET. First, the idea of IL is nothing new. The VB and C++ compilers have generated IL for years, but no one discussed this publicly and no one documented it. The single biggest change from the way you shipped applications in the past is in the code the compiler generates. Other t