You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tools of all kinds benefit from fast execution speeds, so compiling them for AOT makes sense. .NET Tools are a very easy way to distribute tools, so it would seem natural that tools be able to be AOT compiled. There are a few hurdles that would need to be cleared first, though:
We would need to be able to indicate that certain already-compiled binaries should be packaged as the RID-specific version of a tool
on tool install, we'd need to be able to detect if a tool was already-compiled and not create the apphost shim for that tool
Another, potentially more crazy idea might be to on-demand AOT a tool for the current platform on tool install. This could require data that we don't already have packaged in the tool, and might require dependencies like a C/C++ compiler that aren't part of our already-expressed dependency tree for the SDK.
The text was updated successfully, but these errors were encountered:
potentially more crazy idea might be to on-demand AOT a tool for the current platform on tool install.
IMO it's not that crazy. It would save lots of disk space on the nuget side of things (not to mention simplifying the solution for this github issue), and if you think about it, a user that installs a dotnet tool is in most cases a dev, so it's not too insane to require him to have some compiler tools to be able to have his tool optimized for speed.
If a user installs a global tool by using an x86 .NET SDK on an x64 operating system, then would dotnet tool install AOT-compile that tool for x86, for x64, or both?
Tools of all kinds benefit from fast execution speeds, so compiling them for AOT makes sense. .NET Tools are a very easy way to distribute tools, so it would seem natural that tools be able to be AOT compiled. There are a few hurdles that would need to be cleared first, though:
Another, potentially more crazy idea might be to on-demand AOT a tool for the current platform on tool install. This could require data that we don't already have packaged in the tool, and might require dependencies like a C/C++ compiler that aren't part of our already-expressed dependency tree for the SDK.
The text was updated successfully, but these errors were encountered: