# The Most Exciting Promise of .NET 5

**URL:** <https://devforum.okta.com/t/the-most-exciting-promise-of-net-5/17236>\
**Category:** Developer Blog Comments\
**Created:** [April 17, 2020, 3:20pm UTC](https://devforum.okta.com/t/the-most-exciting-promise-of-net-5/17236 "2020-04-17T15:20:39Z")\
**Posts on this page:** 1\
**Showing post:** 41

<div class="post-metadata">

**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\
**Post date:** [April 24, 2020, 3:41am UTC](https://devforum.okta.com/t/the-most-exciting-promise-of-net-5/17236/41 "2020-04-24T03:41:08Z")

</div>

**Xileer**

Aaah, I was unaware of the bundled native exe. Is there any specific reason for the disproportionate file-size of what is effectively a loader, and is there any way to specify these options manually upon compilation to avoid using it (Or to use a lighter version of it, or have it shared between multiple applications)?

It seems odd that there’s a way to offload this common instruction set to a external location in .NET Framework (mscoree.dll in Windows, something included in Mono on Linux) with no obvious way (That I am aware of) to do so with .NET Core. If you’re already installing a type of “.NET Core Framework” to the operating system (The .NET Core Runtime), should this not include some form of native handling?

---

_[View the full topic](https://devforum.okta.com/t/the-most-exciting-promise-of-net-5/17236)._