Importance of Managed and Typesafe code

To appreciate the significance of VistaDB, it is important to understand the importance of building managed and typesafe applications. These two relatively new programming concepts are core to Microsoft's .NET technology.

Managed Code

Managed code represents source code that executes within the .NET memory space and that is managed entirely by .NET and the Common Language Runtime (CLR). Managed applications let .NET protect a computer or device by preventing rogue or malicious code from directly accessing a computer's resources such as memory or hard disks. The .Net framework has built in security mechanisms to prevent an application from having more access to the machine than the user wants to allow. This allows IT administrators to build security policies and ensure they are enforced on all applications running within the .Net framework.

Type safety

Typesafe code means that an application cannot indirectly harm surrounding memory through the usage of variables. Type safety is a key concept in the native .NET data types. In other words, no pointers! In order to use a pointer in managed code you have to declare the code as unsafe. By doing this the code can no longer run in most security contexts.

Code Access Security

Code access security is a constraint model that allows administrators to determine the level of trust and security they require for applications running within their control. A good example is shared hosting for websites. The hosting company gets to determine what level of trust they have in your code. The code itself has to conform to those policies or it will not be allowed to run.

Medium trust is the level of trust most shared hosts configure for their customers. This level allows a lot of .Net code to run, but it denies certain risky actions (like loading unsafe code, opening remote sockets, etc). Most ADO.NET providers cannot run in Medium Trust because it is extremely limiting in what your application is allowed to do within the .Net API. As this Stackoverflow post discusses about breaking CLS Compliance, there are a lot of options to think about before you just throw Medium Trust out as not viable.

Many corporations also have restrictions in place (through security policies) to prevent users from running applications that do not meet the full CLS Compliance. Medium Trust, ClickOnce, running from a shared network drive, guest profiles in a domain setting, etc. There are lots of security situations where your code cannot run if you break the CLS Compliance.

Unmanged code means no compliance

Any third party assembly that does DllImports to load C++ or other unmanged code will not be able run. Some providers load underlying C++ dlls (Sqlite and SQL CE). These assemblies cannot load in Medium Trust unless the host specifically decides to allow that Dll or put it in the machines GAC.

VistaDB is Medium Trust Compliant

VistaDB is the only ADO.NET provider to be xcopy deployable to Medium Trust websites. Many people don't realize how big of a deal it is to meet the strict compliance for Medium Trust until they try to do it themselves.

You cannot deploy Access, Sqlite, or SQL CE to a webserver under Medium Trust. They all use DllImports and unmanaged code for their underlying engines. Some client server systems do have managed clients (MySql, Oracle and Sql Server). The client engine may be all managed, but you still have to install the server somewhere, and in many cases pay extra fees for the hosting of that server.

100% Managed code is a big deal

VistaDB is the only 100% managed code T-SQL compliant database in the world. So what? How hard can it be? It is a lot harder than it appears, and it takes a lot of work to stay 100% managed without ever resorting to unmanaged or unsafe code.

