I think I found a decent solution for logging errors (not just razor view compilation errors).
I would go further and also add the logging in DEV environment not just in production.
Please let me know what you think about it!
Thanks for the suggestion and contribution. We removed global MVC exception filter and diagnostic listener. Now exception errors are logged using the way you proposed. You can see the changes here.
The "Double" editor template is not working. The double.MinValue and double.MaxValue are not correctly encoded because of the "+" symbol. Please see the attached screenshot.
In some of our plugins, we have the need to resolve certain controllers. In 3.90 we are doing it like this:
var someController = DependencyResolver.Current.GetService(typeof(SomeController)) as SomeController;
and this is working perfectly because the controllers are registered in the dependency container via this code: builder.RegisterControllers(typeFinder.GetAssemblies().ToArray());
However, in 4.00 the controllers are not registered in the dependency container anymore and we cannot resolve them.
Adding the controllers into DC is easy, you just have to chain-call the ".AddControllersAsServices()" method after services.AddMvc() on line 223 ServiceCollectionExtensions file and voila - the controllers are added successfully to the DC. However, there is one big problem with this - for some unknown reason the HttpContext is always null and this is causing a lot of troubles. For example, using RenderViewComponentToString method will throw an exception on this line - HttpContext.RequestServices.GetService(typeof(IActionContextAccessor)) as IActionContextAccessor; as the HttpContext is null. Most probably some other methods like RenderPartialViewToString that are using the HttpContext will throw the same exception.
Do you think you can find a solution for this for 4.00?
Thanks for the suggestion and contribution. We removed global MVC exception filter and diagnostic listener. Now exception errors are logged using the way you proposed. You can see the changes here.
Hi Romanov,
Thank you very much! It looks good but I will let you know if there are any problems after I give it a try a bit later.
The "Double" editor template is not working. The double.MinValue and double.MaxValue are not correctly encoded because of the "+" symbol. Please see the attached screenshot.
Regards, Stoyan
Are trying to use it in admin area or public store? Are you using the culture is set to en-US (always set in admin area for formatting)? Do you experience it for other pages (e.g. product details page in admin area)?
When I look at the generated HTML, then I see something like:
In some of our plugins, we have the need to resolve certain controllers. In 3.90 we are doing it like this:
var someController = DependencyResolver.Current.GetService(typeof(SomeController)) as SomeController;
and this is working perfectly because the controllers are registered in the dependency container via this code: builder.RegisterControllers(typeFinder.GetAssemblies().ToArray());
However, in 4.00 the controllers are not registered in the dependency container anymore and we cannot resolve them.
Adding the controllers into DC is easy, you just have to chain-call the ".AddControllersAsServices()" method after services.AddMvc() on line 223 ServiceCollectionExtensions file and voila - the controllers are added successfully to the DC. However, there is one big problem with this - for some unknown reason the HttpContext is always null and this is causing a lot of troubles. For example, using RenderViewComponentToString method will throw an exception on this line - HttpContext.RequestServices.GetService(typeof(IActionContextAccessor)) as IActionContextAccessor; as the HttpContext is null. Most probably some other methods like RenderPartialViewToString that are using the HttpContext will throw the same exception.
Do you think you can find a solution for this for 4.00?
Regards, Hristian
Hi Hristian,
You can use EngineContext.Current.ResolveUnregistered(typeof(SomeController)). But the issue with "HttpContext" could be resolved maybe only injecting IHttpContextAccessor. Anyway, other "Context properties" won't be intialized (not sure that you need them). So they should be a better approach to "Contextualize" resolved controllers
We removed global MVC exception filter and diagnostic listener ...
It looks good but I will let you know if there are any problems after I give it a try a bit later.
Hi Romanov,
Since I upgraded to the latest version (it may be just coincidence) I get some very strange behavior when I receive an exception i.e component name is wrong or when a component returns a named view that does not exist. Instead of getting the developer friendly exception page with the error I get this:
"502.3 bad gateway"
The exception is also not logged in the Log. I believe it is something on my machine i.e the aspdotnet core iis module but need to be sure it is just me.
The "Double" editor template is not working. The double.MinValue and double.MaxValue are not correctly encoded because of the "+" symbol. Please see the attached screenshot.
Regards, Stoyan Are trying to use it in admin area or public store? Are you using the culture is set to en-US (always set in admin area for formatting)? Do you experience it for other pages (e.g. product details page in admin area)?
When I look at the generated HTML, then I see something like:
Please note that it was implemented absolutely the same way in 3.90.
Hi Andrei,
This is happening in the Admin area. I believe you have tested the "Decimal" editor template. There is a problem only with the "Double" template. Since the "Double" template is not used in the administration you can test by modifying the "Decimal" template and open the product edit page. Just change the min and max parameters of the Decimal template to: min: @(double.MinValue) max: @(double.MaxValue)
In 3.9 implementation is the same but it is working correctly.
Regards, Stoyan
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.