@pkfox Good to see you! I don't trust ChatGPT's model, but then the last one i tried was 4. Everyone I talked to about it said try Claude Sonnet 4 so I did, and in some ways it really impressed me. Of course immediately after it would do something pants-on-head stupid. XD

staples... read my post. :) Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"

I’ll make a comment that has to do less with programming( it’s the lounge ) and more with common sense. I’ll give you a cultural example. If you say numbers and words are different basic types that’s not true. The Old Covenant for instance is about both words and numbers. If you take the Eastern Orthodox Church and Chinese culture that’s conflicting basic types. EOC is very sign oriented ( the cross for instance) the Chinese culture is very sign oriented as well. It’s a mismatch. (that’s not a problem because the two don’t meet in real life anyways.)

I see thank you In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP

I watched a video posted here last week about SmallTalk/Squeak...interesting, but I don't have the time. Good luck! :) "Go forth into the source" - Neal Morse "Hope is contagious"

Thanks, Dave. I'll consider it.

When comparing .NET Core and .NET Framework, it is essential to consider various factors such as performance, cross-platform support, deployment options, and future-proofing. Here’s a detailed comparison between the two to help you decide which is best for your needs: 1. Performance .NET Core: Generally faster and more efficient than .NET Framework. Microsoft has made significant performance improvements in .NET Core, especially in areas like server-side web applications and microservices. Kestrel, the web server in .NET Core, is highly optimized for performance, especially in handling asynchronous operations and modern hardware architectures. Garbage Collection (GC) and JIT (Just-In-Time) compilation have been improved in .NET Core to reduce latency and improve throughput. Supports tiered compilation, which optimizes hot paths of code over time for better performance. .NET Framework: Performance is generally good for most traditional desktop and enterprise applications. However, it lacks many of the modern performance optimizations found in .NET Core. The web server in .NET Framework, IIS, is more mature but not as optimized for high-performance scenarios, especially compared to Kestrel in .NET Core. Verdict: .NET Core offers better performance, especially for web applications, cloud-based services, and applications that require scalability. 2. Cross-Platform Support .NET Core: Cross-platform, meaning it can run on Windows, Linux, and macOS. If you are building applications that need to be deployed across multiple operating systems, .NET Core is the clear choice. .NET Framework: Only runs on Windows. It is tightly integrated with the Windows operating system and is not portable across other platforms. Verdict: If you need cross-platform support, .NET Core is the way to go. 3. Application Types .NET Core: Ideal for building web applications (ASP.NET Core), microservices, cloud-native apps, console apps, cross-platform libraries, and high-performance APIs. It supports modern development practices like Docker containers, Kubernetes, and serverless architectures. Does not fully support desktop applications like Windows Forms or WPF (though .NET Core 3.1 and .NET 5+ added partial support). .NET Framework: Best suited for Windows-specific applications, especially legacy desktop applications built with WPF or Windows Forms. If you are working with older enterprise applications that require compatibility with Windows-only technologies like COM, WCF, or Windows Services, .NET Framewor

Very good points! Everything is a trade-off. :thumbsup:

I initially was going that route, but I ran into issues with ILMerge with certain projects. It's been so long now I couldn't tell you what the issue was, but CSBrick was built because ILMerge didn't work in all cases. Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

It's been a long hard road but you're getting there - well done In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP

Presumably you have a well designed understanding of what the additional functionality is in general. There are a number of design patterns that might be useful in structuring the code. - Chain of responsibility - Fly weight - Decorator - Composite - Template As suggested other response you use reflection to load classes dynamically. Those will need either an interface or base class for your code to interact with it. You will need to at least consider dependencies (other dlls required by the dll that is loaded) in that they must be located somewhere. Either load those also dynamically or insure that the application can find them. AtaChris wrote: with reduced functionality That is a design and business consideration which cannot be addressed generically. For example perhaps you want to switch out your database driver. But the application cannot operate without any database. Same thing with supporting multiple card card processor interfaces. If you expect two but only find one then that is ok. But if you find none then the application probably cannot continue. There are ways around failure cases but they add significant complexity and even business risk.

Nelson1965 wrote: I would like the windows I open not to appear in the Task Manager The dream of malware authors everywhere! No, you can't hide your application from the task manager. At least not without writing and installing a "rootkit", which will get your application banned with extreme prejudice. Nelson1965 wrote: when I log out to turn off the computer it tells me that there are open windows You don't need to hide your application from the task manager to avoid that. Any normal application will shut down when the user logs out. If you need to do something special when that happens, subscribe to the Application.SessionEnding event[^]. "These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Thank you, your answer is helpful

Yes, but it would refuse to load the DLL even if there were no code changes or assembly property changes. I think I have solved it however. There is a file in the DLL project named AssemblyInfo.cpp, and it contains an assembly attribute named AssemblyVersionAttribute. And it was set to L"1.0.*". I think this was causing the problem. The asterisk means that it should autoincrement the version number. I changed the value to L"1.0.0" and it no longer fails to load the DLL if the DLL is rebuilt. Thanks for reading my post and for your input! The difficult we do right away... ...the impossible takes slightly longer.