René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Discussions regarding a future Linux implementation of this repository","articleBody":"My company makes use of this library in our product (hence some of the recent work by @bwinsley / @oliverbock  to modernize towards .NET 8), but we are looking to move towards the ability to run on Linux, which this repository doesn't currently support.\n\nWhere we are at:\n1. This repository relies heavily on the C++/CLI interface which is realistically a Windows only functionality.\n2. The C++ code in this repository is pretty heavily coupled to C++/CLI (i.e. it directly uses .NET System:: types in the C++ code)\n3. Therefore a Linux compatible version would likely be (close to) a full rewrite of this code\n\nSo based on the above we are looking to use this repository as an inspiration to build out new code which would contain a pure C++ library, as well as a .NET library which interface using LibraryImport/PInvoke on the C# side. We would be keeping broadly the same public method signatures / interface on the C# side to make migration easier, and be porting the existing test suite from this repository to help prove correctness.\n\nI am posting here though to get any thoughts/impressions from the existing contributors and maintainers. Some questions:\n\n1. Would a cross-platform implementation of this library be useful to you?\n2. Would you see such a project as being a replacement to the existing repository or as separate?\n3. Do you have any other thoughts/concerns that are worth bringing up?\n\nMy view is that due to this having to basically be a rewrite it makes more sense to exist in a new separate repository rather than trying to override the work already done here. The new project would not be written with .NET Framework compatibility because it would be primarily focused on enabling cross-platform builds. There _could_ be performance implications of moving from C++/CLI to PInvoke interop. I believe this should be minimal (and potentially overridden by the .NET8+ improvements on C# side), but given the differences it is worth noting. And the big thing is obviously as a rewrite it wouldn't be established and battle-tested code anymore. So to me Javascript.NET in it's current form still makes sense to keep/maintain even after the new project is completed. \n\nOpen to any thoughts and discussions from anyone watching this repo, but especially interested in thoughts from @spahnke as one of the most active recent contributors to Javascript.NET.","author":{"url":"https://github.com/jamesf-Displayr","@type":"Person","name":"jamesf-Displayr"},"datePublished":"2026-01-16T04:49:54.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/116/Javascript.Net/issues/116"}