meiktranel/nxports

A platform agnostic tool to export .NET functions at build time.

nxports's Issues

Remove obsolete 'aborting reweave' error

Currently all errors are duplicated by an unnecessary extra error log entry.

Warn or error if inappropriate RuntimeIdentifiers/Platform/PlatformTarget options are specified

For PInvoke to work, we need to specify the bitness at build time. Meaning the old windows-only AnyCPU configuration is an absolute no go.
In this case we should error interrupt the build.

Document Support Matrix

• Supported Runtimes
• Supported Compile/Build Sdks

Document default calling convention difference to `UnmanagedExports`

UnmanagedExports defaults to StdCall while we use Cdecl.

Clarify license situation with DNLib

Upstream issue: 0xd4d/dnlib#303

Detect incompatible method signature aka fail on object methods

Exports can conceptually only work with static methods. Currently there are no checks to detect if a class method was decorated with the DLLExport attribute.

Explore GitHub Actions and GPR

Now that we've been granted access to GPR and Actions Beta, we should explore to move away from Azure DevOps, because it's just to heavy for our needs, while GitHub Actions offers a very tight integration and a very nice barebones model to work with.

Building can result in warnings because attributes were removed in a previous build

When MSBuild detects that there was no need to trigger an actual compilation, we are left with a previously reweaved dll, which has no custom attributes for us detect reweaving jobs for.

The impact is small, but annoying, misleading and may act as a deterrent for users.

Add support for .NET Core

I would like to contribute the code needed to support .NET Core.
This would require:

• special code for CallingConvetion
• copy any ".runtimeconfig.json" and ".runtimeconfig.dev.json" to the target destination if present
• support in dnlib (already created a PR there)

Remove attributes and references

Because the attribute doesn't have any purpose at runtime, we should be removing them including the assembly reference onto NXPorts.Attributes.

Freshly cleaned out workspaces without obj files make the AssemblyExportWriterTask crash

When opening a project using NXPorts 0.1.0 without already built binaries in the obj directory, the
AssemblyExportWriterTask tries to read from the intermediate assembly which does not exist yet... failing the task.
To add insult to injury, the fact that msbuild is crashed prevents the dll from being produced, forcing you to remove NXPorts before actually being able to do designtime anything.

MSB4018	The "AssemblyExportWriterTask" task failed unexpectedly.
System.ArgumentException: The given file path does not exist.
Parameter name: assemblyFilePath
   at NXPorts.ExportAttributedAssembly..ctor(String assemblyFilePath) in d:\a\1\s\src\NXPorts\ExportAttributedAssembly.cs:line 17
   at NXPorts.AssemblyExportWriterTask.Execute() in d:\a\1\s\src\NXPorts\AssemblyExportWriterTask.cs:line 27
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

Symbols are stripped away

When building using NXPorts symbols are entirely left in the dirt.

Rename ExportAttribute to DllExportAttribute

I guess the name "DllExport" more accurately expresses what is done, in comparison to "Export".

asdasdasd

Report overlapping export definitions to avoid undefined behavior caused by duplicate aliases

NXPorts & .NET Framework currently allow for a DLL to export two functions using the same alias. This results in multiple entries in the export table with the same function name. This is allowed behavior since export functions are identified by their cardinal index in the export table; in 99% cases however this entirely undesired behavior since no one really loads via index.

Release Checklist for `v1.1`

• Verify correct version in Global Properties to 1.1
• Verify that the Changelog
  • List all closed issues in this release
  • List all contributors who helped with this release
  • Check for updated license in dependencies and add package dep changes to CHANGES.md
• Wait for latest canary build to succeed
  • Automated tests succeed on all supported platforms
  • Manual testing on the canary build
• Run manual action "create-release"
  • Check and publish draft release
• Wait for tagged release build to finish
  • Approve deployment to NuGet Gallery

Add samples

• PackageReference
• Packages.config

Evaluate migrating back to automatic NuSpec generation

Because of our unique requirements concerning lib/ and build/ contents, we currently have to manually write the nuspec file. This is very tedious. We should move back into the safetynet of the dotnet sdk.

Subsequent builds do not clear NXPorts.Attributes.dll from output directory

When subsequently building without triggering a new compile NXPorts.Attributes.dll will get copied to the output directory again.

Remove NXPorts.Attributes.dll the build output

While #4 is already closed, a dotnet build will still copy the NXPorts.Attributes assembly over. I have to inspect whether this is due to a reference or whether there is additional work that needs to be done on the MSBuild side of things.

Add support for producing x86 and x64 assemblies if input assembly is AnyCpu

For snoop i don't want separate projects for x86 and x64.
The exporter i wrote for snoop creates both from an input assembly that is AnyCpu and i would like to contribute that code here.

I guess we'd need some msbuild properties to express this.
Any suggestions for that?