Replace .NET 7 target with .NET 8 rc1 #153
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #116
I am replacing the .NET 7 target with .NET 8. Version 7 is not an LTS release, while 6 and 8 are, so it makes sense to support .NET versions 472, 6, and 8 for the near future.
.NET 8 is now RC1 status which has a go-live license. Merging this change will require .NET 8 RC1 SDK to develop/build the
node-api-dotnet
project, but NOT to develop applications that use it. (Any of .NET 472, 6, 7, or 8 runtimes should still work.) Of course, we'll update from RC1 to the released .NET 8 version when it's available in a couple months.This update required more work than just replacing
7
with8
in a few places:HostFxr
is updated to allow a prerelease version (at least for now).PublishAot=true
property. For most applications it makes sense to have the managed code behave the same as the Native AOT compiled app. Butnode-api-dotnet
depends onReflection.Emit
in its managed host (not in its native host). To work around that I added a specialaot
target, with separate output path, that is built and published when packaging (and for tests).Expression.Lambda()
. I had previously used a workaround for .NET 7 (to reload the generator assemblies as non-collectible) but that doesn't work anymore on .NET 8. This change includes code to explicitly create the lambda delegate types in a collectible context, which resolves the issue. It is a lot more code but is a better solution since now the source-generator can be properly unloaded (and reloaded to pick up changes).VSTestNoBuild
behavior changed a bit in the .NET 8 SDK, so I had to update the logic that is used to conditionally skip the dependency builds during the tests.dotnet format
. So there are small updates in several places to resolve those.Additionally, I noticed the .NET 6 targeted tests were mistakenly using the .NET 7 or 8 runtime. The build and host logic is updated to fix the issue.