-
Notifications
You must be signed in to change notification settings - Fork 10.3k
View recompilation for assemblies loaded through AssemblyLoadContext does not work #14359
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
Comments
@pranavkm thoughts? |
@taori Seems like you are loading the class libraries at runtime. I'm not sure Razor runtime compilation will work in that scenario. The error you are seeing has to do with the reference not being part of the dependency model (*.deps.json" file) and I'm not sure there's a way around it. @pranavkm can confirm. |
@javiercn Hm. Would that not make config.AdditionalReferencePaths kind of obsolete though? That property looks like exactly what i am looking for. Let's see what @pranavkm has to say about this. It would be a shame if this did not work since that would completely break extensibility for what i am trying to do. The weird thing here is also how i change a view in the main application and the error which appears is another plugin, where i made no changes. |
Ok, I missed something the first time I looked. You need to app the runtime assemblies to the list of application parts, which is what MVC considers when it looks for views, etc. |
Nevermind, I saw that it's behind AddPlugins. That said, I'm not confident in the logic you are using there to configure the parts. You should use ProvideApplicationPartFactoryAttribute and RelatedAssembliesAttribute to intantiate the parts for an assembly and find related parts respectively. |
Yep. you found it. That was the suggested way in 2.x and the assemblies loaded so i figured that way is ok. I suppose you are talking about that attribute? Doesn't look like it is in netcore3.0 anymore or are the docs just not up to date? I have not seen any documentation about this attribute but i'll see if someone on github is using this attribute. |
I'm glad I was able to help. The attribute is in 3.0, Closing this as there's no action for us to take here. |
@javiercn but that didn't help? The docs suggest to use adding assembly parts like this and the application is breaking when i edit unrelated cshtml files. I have no idea why both tickets are closed now, since the problem still exists. |
@taori My bad, I thought you meant that you fixed the issue with my suggestion. I’ll leave this open so that we can investigate. |
It's fine that one ticket was closed since they sort of duplicate each other. Unfortunately the other ticket was closed because this one was closed. 😄 You can sort out which one may be closed, i suggested the other one should be closed because the title was inaccurate - viewcompilation does work, better than before, but for some odd reason editing files in a plugin scenario breaks the application, which is a rather severe issue. I am currently forking pranavk's plugin app, to verify that this isn't related to how the parts are added, because in https://github.com/pranavkm/PluginApp there are neither references, nor ProvideApplicationPartFactoryAttribute used, which renders his project very similar to what i am trying to do (except he used another netcore app, since RCL wasn't around at the time i suppose) |
@javiercn is there a guide to add your own sample to the sources of release/3.0 so i can debug this myself? I'm getting duplicate references warning and i am guessing you have some sort of cheat sheet to debug samples using the mvc sources? |
@taori Not really. If you want to debug against the sources, I think it's better if you disable "just my code" and enable sourcelink. That's what we do even on the team when we debug repros. |
@javiercn That's good to know. I wasn't sure if decompiling into sources and setting a breakpoint works with source link, since in that case you can't enter the call chain without it. Thanks for letting me know. |
File header File header bom marker
Closing this issue since we're already using the linked issue to discuss this further. |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
After figuring out that view recompilation only works without debugging now i tried to get it working on RCL views - should this be working or is this not supported yet?
To Reproduce
Steps to reproduce the behavior:
Reproduction
Screenshots
Expected behavior
I would expect RCL views to update as well, not just views which are in the main application
The text was updated successfully, but these errors were encountered: