Had some bad experience with a OSS library in the context of extension methods. 2 rules were broken:

- the logic of a very important type in that library was implemented with extension methods.

- the extension methods were declared in DIFFERENT namespaces (!!!).

That, frankly, is just dumb. Extension methods are used for extending types for which you don’t have the code. Even if you break this rule remember to put the extension method in the same namespace of the extended type so that when somebody is importing the namespace of that type it has access to ALL extension methods automatically.

Official versions are :

- the desktop/server version that everyone knows.

- CoreCLR - the Silverlight version.

- the version from .NET Compact framework  (which runs on windows mobile phones, Xbox 360 etc)

- the version implemented in the .NET Micro framework.

The more the merrier, i guess.

You can use Gmail as SMTP server to send emails. When i launched Topi last week i decided to use Gmail instead of the mail server of the hosting company (since Gmail is much more reliable). To configure it you can simply drop this into web.config  (replace test with actual account data):

<system.net>
    <mailSettings>
        <smtp deliveryMethod="Network" from="test@gmail.com">
            <network host="smtp.googlemail.com" port="587" defaultCredentials="false" userName="test@gmail.com" password="test"/>
        </smtp>
    </mailSettings>
</system.net>

Make sure you use port 587 because it won't work with the other one. Also i decided to use log4net to receive logging data for email so, since log4net Smtp appender doesn't support TLS authentification, i have added this to Microruntime.

You can't alter a page's viewstate with a instance variable  because it's protected. I hate the fact that if MS employees cannot think of a good reason why something should be public , they make it protected.  More context here .

I have released a new OSS project called DataModels (this should be especially interesting if you use DataBlock). It is basically an effort aimed at reusing  specific data models.

The project's page is here.

I've started working on a pet project in Silverlight a few days ago (using VS 2008). And frankly there are quite a few problems with Silverlight itself and support for it in Visual Studio :

- the designer is useless. Basically there is NO designer support (meaning drag and drop) for both Silverlight 2 and 3 in Visual Studio 2008. 

- no *proper* SOAP  Web Services support. Instead web services are invoked using WCF backward compatibility model and, here is the kick, are async ONLY. Async calls would make sense if Silvelight didn't have threads.....but since it has threads, why the heck am I forced to call everything aysnc ?!  Also SOAP headers are not properly supported  event though these guys say otherwise.

- still not enough controls.

I'm not a fan of AOP. I think that in a well design (layered) system there shouldn't be any "cross cutting concerns". Each layer should deal with his responsibility/es. Security is always given as a example of "cross cutting concern".  But i disagree with this.....security is a top level "concern". There's no point in checking credentials/access rights  AT every level of the application.  Not to mention that usually the security features of a application usually permeate to the UI level (as an example.....if the user has the option to edit a record...if it doesn't have the rights to edit it you simply disable the button. If don't let him type and then go 2 layers below to check for rights and then you show a error message....that's bad UI).

Security should really be enforced in the "entry point" layer of the system (be it UI or service).

Well,  i have been working with EF for a while and here are a few impressions :

the good :

- has UI (designer) tool for (automatic) mapping.

- offers support for advanced mapping (unfortunately in the first version only if you edit manually the xml mapping file).

- full LINQ integration (by far the biggest advantage).

the bad :

- on the persistence front,  it has support only for the "big brother" (in this case ObjectContext) which manages entity state and persist them. It doesn't offer a API to do "manual" operations. This makes it very awkward to use in ASP.NET (where most likely you'll have a ObjectContext per request and the entity state can't be tracked down automatically). From my point of view this is by far the biggest disadvantage of the API.

- support only for SqlServer.....i think it will be a while until we can use with something else.

- the MetadataWorkspace used for querying mapping data is a bit hard to use (this is especially bad considering that the first version of EF doesn't support POCO persistence).

the ugly:

- the VS  designer. I hate that crap. It gets unusable with many entitites and it generates all the code in a single file (nightmare for source control).

Plus it's  integrated in VS ( and in this case this IS a BAD thing).

efbog - the Entity Framework Business Object Generator is the project i mentioned  a while ago. Basically it generates DataBlock like business objects for Entity Framework. The project's page is here