Recently a user emailed to us a Sqlite 100% managed implementation. It was not really entirely implemented (didn't handle multi user, locking, foreign keys, etc). And it was only the C++ DLL, not an entire ADO.NET provider. That 100% managed code ran 5-10 times slower than the same C++ code.

We fully expect that VistaDB will not be as fast as low level C++ engines. It is part of the price you pay being 100% managed code. If you want the largest possible deployment footprint, 100% managed code, 32 and 64 bit support from a single DLL VistaDB is the only database to give it to you.

CLS Compliance is the future

The .NET Framework in general and managed code in specific help shape Microsoft's direction for the programming model that will be used for developing nearly all Windows-based applications. Brad Abrams, author and founding member of the Common Language Runtime (CLR) and .NET Framework teams at Microsoft Corp Read more...

.NET Common Language Runtime (CLR)

Beyond the definitions, the .NET CLR is able to inspect managed application code in great detail before actually running it, which allows .NET to determine how much protection to provide the against the application or whether to run it at all. In sharp contrast to this, unmanaged applications cannot be inspected or verified to be safe by the .NET CLR before actually running them. The CLR doesn't know what an unmanaged application will do by inspecting it and therefore cannot make guarantees about what happens when the application runs. This makes unmanaged applications very dangerous to run. One reason why Microsoft is promoting the development of managed and safe .NET applications is to reduce the number of malicious applications, spyware and viruses.


PEVerify is a Microsoft developer tool that is used to verify that a .NET and Compact Framework compiler has created typesafe meta data and IL code. This tool basically verifies that an assembly is "safe" (i.e. does not access memory directly). When an application can successfully PEVerify, it is deemed typesafe by the operating system (Windows Vista, Windows Mobile 5.0, etc.) and is granted top level security permissions.

The .NET Framework blurs the lines between how ASP.NET and WinForms applications work and instead focuses attention on how security rights get assigned to applications. Think of how applications (.EXE files) are downloaded today from the Internet. How can someone safely run them without inviting a virus or malicious code onto their system? There is no clear way today other than running virus scanners and installing on a Virtual Machine. And even after a successful virus scans applications can still damage a system through intentional or unintential coding.

With Windows Vista and the .NET Framework, .NET applications that are determined to be fully managed and typesafe get assigned top level security permissions. Applications that are not, get assigned minimal permissions and end-users are warned that the application is not safe to run. This is the crux of why the world will upgrade Windows Vista. Microsoft will push Windows Vista as the "safest operating system" and managed code applications with PEVerify is at the center of this push. VistaDB lets developers build fully managed and typesafe database applications.

From the Microsoft web site:

The key to writing portable code is to write verifiable code. Verifiable code is code that can be proven to be typesafe. .NET Framework applications are built using types defined in class libraries. Each type in a class library defines fields, properties and methods that are used to access the type’s functionality. The fields, properties and methods defined by a type represent a contract between the type (which provides functionality) and the user of the type (which consumes functionality).

Typesafe code is code that obeys ALL type contracts. Types represent memory. And the fields, properties and methods defined by types represent ways to access memory. Ultimately, this means that typesafe code is code that doesn't improperly access memory. And because typesafe code doesn't improperly access memory, the common language runtime is able to safely execute multiple verifiable applications, each isolated in its own AppDomain, within a single (more expensive) operating system process. Also, because typesafe code doesn't improperly access memory it also reduces memory corruption which results in a more stable execution environment.

The C#, VB.NET, J# and managed C+ compilers that ship with the .NET Framework SDK all produce verifiable (typesafe) code. The C#, VB.NET and J# compilers produce verifiable code by default, while the managed C++ compiler produces verifiable (typesafe) code when the /clr:safe flag is used. In addition, the .NET Framework SDK ships a tool (PEVerify.exe) that allows developers to determine if their code is verifiable.


Common Language Runtime (CLR)—The type, metadata and execution systems provided by the .NET Framework, which supplies managed code and data with services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support. By targeting the CLR, compilers and other tools can offer these services to developers.

Intermediate Language (IL)—The machine-independent language into which .NET applications are compiled using a high-level .NET language compiler (e.g., C# and VB.NET). The IL output is then used as the input of the Just-In-Time (JIT) compiler, which compiles the IL instructions to machine language just prior to its execution. IL can also be converted to native machine object code using the Native Image Generator utility.

Managed code—Managed code supplies the metadata necessary for the CLR to provide services such as memory management, cross-language integration, code access security, and automatic lifetime control of objects. All code based on IL executes as managed code. By having 100% managed code your application is able to be promoted to other architectures through the Framework. An application written for 32 bit Windows can JIT up to a 64 bit application without any code changes.

Native code—Machine-readable instructions that are created for a specific CPU architecture. Native code for a specific family of CPUs is not usable by a computer using different CPU architectures (c.f., Intel x86 and Sun UltraSPARC). Also called object code and machine code.

Portable Executable (PE) file—The file format defining the structure that all executable files (EXE) and Dynamic Link Libraries (DLL) must use to allow them to be loaded and executed by Windows. PE is derived from the Microsoft Common Object File Format (COFF). The EXE and DLL files created using the .NET Framework obey the PE/COFF formats and also add additional header and data sections to the files that are only used by the CLR. The specification for the PE/COFF file formats is available at

Portable Executable Verifier—A .NET programming tool (PEVerify.exe) used to verify that a .NET compiler has created typesafe metadata and IL code. Because Microsoft .NET compilers always generate typesafe code, this tool is used primarily with third-party ILASM-based compilers to debug possible code generation problems.

Typesafe—Code that accesses only the memory locations it is authorized to access, and only in well-defined, allowable ways. Typesafe code cannot perform an operation on an object that is invalid for that object. The C# and VB.NET language compilers always produce typesafe code, which is verified to be typesafe during JIT-compilation. The PEVerify tool can also be used to verify if code is typesafe.