Add multi-targeting for .NET 8/10

[vbsnbreuker]

Hello,

I've been working on migrating the main application my company works on from .NET Framework to .NET 10. NetOfficeFw was one of the few packages that didn't have a .NET 8+ compatible variant, so since it was open source I thought I'd give it a try myself.

Feel free to close this if it's not the direction you want the .NET 10 port to go to. I noticed there is an issue for the .NET 10 migration and not everything is checked yet. I based this PR on the main branch instead of the dev/net6 branch since the latter had not changed for the last 2 years.

I'm not that familiar with Github workflows, so those likely still need to be modified. The AppendTargetFrameworkToOutputPath property needed to be turned on due to source generated code (like for example the [assembly: Attributes]) not being compatible between .NET Framework and .NET Core+. I could perhaps use an LLM to try and make it compatible, but I'm not sure what your policy is on using AI, and I'm not fond of committing code/yml I don't understand myself.

All unit tests are running on all target frameworks except for one that failed in net462, but that was because my laptop is set to Dutch which caused the expected error message to not match. So far I tried the ClientApplication and saw no difference in how it's used (except that the .NET 8+ variant listed more assemblies in the Technical Environment / Diagnostics). For testing I also created a local nuget package and tried it on our main application which uses NetOfficeFw for Outlook integration which worked nicely.

As you can see it's not a complicated PR. Most of the code was already compatible with .NET 8+ (or would at least compile). Right now I'm trying to find a nice way to get rid of the few thread.Abort() calls which are not supported in .NET Core+, but I figured I'd create this PR as a draft to see if it's worth pursuing.

[jozefizso]

Hi @vbsnbreuker , thanks for this change and involment in the project.

What are your use cases with NetOffice on .NET 10?

I have tested NetOffice for the automatization scenarios on .NET 6, 8 and 10 and it works well. Automatization is used to control Office apps from external application.

There are still many problems with running NetOffice COM add-ins on .NET 6, 8 and 10, as there are some use cases, like task pane extensions, which require runtime support and those won't work.

[jozefizso]

As for the code change - targeting .NET 10 on Windows platform is first step to run NetOffice on .NET 10.

There are still a lot of changes required to get it working. I am sorry for the mess in the branching. There is a newer code on dev/dotnet branch where I started to do code changes required to be a native .NET 8 or 10 library.

https://github.com/NetOfficeFw/NetOffice/commits/dev/dotnet/

If you need to automated Office apps using NetOffice on .NET 10, you can do it right now. The libraries will work.

To support COM add-ins, there is still a lot of work required to be done. Some of the changes are already in the product, like splitting some WinForms code out of the Outlook library.

[jozefizso]

You can use AI coding assistance tools to work on the project. We welcome improvements.

Please ensure to include unit, integration, or other type of automated tests which your new code changes.

In fact, we are already using Codex GPT-5.5 to upgrade supporting tools, although those changes are not published yet.

[vbsnbreuker]

Currently we use NetOfficeFw not in add-ins, but in a WPF application. It's a rather large application for notaries that, among many other things, allows our customers to manage dossiers and research clients within these dossiers. We currently use NetOfficeFw to integrate with Outlook so they can automatically schedule meetings with their clients, send emails and more from within the application. There is also some interaction with Word, but we're slowly migrating that to more native solutions that don't interface through COM where possible.

While the application seems to work fine even with NetOffice still targeting .NET Framework I'm trying to get rid of the warnings about incompatible libraries by finding alternatives rather than just pressing the ignore button and hoping it works. One of the libraries I had to replace compiled fine, but on startup threw an exception which was really frustrating to track down. It turns out it was relying on a type in System that didn't exist anymore in .NET Core+. I'll admit I hadn't considered .NET add-ins for Office when I created this PR. My hope was to have more certainty about the compatibility of the libraries we use after our .NET 10 migration.

I'll try to merge back the dev/dotnet branch and fix the pipeline. I've searched a bit for a nice replacement to the thread.Abort() usage, but it seems except for inter process there is no safe way to abort a frozen thread. I'm thinking of adding a cancellationtoken instead. This would mean we'll have a dangling thread until Windows responds again though.