How to access and manipulate a custom ASP.NET user control from a Controller in a Module project

We have updated our How to: Show a Custom Data-Bound Control in an XAF View (ASP.NET) tutorial with more information on how to pass external data to custom Web user controls. 

Previously, our customers had the following difficulties with this task:

- In which project to create web user controls. By default, ASP.NET suggests doing this in the YourSolution.Web project. Adding an *.ASCX control into the YourSolutionName.Module.Web project led to errors.

- How to deal with circular references when attempting to reference the YourSolution.Web project from a Controller defined in the YourSolutionName.Module.Web project.

- How to pass an IObjectSpace, XafApplication or current View object to a custom user control.

A common way to resolve such a dependency (unrelated to XAF itself) is to define an interface within your class library (a XAF module project) and implement it by using your custom user control.

No Visual Studio designers for generic ViewController versions

XAF Controllers are technically descendants of the System.ComponentModel.Component class, primarily to be smoothly integrated with the Visual Studio design time features. The standard Component designer does not support generic classes due to a Visual Studio limitation: https://stackoverflow.com/questions/6877217/can-visual-studio-designer-show-classes-inheriting-generic-types 

This is a Microsoft functionality and we cannot do much about it on our side. So, if you have a class like this, and try to double click it or use the Enter key for it in the Solution Explorer, you will receive this error, which is expected here:

This has always caused support calls to us from day one and still causes them today. Check out this support article to learn more about this situation and our previous recommendations.

Starting with v17.2.6, we have removed the visual designer association from the base ViewController<ViewType> and ObjectViewController<ViewType, ObjectType> classes - they will always be opened directly in the Code Editor now. This should work fine in Visual Studio 2015, 2017 and newer versions. This does not work for Visual Studio 2013 and older versions and we decided not to investigate this further, because of the very low usage rate of these IDEs nowadays.

We believe that this new behavior is most expected here and really hope that it will not cause new questions😀. Originally, generic View Controllers were specially designed for users who prefer to do everything manually and want to have a more elegant and compact code. So, opening the Code Editor for such classes is naturally expected. Taking this opportunity, we also improved our online documentation to further promote generic View Controllers, since most of our Support Center answers, demos and docs use this concise code approach anyway.

My team and I are looking forward to hear from you on what you think of the new behavior.