DotNet or Not DotNet? (Repost) |
Post Reply |
Author | |
boa1968
Newbie Joined: 02 July 2003 Status: Offline Points: 1 |
Post Options
Thanks(0)
Posted: 16 October 2003 at 8:54am |
Because my previous post was removed after one month of silence, I'm reposting it again. I'm very interesting in the new .NET version of XT. However, after downloading an evaluating, I detected that this is not a real .NET library - it just wraps the existing MFC/Win32 framework. Is it true? If so, I would not recommend using it. CJ team, do you plan to create native .NET components? P.S. to see MFC/Win32 legacy dependencies, just try to run Ildasm.exe /adv and open one of XP.NET DLLs such as CodeJock.XtremeCommandBars.dll. In addition, why do you distribute mfc70.dll, if you call the package .NET? It remembers me the old good days when not so experienced coders claimed, that they're "writing programs under Windows", but it was native MS DOS code run inside DOS box Wating for your answer. |
|
kstowell
Admin Group Joined: 25 January 2003 Location: MIchigan, USA Status: Offline Points: 496 |
Post Options
Thanks(0)
|
Hello There! To answer your questions... The Xtreme Suite which consists of Docking Pane, Command Bars and Property Grid is indeed a .NET WinForms component. The .NET component was created using managed code this is obvious by the dependency on mfc70.dll and is no mystery. Since our products must have cross-language support (Visual C++/MFC, Visual Basic/ActiveX and .NET), using managed code was the most logical approach. This also provides encapsulation so we do not need to maintain multiple code repositories for each language, and can concentrate our development efforts in one place. In case you don't know what managed code is here is a quote from MSDN, managed code runs within the context of the .NET run-time environment: "A program written with managed code using Managed Extensions for C++, for example, can operate with the common language runtime to provide services such as memory management, cross-language integration, code access security, and automatic lifetime control of objects." The bottom line is in a "DotNET only world" you would see this product completely re-written in C# . However to maintain cross-language support "ie: real world" there is no practical reason to completely rewrite the product using C# and maintain two separate code bases. As you can imagine, this would be a huge loss of time and resources. Kind regards, Edited by Administrator |
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |