Single library output ?

[maximilien-noal]

Hello,

Thank you very much for this project !

I can finally write a libretro core with .NET 5 in a manner that is fully supported.

Is it or will it be possible to build everything in a single static library ?

I want to be able to ship only a single file per platform (Windows, Linux, Mac) like libretro cores written in C do.

It does not seem to be possible in my mind (there's got to be a proxy), but it doesn't hurt to ask.

Thank you very much again !

[jcapellman]

A couple of my use cases would prefer that as well - though not having to do a COM Interface or Embedinator 4000 is worth the switch to DNNE.

[AaronRobinsonMSFT]

Is it or will it be possible to build everything in a single static library ?

@maximilien-noal Great question. That is something I am thinking about working with @vitek-karas on supporting. There are some minor issues to handle and a few major ones, if a "self-contained" library is desired, that would need to be addressed. As an FYI we are actively discussing the inclusion of this kind of tech in .NET 6.0. Nothing is certain but as we hear more from the community we take this feedback seriously during the planning phase.

@maximilien-noal and @jcapellman

Are either of you looking at self-contained deployment or would shared-framework be fine?

/cc @jkotas

[jcapellman]

Self Contained would be preferred, but shared framework would be ok as a hold out until .NET 6

[maximilien-noal]

Either is very fine, even if self-contained would be interesting to ease shipping even more.

[NickAcPT]

I too would love to see this be implemented. For me, self-contained would be super amazing, but shared framework is also fine.

[AlexandreGarino]

IMHO, both of the two approaches should be available.

[LeonarddeR]

I'd also really like selfcontained export for this to be available!

[govert]

I would prefer a single-file library, but targeting shared-framework. This is because I am loading into a hostile native process (Excel) and need to share with other libraries, so would prefer to support the newest framework on the machine.

[esso23]

This would be great. Currently we are still forced to use net472 - we are using DllExport for unmanaged exports and Costura.Fody for single library output. This feature would finally make it possible to migrate to .NET 5.

[bitapparat]

Any news on self-contained publishing, now that .NET 6 is available? I want to provide a plugin for a native application, ideally developed in .NET 6 and self-contained.

[AaronRobinsonMSFT]

@bitapparat I am sort of reluctant to evangelize this functionality but I did add basic support in an experimental way. Getting it to work is not for the faint of heart but that is mostly an issue with collecting all the needed .NET components and putting them in the right place. The DNNE support is as good as it can get given the current library support for self-contained in .NET.

https://github.com/AaronRobinsonMSFT/DNNE/blob/5e54164791978b706749b7b3083e32c3cd2fcb7c/src/msbuild/DNNE.props#L87-L93

[climblinne]

Just to clarify, I looked into .net 6.0 and recognize, that the single library output will be only available for "executables". Did I miss anything, how it can be made elsewhere?

[ThaDaVos]

Any updates on the above?

[vitek-karas]

NativeAOT can produce self-contained native libraries. It still comes with similar drawbacks as self-contained CoreCLR based library would though:

• Debugging experience is reduced - in the NativeAOT case you can definitely debug it, but it looks like a C++ (or other native) code for the debugger.
• Multiple GCs in one process - and all the potential issues which come with that. This should not be a functional problem, but could be a performance issue depending on the usage.

[govert]

Can you perhaps expand a bit or add a link about the "Multiple GCs in one process"? I imagine having to support many tens of add-in libraries (built with NativeAOT) in a single Excel process. They can't use a shared runtime because .NET 6 might also be loaded in the process. Would this be OK, supposing one has enough memory?

[ThaDaVos]

Sadly, dotNET 7 NativeOAT doesn't support x86...

[vitek-karas]

Can you perhaps expand a bit or add a link about the "Multiple GCs in one process"

I don't think we have a document discussing this. @vsadov might know more about this - if it's something we would recommend in your case (10s of GCs in one process).

Note that if you wanted self-contained, then this would exist regardless if it's NativeAOT or not.

[VSadov]

I am not completely sure I understand the context here. The way NativeAOT runtime is structured should allow multiple dynamically loaded libraries in a process each with its own runtime and its own GC. It is not a common scenario, so there could be issues, but it should work. When multiple NativeAOT libraries are linked into an app statically, they are linked with only one runtime library and thus share the runtime and GC.

@MichalStrehovsky would know what configurations would be more appropriate here.

[ThaDaVos]

What I have done is used Fody with Fody.ILMerge - you'll end up with two DLLs - your normal dll and the NE one - for me, it works perfectly this way

[maximilien-noal]

Hi,

Any update on this perhaps ?

Also is dnne still considered experimental ?

Thank you !

[AaronRobinsonMSFT]

@maximilien-noal No updates on this issue. Since .NET 5 a bunch of things have happened in the hosting space so it might now be easier to make this possible in a supported manner. @elinor-fung, Are there officially supported options for loading an assembly from within a native binary? I'm not keen on reimplementing the single file experience outside of the .NET SDK, but I might be able to create some narrow scenario.

Also is dnne still considered experimental ?

It is experimental in the sense that it isn't supported officially by .NET and instead by me, one of the .NET runtime devs. It is also a relatively simple project that can be easily replicated by any one using official .NET 5+ APIs.