Cannot convert anonymous method to System.Predicate message may be misleading

This compiler report is misleading. It turned out that there was an undeclared variable within anonymous method, e.g. "someId" below was not declared or passed in as an argument. It looks like the compiler may not be able to dig deeper into the anonymous method and report syntax or normal errors.

if(delegate(Product rcrd) { return (rcrd.ItemId.Equals(someId); }))
{
// do something
}

Check out the following links for more info:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=91434
http://weblogs.asp.net/avnerk/archive/2006/05/22/Bad-compiler-warnings-when-using-anonymous-methods-for-Predicate_3C00_T_3E00_.aspx

Windows Vista Shutdown/Restart from Remote Desktop

You can shutdown or restart Windows Vista while you've remote-desktoped into the machine by executing this command prompt:

Windows Vista
Restart: shutdown /r /t 0
Shutdown: shutdown /s

Windows XP
Restart: shutdown -r -t 0
Shutdown: shutdown -s

ProfileManager.DeleteProfile

I wanted to find out how would the web site behave when suddenly there is no profile for the logged in user, i.e. it was deleted from the Profile provider. It turned out that it's a bit more than simply calling the DeleteProfile method.

In one scenario this methods returns True even though in fact it's not actually deleted the user from the aspnet_Users table. This scenario is when you're trying to delete a profile while the that user is logged-in within the same browser session. Strangely, the SQL Server Profile traces seemed to confirm the deletion since the transaction as commited. (However if you dig a little deep into the stored procedure, you'll see that DELETE FROM aspnet_Users call condition is not satisfied and therefore not called.)

The trick was to delete the profile while not logged-in in the same browser. This is another reason you need both IE and FireFox for development purposes.

Here are the steps:
1. In IE, login as the user.
2. In FireFox, navigate to the page that triggers the DeleteProfile call. I supposed this could be achieved in a command line application.
3. Go back to IE and refresh the page or click to other pages.

Beware that users who are logged-in will have unexpected web site behavior, i.e. this exercise is not recommended in all server environments.

Microsoft North America TechEd 2008 - Developers

Featured Speakers: https://www.msteched.com/dev/featuredspeakers/default.aspx
Developers Agenda: http://www.microsoft.com/events/teched2008/developer/about/agenda.mspx
Technical Tracks: https://www.msteched.com/dev/public/tracks.aspx
Session Catalog: https://www.msteched.com/dev/public/sessions.aspx

Profile Serialization Hell (similar to Dll Hell)

I recently came across the problem of modifying the interface to one of the classes that was contained within a custom ASP.NET 2.0 profile class. The worry was that if the property name via which that particular property is accessed gets changed, the profile will break. The consequence of this breakage would have been that if the user is logged in while the code gets deployed (I know that code deployment should, in most cases, be deployed after hours) the serialized profile object in the SQLProfileProvider would not match that of the new deployed object and it would error out or the site would not function properly. Here is an interesting insight.

Properties are just getter/setter methods in .NET, i.e. I had nothing to worry about breaking the compatibility. I could have the name of the property itself. The culprit is when the private variable name that gets serialized and deserialized when reading the profile object stored in the database. If you change the name of this private variable, it breaks!

The point is that if you don't change the variable name, everything should be fine, even if you add new properties and their corresponding serializable variables. Note that removing a variable will definitely break the compatibility.