[WIP] Update entry assembly #100935
[WIP] Update entry assembly #100935
Conversation
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
|
|
||
| } | ||
|
|
||
| INT32 Assembly::ExecuteMainMethod(PTRARRAYREF *stringArgs, BOOL waitForOtherThreads) |
There was a problem hiding this comment.
What are you trying to achieve by this refactoring?
There was a problem hiding this comment.
What we are trying to determine is the best place to allow swapping the entry assembly and it having a real effect. The goal in #99883 is to allow some / all of the TPA assemblies to load, sleep/wake up, and allow the entry assembly to be swapped.
We've identified two ways to do this. Make the runtime aware, which is what this PR is attempting to do. And the second is another export in the host that doesn't shut the runtime down after it's done (the onus would be put on the custom host to do that).
There was a problem hiding this comment.
Alternative approach we've discussed in the past is this:
- Rely on startup hook to "stop" the runtime and wait for knowing the final entry point assembly
- Add a new API which sets the entry point assembly for all of the other places where the runtime uses this information
- Rely on reflection to load an execute the entry point assembly from the startup hook.
- Basically the original entry point assembly would never be executed.
This is more of the "do this in managed code" approach. Not sure how this would fit with the host changes to allow for TPA modifications after startup.
There are other similar ways - for example the above could be done without startup hooks, where the original Main would perform the operations and effectively "replace itself".
There was a problem hiding this comment.
- Rely on reflection to load an execute the entry point assembly from the startup hook.
- Basically the original entry point assembly would never be executed.
The way the runtime appears to work right now is that the original main will be executed regardless of what you do in the hook. Also, aren't there limitations executing code from the hook?
There was a problem hiding this comment.
The way the runtime appears to work right now is that the original main will be executed regardless of what you do in the hook.
Yes - but nothing is stopping the hook from calling Environment.Exit ;-)
I think the idea of doing this from the main is better anyway. That's what dotnet watch uses for ASP.NET anyway. BTW that would be another interesting thing to look at - they're one of the teams asking for the entry point replacement as the watch breaks some apps which rely on it.
Also, aren't there limitations executing code from the hook?
Not really - AFAIK there are no restrictions other than "you should not do that" - but mostly those are there to not break the "Main", but if the "Main" is empty then they're moot.
There was a problem hiding this comment.
Not sure how this would fit with the host changes to allow for TPA modifications after startup.
TPA additions after startup can be done via the AssemblyLoadContext.Default.
I do not think we should be enabling modifications of TPA after startup. It would be a pit of failure when an assembly that wanted to be overridden by the copy in the app got loaded too early. Instead, we should figure out how to startup the runtime with TPA subset that is never going to be modified.
There was a problem hiding this comment.
If we take the Main approach, then the real app main could be invoked by reflection. I wonder what is the need of creating a new API Assembly.SetEntryPoint? It seems that what Functions team would like to do could be achieved with existing API's. Am I missing anything?
There was a problem hiding this comment.
Without the new API for example this Assembly.GetEntryAssembly would return wrong value (it would point to the "host's template Main"). I think there are other places that this shows up in some way or form as well. Some apps use this to mostly get to the location of app's files (Assembly.GetEntryAssembly().Location) for example.
There was a problem hiding this comment.
ASP.NET Core has number of places that call Assembly.GetEntryAssembly: https://github.com/search?q=repo%3Adotnet%2Faspnetcore+GetEntryAssembly&type=code
As Vitek said, it is important for Assembly.GetEntryAssembly to return the actual application assembly to avoid breaking these places.
|
Closing this PR, as we chose not to proceed with this approach. We found that this approach performed the same as the Main approach (no runtime change needed) mentioned in the discussion above. |
No description provided.