Hi arielf,

as documented an early version of ajax toolkit had some issues with asp.net profile so we commented out that section. Since then we have upgraded the ajax toolkit and made some tests and it seems to work (it is not interfering with ajax toolkit) correctly. The bottom line is that we didn't fully test the profile in combination with new version of ajax toolkit so that's why we didn't uncomment the section.

Can you please try to uncomment the section and run the application.

If any of the problems appear please contact us and we will try to solve the issue.


Regards.

Hi khorvat,

I have uncommented the section and it is working fine.

Regards

Thanks a lot for your quick reply khorvat and kpeulic!

I have added a new profile field in the section of the web.config. However, I am not sure how to activate that field in the user profile control when a user edits his/her own profile. I am looking at both UserProfileModule.ascx and EditProfile.ascx but cannot figure out how to map HTML input fields with the new profile property.
Any suggestions? I assume the ORM is not involved here as this is native ASP.NET functionality.

Thanks a lot!
Ariel

One more thing related to this issue:

Asp.Net compiles the profile to the App_Code.dll which can't be shiped with the MonoX CMS because custom projects needs to have ability of having custom code put in to the Asp.net folder App_Code (which is compile it to the App_Code.dll).

Regards

Thanks for the details! I still cannot figure out how to add a custom field to the user profile. After adding it to the profile section of the we.config, do I need to recompile the whole project? How do I map the new profile field to input fields in the user profile page?

Hi Ariel,
Profile provider infrastructure went through a series of issues with different types of projects in VS 2005 and 2008. As MonoX v2 was started as a Web Site Project, we initially included a full support for profile providers in it. However, later changes and issues with Web Application Projects (WAP) forced us to abandon this approach. As Kristijan said, there is a little control of where the profile proxy class goes, and it makes deployment of projects rather cumbersome. In addition, there is no support for strongly typed profiles in WAP, which in our opinion almost beats the purpose of using this approach from a developer's point of view.
There are [url=http://murrayon.net/2009/02/aspnet-profile-and-web-application.html]some workarounds[/url], and this is still a convinient way to manipulate profiles for the end users and non-developers, so we are currently working on reintroducing the full profile provider support. In this version you will have to manually change the profile parts to achieve the desired effect. We are using the dedicated DB table for all additional user profile fields at the moment, which is related 1:1 to the aspnet_users table.

Ariel,

one other thing to mention is that our best practice is to put all your custom user specific data to separate table and connect it 1:1 with UserProfile or aspnet_Users table. This is a better approach on the long run.

Regards

I am using the approach you just described - it looks more difficult at the beginning, but you get a full control over the data stored in the user's profile, which is something you will use with the default implementation of the profile provider.
Maybe it could be a different story with a custom provider?

Thanks for the support! I understand then that ASP.NET profile is not a good approach for the moment. Khorvat, the best practice you mention is clear in terms of the design. But how would implement that in practice? I can create a new table with custom data and set a 1:1 relationship to the UserProfile table, but still where do I add the business logic for those additional fields ? I would need to somehow blend that in within monox standard user profile page...

SOrry if I sound to noob with that, but I am just trying to measure the efforts involved in customizing monox!

Thank you again.