kburgoyne said:

blowdart said:

*snip*

I tracked down a reply on another forum that didn't precisely identify the problem, but it did ask a question that ended up identifying the problem on my system.

Specifically, if CardSpace is failing to automatically create a "CardSpace" folder created under their C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft folder, this is most likely the solution.

A definitely problem relates to security settings under the C:\Documents and Settings\<user> directory branch.  This is a subtle nasty "problem".  I wouldn't say it's a "bug", but Microsoft could probably add some code to CardSpace to help user's resolve it.

My entire C:\Documents and Settings\<user> branch did not have any security entry for <user>.  Access was based entirely upon administrator.  (<user> is an administrator.)

The solution is to make sure your actual sign-on user account is listed as having "full access" for the C:\Documents and Settings\<user> directory branch, including all subfolders.  The fact that the user account might have administrator priviledges doesn't count.  These folder security settings are supposed to be the "normal" situation anyway, but system reconfigurations applied over time may have resulted in these entries not existing.  There's a check box under the "Advanced" button for security settings that'll make all subfolders under the <user> branch have the same security settings as the <user> folder.

I think what Microsoft is facing here is that CardSpace is probably the first application that a user will run that probably forces the security context to be specifically the signed-on user in order to fulfill the security restrictions CardSpace wants to impose (in order to fulfill its security objectives).  Since CardSpace has security objectives that are not a concern of other applications accessing \Documents and Settings\, this isn't really a "bug" in CardSpace.  It does however mean that CardSpace support is going to encounter the typical support problems associated with going "where no one has gone before".

I think this is definitely a candidate for a knowledge-base entry for starters.  I think it is then a candidate for some user "help" code to be added to CardSpace that explicitly tests for the problem in the directory branch, and then tells the user more clearly what is happening and what might need fixing.  Presumably this wouldn't result in a security breach because presumably the user wouldn't be able to "fix" the problem unless they had the appropriate permissions anyway.

I would guess that this problem is most likely to occur on systems that have evolved through various user accounts.  This was a LONG time ago, but I believe the current user account I use was not the original account when the system was first configured.  I think I cloned the original account into this new account because I wanted to shut down network access to the original default account.  The cloning of the \Documents and Settings\ branch probably ended up creating this situation.

I changed my Users folder on Win7 x64 from C:\Users to D:\Users and ran into the Cardspace crashing issue.

After checking your comment, I replicated the exact security settings for my account folder and everything is now OK, Cardspace is running normally.

Just wanted to let people know that it works fine under Win7 too.

The main contention with Mono is not that MS only has an agreement not-to-sue with Novel. Customer of Novell are OK, others are not, which raises the question of what are you really getting yourself into if you create an application using mono that can be installed on non-Novell platforms like Ubuntu for instance. 

With WPF and Silverlight, there is a real possibility that .Net can push the boundaries of Windows and get installed on Linux and Macs. That may not represent the wishes of Microsoft for a Windows-only world, but I believe that this shortsightedness is very limiting to the development of .Net, and by extension also limits what software companies can offer to their own Customers.

I really wish MS made it clear that it will not punish customers who invest in .Net and want their application to work on multiple platforms.

EDIT: just found and read this excellent article and I must say it puts a lot of the misinformation about mono in perspective:
Why mono doesn't suck., I only wish there were more links to resources to justify some of the positions but it's a worthy read.