-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build an apphost with hostfxr and hostpolicy linked in #35368
Conversation
Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar |
c8ec727
to
e4882e4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I second @vitek-karas's comment on here on #35087 that it is best to leave the implementation and header files in their existing directories, and only create separate CMakeLists files
@swaroop-sridhar - I will look at the file moves. |
@jkotalik on how this may affect IIS |
@janvorli - any idea what is missing for this to work? Why is it looking in corehost? |
Yeah, I'm a bit confused on how this will interact with IIS as well. In our IIS interop, we rely on calling into hostfxr via pinvoking to call |
Let me take a peek. |
Ah, I see. The move of the functions.cmake to eng/native that happened some time ago should have moved the awk script there too. The generate_exports_file function now looks for the script at ${CMAKE_SOURCE_DIR}/${AWK_SCRIPT}. So for coreclr, it is in src/coreclr as the root CMakeLists.txt is there. For corehost, the ${CMAKE_SOURCE_DIR} is src/installer/corehost. Can you please move the awk script to eng/native and modify the path to the script in functions.cmake by removing the |
@jkotalik @davidfowl Just to clarify - currently IIS hosting doesn't support single-file apps (even those in 3.1). Single-file in 5.0 is different from 3.1, but in terms of hosting support it's actually very similar - we still don't support hosting it via native host (IIS being one such native host). If this is something we think we should have, than we need to figure out what it means. |
3676d5c
to
e88b262
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall the change looks good.
Can you please make sure that existing apphost, liobhost, comhost, are not affected and build exactly the same (when compared to building without these changes)? Thanks.
#include "pal.h" | ||
#include "error_codes.h" | ||
|
||
class hostfxr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The class name must match the file name. So, the class should be called hostfxr_iface_t.
However, in keeping with the hostpolicy_resolver naming, this class (and file) should probably be called hostfxr_resolver_t.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot about this. Why the "_t" part?
Could the type and file be both just hostfxr_resolver
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every type in the host ends with _t
. While I don't particularly like it, we should follow the convention.
# The .NET Foundation licenses this file to you under the MIT license. | ||
# See the LICENSE file in the project root for more information. | ||
|
||
project(static_apphost) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@richlander @samsp-msft
Wanted to ask again if we want a better name for the static host, instead of static_apphost.exe?
We build two types of hosts:
- Apphost linked with other host components code-named "static apphost" (this PR) -- this will ship in the Microsoft.netcoreapp.host package for Windows (and Mac).
- Apphost linked with host and runtime components code-named "super apphost" (TBD) -- this will ship in the Microsoft.netcoreapp.host package for Linux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@VSadov please see @jkotas comments here: #32823 (comment).
This static_apphost
should be renamed to netcoreapphost
or singlefilehost
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file is a template to be linked with app parts and renamed, so naming is not extremely important IMO.
singleapphost
feels a bit better as it hints at the purpose of the file.
I assume the standalone apphost will not be used (or will not be recommended) for single-file scenarios once this is shipped.
I will change to singleapphost
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The feature is called SingleFile (e.g. -p:PublishSingleFile=true
) so the name should be singlefile*
for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
singlefilehost
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I meant singlefilehost
in the first place.
singleapphost
was a mistype.
@@ -0,0 +1,45 @@ | |||
# Licensed to the .NET Foundation under one or more agreements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the upcoming change: #1154 (comment)
We could consider not building hostfxr_shared.lib etc, but simply building static_apphost.exe directly.
Again: This is just for consideration ... may simplify the build logic, not sure it is a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The static_apphost should be published in Microsoft.NETCore.App.Host package, along with
apphost, comhost, ijwhost, nethost.
This is part of the work to create an apphost that bundles both hostfxr and hostpolicy. The main distinction between the static and shared versions of hostfxr is that the static version contains a hostpolicy resolver that references the hostpolicy symbols directly rather than loading them from a DLL.
This change is part of the work to enable an apphost that bundles both hostfxr and hostpolicy. There's no distinction between hostpolicy that's built as a shared library and as a static library: the shared library is built by linking an empty object file with the static library.
Provide a hostfxr_iface class, that abstracts how the hostfxr functions called by the early stage in the hosting layer is resolved.
This provides two implementations of hostfxr_iface: one for the static apphost, which bundles hostfxr and hostpolicy, and another for the conventional apphost, which loads them dynamically on startup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Please add the test-case from Add a test case VSadov/runtime#2
- The hostfxr_iface renaming issue still needs to be resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The static_apphost needs to be packaged into microsoft.netcore.app.* but I think this change can be done in a separate PR.
if (CLR_CMAKE_TARGET_WIN32 AND (CLR_CMAKE_TARGET_ARCH_ARM OR CLR_CMAKE_TARGET_ARCH_ARM64)) | ||
target_link_libraries(apphost Advapi32.lib shell32.lib) | ||
endif() | ||
add_subdirectory(static) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure "static" and "shared" are the best names here.
I think Leandro chose these because of static and shared libraries.
But "shared" is a bit confusing because (a) it seems to represent code shared between different kinds of builds, and (b) apphost is not a shared library.
Please consider renaming them to more representative names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not like 'shared', but did not have a lot of good alternatives. It is an opposite of "static" and "super" - could it be "standalone"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I think "standalone" is a good option. "linked vs standalone" or "static vs standalone" are good I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will make it static vs. standalone. (static seems good enough)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change looks good to me, except for a few issues noted above.
Thanks.
I think I have added the publishing steps in 433db23 Are there other packages it needs to be included in? |
Thanks I overlooked that change. |
@wli3 @dsplaisted FYI This change introduces the "superhost" as discussed in #32823. |
/azp runtime |
Command 'runtime' is not supported by Azure Pipelines. Supported commands
See additional documentation. |
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
Hello @VSadov! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
@swaroop-sridhar @VSadov maybe this is the reason for the test failures on rolling builds on CI for the installer linux_musl_x64 leg? https://dev.azure.com/dnceng/public/_build/results?buildId=632734&view=results |
what could be special abut |
I don't know but also note that the PR leg is Debug and rolling build is Release... There was another break similar to this in the installer tests also only in Maybe we should add a Release leg to PRs as well as it seems like these scenarios behave differently in Debug and Release. |
This is a continuation of #35087
======
This PR introduces a few changes:
One of the concerns with this was about the size of the executable. This table summarizes it: