By way of here's a CSS vulnerability in IE. What pisses me off is the lame excuse this "so-called security firm" E-cqurity lists as the reason they didn't bother to contact Microsoft to let them know about the issue.
"This would most likely be small problem to Microsoft and we decided not to report it. Internet Explorer still has quite a few serious unpatched security holes in it, and we don't think this one deserves Microsoft's attention. In the meantime, perhaps
using a different browser to surf the web is in order."
The last statement says it all. These people clearly have an agenda. So rather than report a potential security flaw to Microsoft before releasing the information to the public (where malicious people can exploit the vulnerability) they see fit to recommend an alternate browser. The responsible thing to do would have been to take 5 minutes to report the freaking bug and let Microsoft decide whether it was important enough to fix. What a bunch of assholes.
Which way is better?
// Static method
Hotel hotel = Hotel.Find("NYC0010");
// Helper object
IHotelManager manager = HotelManagerFactory.Create();
Hotel resort = manager.Find("NYC0010");
Assume the data on all hotels lives in a database.
How do you initialize the connection string?
Where does the data access code live?
Regardless of which method you choose how do you save the hotel back to the database once you've modified it?
I've been using Whidbey since Beta 1 was released to MSDN Subscribers and I must say I love it. Generics are addictive and valid XHTML is wonderful. Refactoring support is also very nice as is the Generate Method Stub feature. The snippet functionality is very cool (type prop and hit tab) and so are the slew of new classes I've only begun playing around with. Having said all that, there are some things about the IDE that really annoy the crap out of me.
Let's start out with project properties view. Why the need to get so fancy with the UI of the project properties display? It's waaaaaaaay slower than the simple dialog based display was in VS 2003. The effort in making it "pretty" seems wasted since you typically view this screen once or twice in the development lifetime of a project. They did add the key-signing stuff here, so that's cool and this is only a minor issue. Much worse is the annoying behavior when you name a new project according to the . Guess what Whidbey does for you?! The root namespace is automagically converted by Whidbey such that the dots (.) are replaced by underscores (_). Don't do me any favors, now I have to go back and rename them all so my types are named Company.Product.Technology.Class instead of Company_Product_Technology.Class. Just a dumb choice.
Why do Web Forms continue to feel like the red-headed step child in Whidbey? Let me explain. In ASP.NET, markup pages produced with the IDE use the *improved* code-behind model (code-beside). The way it works is that your class definition is spread out across multiple files each containing a partial declaration of your type. In the case of ASP.NET, developer code goes in to one file and all the plumbing goes into the code-beside file containing the rest of the partial type. In theory this is nice considering the number of times I've seen component model/OnLoad delegate code get deleted in v1.0 and 1.1. But the drawback is that if you look at the developer portion of the partial type declaration, you would never even know that your class inherits from System.Web.UI.Page - much less that it implements System.Web.SessionState.IRequiresSessionState by default. You might suggest I inspect base types in the Class View tool, except web form projects don't show up in there only classes inside the Code directory and not web form classes show up in Class View. Not that you could do anything truly useful with the newly crippled Class View like add an override with a right-click like you can in VS 2003! In fact, I have seen no discernable way to navigate to the rest of your partial type (except by purposely producing an error - covered next).
Worse yet, try making your code-behind class inherit from a custom class that you've written which acts as a Layer Supertype. I have yet to figure this one out because the two (or more) partial definitions of a class must inherit from the same class. So making your partial class inherit from a fictional BasePageController class no longer seems possible. In fact, you get a compiler error:
CS0263: Partial declarations of 'DestinationController' must not specify different base classes c:\WINDOWS\Microsoft.NET\Framework\v2.0.40607\Temporary ASP.NET Files\certified.web.framework\fb3bd7cb\29bee2ba\dhrpkw0b.0.cs 32"
Notice the rest of the partial type declaration is hidden away in some freaky file inside some temporary assembly that the IDE gives you no way to navigate to unless you double click on the resulting error. Even then, you still can't change hijack the inheritance hierarchy because doing so would probably require you adding a reference from the temporary assembly to the assembly that contains your System.Web.UI.Page-derived type.
In short, Whidbey has some great new functionality and I'm amazed at how much they've crammed into this release. What I'm not particularly fond of is the persistent treatment of web-based projects as second-class citizens. Also some of the other IDE changes have been for the worse, not the better. I certainly hope these issues get ironed out in time for Beta 2.
[Editiing note: fast typing = missing words. Title should have read Whidbey Still Recovering From Its Slip and Fall not Whidbey Still Recovering Its Slip and Fall.
The title is a reference to my earlier post Whidbey Slips, Falls, and Breaks a Hip.]
At the risk of offending those who think SingletonsAreEvil, I'm posting to an article on MSDN which explains how to implement Singleton properly using Double Checked Locking to avoid syncronization issues. Occasionally, there is a solid reason for using Singletons and we might as well use them correctly, especially in multi-threaded contexts like ASP.NET.
It's official...they just sent me the email:
"In addition to delivering world-class antivirus protection, you can also look forward to an upgrade in your storage capacity. In fact, you'll receive 125 times your current email storage with the introduction of a 250 MB inbox as well as the ability to send attachments up to 10 MB."