It's taking me quite a while to get used to the programming behind this site.

I tried setting up some ExtendedAttributes as set out on the forums (I was actually getting the context issues and it annoyed hell through me most of tonight), Jose Lema's site and Rich Mercer's site.

The main problem is I wanted to set up a GUID that was assigned when the user signed up for the site.

~/Themes/default/User/createuser.aspx

Assigning it as part of the textbox "<asp:Textbox id="myGuid" ... Text=<%# System.Guid.NewGuid().ToString() %>" worked, however it reassigned a new code on postback, which is of course not great when we just displayed a different code to the user.

And I wasn't sure how to tell it not to assign on postback, so I tried programmatically setting it.

    void Page_Load()
    {
        SetTitle(ResourceManager.GetString("CreateNewAccount_Title"), true);
        if(IsPostBack) {
            User user = CSContext.Current.User; // Get the logged on user. 
            user.SetExtendedAttribute("myGuid", System.Guid.NewGuid().ToString()); 
            Users.UpdateUser(user); // Save the changes. 
            }
    }

I had to make sure I imported the CommunityServer namespace before this.

This is where I came across my next problem, I could see a guid was being inserted but it was being put on the Anonymous user - and each time I signed up with another test user it nuked and reassigned the guid on anonymous.

Obviously the result of the Sign-up process is done anonymously and then logged in on the redirect.

By this stage I realised that I was doing the guid to try and assign my users a unique id that they could then use in a winforms app to talk back to my web services, so they had the guid from the start of signing up to the site - and use it in my second ASP .NET Application, and authenticate from a winforms application.

So ExtendedAttributes is pretty much useless as it concatenates all the attributes into the one string, so is hard to do a simple lookup and compare unless you're in the Community Server environment.

So instead I'll have to look at modifying the first login to assign it to another table.

This may mean I actually have to look at doing some kind of new table for it, but also somehow leverage it to an ExtendedAttribute just so I can display it on the profile page so the user can view it at any time.

Anyway, requires more thought I guess.

And more looking into what it would take to add my own processes into CS.

I also used the instructions on this site as well as two of Dave's posts (1) (2) to remove my blogs link from my main menu at the top and put in an articles page which I just labeled "FAQ", just cos... there's no real reason for it yet other than testing.  Although I know one guy who could leverage that item to bring his applications pages directly into his Community Server page to make it one integrated site.

I've also just realised that since I set my original user up here using the ASP .NET Authentication in my app it's kind of mucked up my ID here on CS.

Guess the rule here is if you are setting up some users for your second app sharing a CS site, you need to still set every user up with Community Server, otherwise you'll have some issues.

(Such as usernames not showing up in the memberships on your CS site).

Anyway, thus concludes the post on what I learnt (by error, and mistake, and hours of banging my head against a wall trying to get rid of "context" errors).