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
When the .well-known path is added as a virtual application it inherits the web.config but the bin folder from the parent application is not available. This can cause issues if for instance if I have added a reference in /configuration/system.web/compilation/assemblies/add to an assembly that is located in the parent application bin folder.
When the .well-known application is accessed the web.config is inherited and will fail when it tries to start the virtual application and accesses to the .well-known/acme-challenge/blahblah will result in an internal server error.
If I on the other hand, configure the .well-known path as a directory instead of a virtual application, then it will reuse the old application and just add a new file to it. Accessing the same url will then work.
I would like that the .well-known path would be added as a virtual directory instead or at least if it could be configured to be created as a virtual directory using environment variables?
I have tested to configure the web.config for the .well-known application but this is quite a tedious job and can fail if new releases of the parent application updates new dependencies into the web.config that I haven't considered.
The text was updated successfully, but these errors were encountered:
This is a viable solution but introduces other issues
Parent application needs to be modified and the modifications can be very extensive for configuration heavy applications
This will not only affect the .well-known virtual application but also every other virtual application where the configuration might be needed. There is no way to scope the inheritInChildApplications for the .well-known application only.
Is there some reason why the .well-known path must be a virtual application or why can it not be a directory?
We would like to change from virtual applications to virtual directories if we can guarantee that the change will not break existing deployments. We do not want to change the behavior depending on the options, so we need to unify one or the other.
I think there was a reason why we chose virtual applications, but I don't remember it because it was so early in the development process.
The only reason I can think about that would justify a virtual application is if you have code that is running in the virtual path that you would like to have isolated. In this case, the only purpose is to deliver static files, nothing more?
Regardless of the operation, any change to virtual paths will restart the application.
What if the virtual path is already existing?
Could the creation/cleanup part be skipped?
In that case the user can setup this virtual directory/application beforehand and avoid both restarts and configurations that breaks the validation process?
When the .well-known path is added as a virtual application it inherits the web.config but the bin folder from the parent application is not available. This can cause issues if for instance if I have added a reference in
/configuration/system.web/compilation/assemblies/add
to an assembly that is located in the parent application bin folder.When the .well-known application is accessed the web.config is inherited and will fail when it tries to start the virtual application and accesses to the
.well-known/acme-challenge/blahblah
will result in an internal server error.If I on the other hand, configure the .well-known path as a directory instead of a virtual application, then it will reuse the old application and just add a new file to it. Accessing the same url will then work.
I would like that the .well-known path would be added as a virtual directory instead or at least if it could be configured to be created as a virtual directory using environment variables?
I have tested to configure the web.config for the .well-known application but this is quite a tedious job and can fail if new releases of the parent application updates new dependencies into the web.config that I haven't considered.
The text was updated successfully, but these errors were encountered: