Let’s have a little talk about WinForms in NativeAOT context again. Time flies and more and more components can be used (note, with proper ComWrappers instance supplied). There two minor issues, one is
FolderBrowserDialog and second is
Let’s start with simple one
FolderBrowserDialog. This class works, open dialog, but cannot release it, since it uses
Marshal.FinalReleaseComObject which does not support global ComWrappers instance. This is by design and would be fixed in WinForms. If by a chance you need this right now, I can suggest easy workaround. Please contact me.
WebBrowser has issues of different nature. This is extremely…
Today I will have only partially interesting article I believe. My wife stuck in Montenegro with kids, because she forget to take COVID test, and I have to magically pull additional tickets from somewhere. That’s was a bit of stress for me, so I have limited time to setup proper experiment.
Enough explanations, let’s start to business. I decide to run NativeAOT on Docker. Obviously that’s not interesting enough, since that would work in same way as it would work on Linux. So to make things a bit spicier, I decide to run Hello World on the scratch image. Practical…
I’m always looking for a diverse set of fun projects where I can show the strengths of Native AOT. So today I will write about DirectX. Technically, DirectX is just another COM library, and because I wrote about COM in NativeAOT earlier, it’s nothing special in that regards. What’s new in this article is that today I will use source generators to quickly create a ComWrappers instance ready to use within my small application.
Out of the box, NativeAOT does not work with System.Drawing.Image class and friends. I was discover that when made attempt to port existing application WinForms to NativeAOT.
So as responsible developer, I decide to fix that flaw. So I go to my pet project WinFormsComInterop and add support there. Once I implemented nescessary changes, I start looking for a target where I can show off what was done, and something simple at the same time. On first Google search I discover article from Scott Hanselman, “How do you use System.Drawing in .NET Core?”. …
While WinForms support forming it’s shape (all controls without support for images, cursors and related stuff), I found nice library which can be used for writing simple Win32 applications in NativeAOT.
Library is called WInterop and is written by Jeremy Kuhne. He seems to be working on WinForms, but this library has nothing in common with WinForms, except Win32 API. I believe this thin wrapper over Win32 API is worth looking at if you need get rid of frameworks and write Windows only application. This library has a lot of samples!! …
Today I would like to share my understanding of the status of WinForms and what’s left. I hope that WinForms would be working by that time, but unfortunately this is not yet happens. I would like to brag a lot how WinForms is usable, but unfortunately current form has it’s limitations.
Currently WinForms successfully compiles and runs WinForms which use supported controls. Other controls like DataGridView may or may not works. I simply did not test them. Overall average size of application is 37Mb for me. That’s moderately good in my opinion. Startup time not excellent, which will be improved…
A lot of people trying to use WinForms or WPF in NativeAOT and immidiately hit the roadblock — COM is not supported by Native AOT. Fortunately, after https://github.com/dotnet/runtimelab/pull/653 landed in the NativeAOT, the future seems a bit brighter. That PR unlocks ability to use RCW in the NativeAOT i.e — passing .NET to COM side.
Unfortunately, this is not yet enough for you to try WinForms or WPF application on NativeAOT, but be patient, changes are on the way.
So what can you do now with current state of COM support? And more importantly how?
A lot of applications communicate with databases at this point of time. That’s undeniable fact. Also most people in .NET world do not use ADO.NET directly and instead of rely on the ORM or ORM-like libraries. Given that Native AOT currently has several limitations, what kind of code can be compiled, I decide to test what libraries can be used with NativeAOT without too much pain.
In order for test what’s available, I decide that Dapper.Performance.Tests suite would work just fine for this purposes. This collection of benchmarks easy to setup and it has references to a lot of other…
If you want write applications for UEFI using C# that’s already possible, thank for examples from Michal Strehovský. Unfortunately UEFI does not supported by Microsoft as valid target, so development environment quite limited and experimental. Most important limitation is that you cannot use standard runtime library and BCL which defeat whole point of using C#. For now you have to maintain small library by borrowing code from NativeAOT/CoreRT project.
If you write your custom runtime you most of the time limited to start your application with
void Main() entry point. That’s not a problem unless you want use C# 9.0…
ILCompiler by default lookup for types to be compiled starting from the entry point of the application. If application using reflection, that is not enough to make application running.
To help ILCompiler found types which should be analyzed rd.xml file can be supplemented. This is similar format as format used by .NET Native, but much more limiting.
Minimal Rd.xml configuration
<Assembly Name=”mscorlib” />
ILCompiler supports 2 top level directives
Library. Right now, both of them can be used interchangeably and just define area where actual assembly configuration happens. …
Math lover, lost in the woods of software development