Jump to content

Walter Verhoeven

Members
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Walter Verhoeven

  • Birthday 07/23/1969

Technical Information

  • Delphi-Version
    Delphi 12 Athens

Recent Profile Visitors

367 profile views
  1. Lots of talk not much code... Here is my test type IImplementsStuff = interface(IInterface) ['{83B3CBFA-9854-4BFC-A7B3-A015BE6B8B0B}'] // Interface methods end; [TestFixture] StringUtilsTests = class public [Test] procedure InterFaceToGuid; end; implementation uses SysUtils; procedure StringUtilsTests.InterFaceToGuid; var GUIDStr: string; begin GUIDStr := GetInterfaceGUID(TypeInfo(IImplementsStuff)); Assert.AreEqual('{83B3CBFA-9854-4BFC-A7B3-A015BE6B8B0B}',GUIDStr); end; Here is my implementation: function GetInterfaceGUID(const TypeInfo: PTypeInfo): string; var TypeData: PTypeData; GUID: TGUID; begin Result := ''; if TypeInfo.Kind = tkInterface then begin TypeData := GetTypeData(TypeInfo); // Correctly handle the conversion from byte array to TGUID Move(TypeData.IntfGuid, GUID, SizeOf(TGUID)); Result := GUIDToString(GUID); end else raise Exception.Create('Provided type is not an interface'); end; Hope it helps you as well as anyone else who needs it
  2. Walter Verhoeven

    Migrating projects from Delphi to .Net

    I understand that you have concerns regarding the reliability of .NET for projects with long investment horizons. From my experience, it is important to note that support for any given version of .NET typically ends within approximately three years. For instance, long-term support for .NET 8 is scheduled until November 10, 2026. This may not be ideal for projects that require stability over time, considering operating system compatibility and security updates. https://dotnet.microsoft.com/en-us/download/dotnet If you plan to move to production quickly, you will have approximately one year before needing to migrate to the next version. Additionally, it is worth noting that native compilation, such as converting .NET IL to native code using tools like the native AoT c++ copiler, can pose some problems you will not be able to fix like loose all meaningfull stack on a exception. This approach can be problematic given how many NuGet packages and elements of the .NET technology stack rely heavily on reflection. Currently, no UI framework supports Ahead-of-Time (AoT) compilation, and most complex code does not function cross-platform. Moreover, utilizing third-party code can be beneficial, but it often requires significant effort to maintain, and performing risk analysis on such code can be challenging. Additionally, ensuring service level agreements (SLA) when the implementation correctness of the code is uncertain can be difficult. Based on my personal experience managing 22 NuGet packages with over 17 million downloads, maintaining them feels like a full-time job. As a result, we are currently transitioning from .NET to Delphi and creating wrapper classes to interface with the original C# code while ensuring that nothing breaks for my users during the process. If you need more convincing have a look at the security updates, I know as I reported several of them that are still not resolved. You can check out the .NET 8.0 Downloads page. https://dotnet.microsoft.com/en-us/download/dotnet/8.0
×