Use Dot Net Core SDK direct from the install tree rather than a copy.

There seems to be a copy of the 32 bit libnethost.lib and header files inside ExcelDna.Host. An alternative would be to reference them from the SDK install tree. I don't think it's unreasonable to say that installing the SDk is a prerequisite of building ExcelDNA itself. I will create a PR so you can take a look, this will include getting the 64 bit build of ExcelDna.Host to work as well.

You mentioned dealing with the packed ExcelDna.ManagedHost.dll file. When you say "dealing with" do you mean loading into the CLR in the ExcelDna.Host code?

I do have otehr build suggestions, the following are roughly in order of which I think might be most impactful.

1) Generate the nuget packages as part of the csproj files rather than using nuspec files and batch commands, this uses . This way the packages generation is simply part of the normal build process with no other messing around. This could also include symbols via . Note this is orthogonal to the issues of users consuming the nuget package via rather than packages.config.
2) Factor out more build stuff into Directory.Build.props
3) Put all build output into a common solution wide output directory rather than into each project and then copying stuff around
4) Select a C# compiler version, via , I would suggest 9.0
5) Switch on nullabel reference types.
6) use /W4 and treat warnings as erros.
7) Use static analysis tools