CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 6 of 6
  1. #1
    Join Date
    Jan 2001
    Location
    Ottawa, Canada
    Posts
    152

    Migrating VC++ 6.0 apps to .NET

    We are considering the ways to migrate our VC++ 6.0 applications to .NET platform.
    It would be nice to rewrite them completely in C#, but due to the time constraints
    this option is out of question. We started from rewriting some dll in C# in Visual
    Studio .NET. Now we face chalenges of interoperation between old VC++ 6.0 apps and new .NET C# components. To solve this problem we considered the following options:

    1) Recompile old VC++ 6.0 app in Visual Studio .NET without /CLR and use COM introperability to connect this app and new .NET C# components. It works more or less OK as long as new .NET C# component expose interfaces. But it is extremely difficult to access just methods of the class whish is not exposed as interface in .NET C# component. TBLexp automatically creates interfaces for such classes and this is complete mess. One method somehow become property, names are hardly recognizable etc.

    So I tried another approach.

    2) Recompile old VC++ 6.0 app in Visual Studio .NET with /CLR and use "It just works" approach. In this case I have no troubles to access interfaces or classes from new .NET C# component. However I very quickly discovered the
    managed/unmanaged code interaction nightmare. The new .NET C# component methods of course require managed parameters, and rest of the old VC++ application code of course expects unmanaged types.

    We don't want to convert the old VC++ application code to Managed C++ in one shoot, so the idea was to keep old application code intact (may be with minor changies) and just recompile it in Visual Studio .NET to gain easy access to new .NET C# components.

    But because of this managed/unmanaged **** I can't even make simple function call to new .NET C# components. For example see the following code segment:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    unsigned char cMessage __gc[] = new unsigned char __gc[256];
    unsigned char cResult __gc[] = new unsigned char __gc[256];
    unsigned char cBuf __gc[] = new unsigned char __gc[256];

    ...

    // Call to new .NET C# component
    m_pCommInt->SendCommand(cMessage, &cResult ) ;

    ...

    strncpy((unsigned char*)&cBuf[0], ((unsigned char*)&cResult[0]) + 3, (int)cResult[2]);
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    The last line causes error C2440: 'type cast' : cannot convert from 'unsigned char __gc *' to 'unsigned char *' Cannot convert a managed type to an unmanaged type

    I understand that strncpy doesn't understand managed types, but it means that in
    this case we won't be able easily migrate our old app to .NET platform. Lots of
    changies will be required to old app to make it interoperate with new .NET C# component.

    Are there other ways to make old VC++ 6.0 app to interoperate with new .NET C# component?

    Can anyone suggest a better way for old VC++ 6.0 app to interoperate with new .NET C# component?

    Can anyone suggest recommend a good example of old VC++ 6.0 app interoperating with new .NET C# component?

    Can anyone clearly explain how to fix code segment above with strncpy function causing C2440 error?

    Can anyone provide good examples how to convert array array of managed types to unmanaged e.g. unsigned char cManaged __gc[] to unsigned char cUnmanaged[256]?

    Most of the examples and methods in MSDN are about other way around situation when new .NET app calls old legacy component (P/Invoke etc).

  2. #2
    Join Date
    Jun 2004
    Posts
    1,352
    First of all let me get this right. Your saying that you where able to recompile and existing MFC project with the /clr option and it generated byte code the would execute on the .NET RUN-TIME????

  3. #3
    Join Date
    Jan 2001
    Location
    Ottawa, Canada
    Posts
    152

    Migrating to >NET problems

    I don't exactly understand your question. Yes had no problems to recompile existing MFC project with /CLR in Visual Studio .NET.

    The problems began when I tried to replace existing DLL with new .NET C# component as I described in my post.

  4. #4
    Join Date
    Dec 2003
    Location
    Montreal
    Posts
    58
    Lets get the basic stuff out of the way first:
    Code:
    #using <mscorlib.dll>
    using namespace System;
    using namespace System::Runtime::InteropServices;
    The within your code to go from managed to unmanaged pointers, you'll need to pin the pointers first (stops the GC from relocating while they are being used in unmanaged code) e.g.:
    Code:
    int Old_GetTagData (int TagID, unsigned char *DestBuffer);
    ...
       Int32 TestTag::GetTagData (Int32 TagNum, [Out] Byte TagData[])
          {
          Byte __pin *bp = &(TagData[0]);
          Int32 rc;
    
          rc = Old_GetTagData (TagNum, bp);
          return (rc);
          }
    In this example TestTag::GetTagData is a new class I created in MC++ to talk to C# and OldGetTagData() was from an unmodifed existing C DLL.

    In your case, you might not need to create a wrapper, you need only make sure the parameter type can be translated to the CLR types (either by default of explicitly by adding attributes).

    Compile your C++ with the /clr switch so that it may run fully under .NET (In my case I still had to use the existing native C DLL). Interfacing Managed C++ with C# is the easiest. In the above example I used the [Out] attribute because when (If ?) we port this function to pure C#, the "Out" attribute will be required as the Byte array would be passed by value otherwise.

    Read the "managedextensionsspec.doc" for a good understanding of MC++.

    For ADSOFT:
    Quote Originally Posted by adsoft
    First of all let me get this right. Your saying that you where able to recompile and existing MFC project with the /clr option and it generated byte code the would execute on the .NET RUN-TIME????
    Yes, "It Just Works" (thats Microsoft's name, not mine).

  5. #5
    Join Date
    Jan 2001
    Location
    Ottawa, Canada
    Posts
    152

    Migration to .NET problems

    You are right one must to pin the pointers before converting from managed to unmanaged pointers. However in my case this doesn't solve the problem, I stil get compilation errors. Here is my code:

    // Managed arrays
    unsigned char cMessage __gc[] = new unsigned char __gc[256];
    unsigned char cResult __gc[] = new unsigned char __gc[256];

    // Unmanaged array
    char cBuf[256];

    // Call to .NET C# component
    CallToDotNETComponent(cMessage, &cResult ) ;

    // Copy managed array to unmanaged
    strncpy(cBuf, (cResultPtr + 3), (int)cResult[2]);

    I get the following compilation error C2664: 'strncpy' : cannot convert parameter 2 from 'unsigned char __pin *volatile ' to 'const char *'

    Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

    Do you have any suggestion in general what is the best way to migrate existing VC++ 6.0 application to .NET?
    Last edited by Bobby2001; August 20th, 2004 at 09:00 AM.

  6. #6
    Join Date
    Dec 2003
    Location
    Montreal
    Posts
    58
    Could you post the ful code excerpt, I don't see how cResultPtr is declared and initialized?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured