I was working with the new SQL Server Express Edition lately and was reminded that the Profiler is programmed to deny connections to this edition. Ah, I think this decision will unnecessarily challenge those who try to diagnose deployed SQL Express applications. Since you have to buy the SQL Server Workgroup (or better) edition to get the Profiler, I don’t see any reason what-so-ever to prevent its use against the Express edition. I can certainly see not including it (or some other tools) with the SSEE, but to disable the Profiler is not going to do anything but generate more PSS calls. If I had my way they would enable Profiler to access SSEE--at least to a point. It does not need all the bells and whistles, just enough to see what's getting executed T-SQL-wise.
I've also been experimenting with “User Instance=True” in the ConnectionString. In case you hadn't noticed, this option is pretty bold. What it does is create a separate (seemingly invisible) instance of SQL Server by physically copying master, model, tempdb and your user database file(s) to the user's private diskspace. This is done once--when the connection is first opened. The user can then log on as SA and do whatever they want to the database, master or whatever as it will have no effect on the “real” master etc. or other user instances. Interesting. I also noted that this option is not permitted with “non-Express” versions of SQL Server so you'll have to build a connection string specifically for your deployed SSEE target instance. This approach is interesting for scenarios where the application needs a private, stand-alone SQL Server engine a bit more robust than JET or SQL Server CE.