Code generation between .NET Framework and other frameworks.

[jorgegr1707]

Hello,

We have tested some native calls using the NuGet on various frameworks (.NET Framework, .NET Core 3.1, .NET 5, .NET 6); we have noticed that there are interesting differences between the code generated in .NET Framework with the rest.

Attached sample generated code:

.NET Framework 4.8

public static unsafe Microsoft.Win32.SafeHandles.SafeFileHandle CreateFile(string lpFileName,
	winmdroot.Storage.FileSystem.FILE_ACCESS_FLAGS dwDesiredAccess,
	winmdroot.Storage.FileSystem.FILE_SHARE_MODE dwShareMode,
	winmdroot.Security.SECURITY_ATTRIBUTES* lpSecurityAttributes,
	winmdroot.Storage.FileSystem.FILE_CREATION_DISPOSITION dwCreationDisposition,
	winmdroot.Storage.FileSystem.FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes,
	SafeHandle hTemplateFile)
{
	...
}

.NET 5

public static unsafe Microsoft.Win32.SafeHandles.SafeFileHandle CreateFile(string lpFileName,
	winmdroot.Storage.FileSystem.FILE_ACCESS_FLAGS dwDesiredAccess,
	winmdroot.Storage.FileSystem.FILE_SHARE_MODE dwShareMode, 
	winmdroot.Security.SECURITY_ATTRIBUTES? lpSecurityAttributes, 
	winmdroot.Storage.FileSystem.FILE_CREATION_DISPOSITION dwCreationDisposition,
	winmdroot.Storage.FileSystem.FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes,
	SafeHandle hTemplateFile)
{
    ...
}

For this scenario, in the .NET Framework, the fourth parameter (lpSecurityAttributes) must be passed as a pointer, whereas in .NET 5 it is a nullable value type. And this happens with other native calls that we are testing.

Is there a reason for this difference between using one framework or another?
Any aspect that we must consider when using NuGet based on the framework?
Is there a possibility to standardize the code generation along different .NET Frameworks?

Thanks.

[AArnott]

There are differences in code generation across the frameworks, but they aren't the ones you're looking at.
The two CreateFile overloads you refer two are both generated for all frameworks.

On .NET 7, we emit both of these:

internal static unsafe Microsoft.Win32.SafeHandles.SafeFileHandle CreateFile(string lpFileName, winmdroot.Storage.FileSystem.FILE_ACCESS_FLAGS dwDesiredAccess, winmdroot.Storage.FileSystem.FILE_SHARE_MODE dwShareMode, winmdroot.Security.SECURITY_ATTRIBUTES? lpSecurityAttributes, winmdroot.Storage.FileSystem.FILE_CREATION_DISPOSITION dwCreationDisposition, winmdroot.Storage.FileSystem.FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes, SafeHandle hTemplateFile)

internal static extern unsafe winmdroot.Foundation.HANDLE CreateFile(winmdroot.Foundation.PCWSTR lpFileName, winmdroot.Storage.FileSystem.FILE_ACCESS_FLAGS dwDesiredAccess, winmdroot.Storage.FileSystem.FILE_SHARE_MODE dwShareMode, [Optional] winmdroot.Security.SECURITY_ATTRIBUTES* lpSecurityAttributes, winmdroot.Storage.FileSystem.FILE_CREATION_DISPOSITION dwCreationDisposition, winmdroot.Storage.FileSystem.FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes, winmdroot.Foundation.HANDLE hTemplateFile);

While on .NET Framework we emit this:

internal static unsafe Microsoft.Win32.SafeHandles.SafeFileHandle CreateFile(string lpFileName, winmdroot.Storage.FileSystem.FILE_ACCESS_FLAGS dwDesiredAccess, winmdroot.Storage.FileSystem.FILE_SHARE_MODE dwShareMode, winmdroot.Security.SECURITY_ATTRIBUTES? lpSecurityAttributes, winmdroot.Storage.FileSystem.FILE_CREATION_DISPOSITION dwCreationDisposition, winmdroot.Storage.FileSystem.FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes, SafeHandle hTemplateFile)

internal static extern unsafe winmdroot.Foundation.HANDLE CreateFile(winmdroot.Foundation.PCWSTR lpFileName, winmdroot.Storage.FileSystem.FILE_ACCESS_FLAGS dwDesiredAccess, winmdroot.Storage.FileSystem.FILE_SHARE_MODE dwShareMode, [Optional] winmdroot.Security.SECURITY_ATTRIBUTES* lpSecurityAttributes, winmdroot.Storage.FileSystem.FILE_CREATION_DISPOSITION dwCreationDisposition, winmdroot.Storage.FileSystem.FILE_FLAGS_AND_ATTRIBUTES dwFlagsAndAttributes, winmdroot.Foundation.HANDLE hTemplateFile);

In general, we emit the same source code. But we make special cases for target framework and language version where necessary so that the code will compile. For instance, we avoid using Span<T> overloads when your compilation doesn't make that type available. There certainly is superior code emitted for .NET because of its additional APIs.

When you are multi-targeting, you may find setting "multiTargetingFriendlyAPIs": true in your NativeMethods.json file to be useful. When you do that, we emit more APIs per-framework so that on average, you get more of the same APIs across target frameworks instead of just the best ones for each framework. That can make for fewer #if regions in your code.

[jorgegr1707]

Thank you very much for the quick response, we have tested the tag that you mentioned to us; we create new projects in Visual Studio 2022 using the .NET Framework and .NET 5; the code is generated the same for both cases.

However, in a project that works in Visual Studio 2019, we would like to incorporate the NuGet, when generating the code it continues to leave the fourth parameter as a pointer, even if we add the corresponding tag on the .json file. All these tests that I mentioned have been carried out using version 0.2.63-beta.
I attach a case where it reproduces that behavior and the generated file.

Could it be something related to the source generator feature?
Could it be that this project has some different configuration that causes that behavior?

Thanks in advance

TestNuGetVersionIssue.zip

[AArnott]

Do you know that .NET 5 is no longer supported? Targeting (or more particularly, running on) that runtime leaves you open to security exploits. I don't see any .NET 5 targeted project in your .zip file though. Only net48.

The reason you're getting a pointer instead of an optional parameter in your net48 project is because your project doesn't bring in the System.Memory nuget package. CsWin32 generation changes based on presence of Span<T> as I mentioned before. Although in this particular case I don't think Span<T> is required and it's probably just a limitation of how we differentiate code gen that that would be required to get the preferred overload generated. But it's something simple you can fix in your projects by just adding the System.Memory package reference.

The mystery for me here is how you have a PackageReference to CsWin32 while targeting net48 and not automatically get the System.Memory package as well, since that's a package dependency. Very odd. When I create a new .NET Framework class library project I cannot repro this, so I can only guess it's something peculiar about your project.

[jorgegr1707]

My apologies, I thought I mentioned that this was a problem that only occurs in the .NET Framework.
About .NET 5, yes, we are aware of the life cycle for both STS and LTS releases.
We followed what you told us and indeed the problem has already been solved, it seems that it was due to including the package reference manually; now with this, we have a better perspective on the use of the NuGet and package reference in general.

I appreciate your help.