April 22, 2019
Hot Topics:

Visual C++ and CodeDom

  • November 4, 2004
  • By Nick Wienholt
  • Send Email »
  • More Articles »

The original VB output was:

Option Strict Off
Option Explicit On

Imports System
Imports System.Data
Imports System.Drawing
Imports System.Windows.Forms
Imports System.Xml

Namespace codeguru.com
   Public Class Form1
      Inherits System.Windows.Forms.Form
         Private components As System.ComponentModel.IContainer
      Public Sub New()
      End Sub
      Protected Overloads Overrides Sub Dispose( _
         ByVal disposing As Boolean)
            If disposing Then
               If (Not (components) Is Nothing) Then
               End If
            End If
      End Sub
      <System.Diagnostics.DebuggerStepThrough()> _
      Private Sub InitializeComponent()
         Me.components = New System.ComponentModel.Container
      End Sub
   End Class
End Namespace

The original code sample went on to create an actual compiler and generate an executable file. The call to ICodeCompiler.CreateCompiler on the MCppCodeProvider type returns a null reference, which means the code cannot generate an actual executable. This shortcoming is understandable considering the greater complexity of the C/C++ compiler compared with simpler managed code-only compilers such as VB.NET and C#. You can add the generated header file to a standard Managed C++ Windows Forms application, and after including the generated header file into a source file, the application will compile without any modifications to the generated code.

Visual C++.NET 2005

Using code generation via Code DOM really pays off during the transition from Managed C++ to C++/CLI. In Visual C++.NET 2005, Managed C++ is deprecated in favor of a new, simpler .NET binding officially entitled C++/CLI. Thankfully, Microsoft didn't repeat the less-than-optimal story of the original Visual C++.NET release, and included a CodeDom provider for C++/CLI in Beta 1. In addition, the MSDN Library documented the provider.

You need to reference the CppCodeProvider assembly to use the new CodeDom provider. CppCodeProvider.dll is located in the same location under the main Visual Studio.NET install path as the previous MCppCodeDomProvider assembly. The name of the provider is now CppCodeProvider. By changing the reference and substituting CppCodeProvider for MCppCodeProvider in the CodeDom sample, you can produce the following code:

#pragma once

#using <mscorlib.dll>

using namespace System::Security::Permissions;
SecurityAction::RequestMinimum, SkipVerification=false)];
namespace codeguru {namespace com {
   using namespace System;
   using namespace System::Drawing;
   using namespace System::Windows::Forms;
   using namespace System::Xml;
   using namespace System::Data;
   using namespace System;
   ref class Form1;
   public ref class Form1 : public System::Windows::Forms::Form {
      private: System::ComponentModel:: IContainer^ components;
      public: Form1();
      protected: virtual System::Void Dispose(
         System::Boolean disposing);
      private: [System::Diagnostics::DebuggerStepThrough]
      System::Void InitializeComponent();
namespace codeguru {namespace com {
   inline Form1::Form1() {
   inline System::Void Form1::Dispose(System::Boolean disposing) {
      if (disposing) {
         if ((components != nullptr)) {
   inline System::Void Form1::InitializeComponent() {
      this->components = gcnew System::ComponentModel::Container();

Notice that while using the CodeDom interfaces still results in the output being emitted to a single file, the declaration and implementation of the form are emitted individually, which allows you to create separate header and source files if you desire. Hopefully, Visual C++.NET 2005 will ship with an option to emit the files separately. Also, the generated file uses the new C++/CLI syntax.

If the old Managed C++ syntax is required, a provider capable of generating this code also ships in the CppCodeProvider assembly. The provider, implemented in the CppCodeProvider7 type, splits the declaration and implementation in the same way that CppCodeProvider does. If a separate header and source file is required for a Managed C++ application, generating the code using Visual C++.NET 2005 and compiling with Visual C++.NET 2003 is a viable option.

CodeDom is great technology that hasn't gotten the same level of attention in C++ circles as VB.NET and C# have. This is largely due to the lack of documentation and the delay in shipping the Managed C++ provider. Despite these problems, CodeDom is just as relevant in C++ as it is in the other languages. With the major syntax changes between Managed C++ and C++/CLI, CodeDom is definitely the best technology for code generation because it allows the switch to C++/CLI to occur with the minimum amount of effort.


Nick Wienholt is an independent Windows and .NET consultant based in Sydney, Australia. He is the author of Maximizing .NET Performance from Apress, and specialises in system-level software architecture and development with a particular focus on performance, security, interoperability, and debugging. Nick can be reached at NickW@dotnetperformance.com.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date