Well that alone is news in its own right! Thanks for the info

Sql Server may well be in RTM, but it has dependant components that are still in BETA.

It requires .Net Framework 3.5 SP1 (still in Beta) - and if you want the BI studio it will need Visual studio 2008 sp1 (still in Beta)

How can a product, whose dependant components are in BETA go to RTM, i find that a bit confusing. Correct me if im missing something, but surely, should there be any breaking change in any of the dependancies when they those dependancies reach their final release it will mean a 'HotFix for sql 2008' ? The full solution doesnt look like 100% RTM ready for production servers, it looks more like a public Beta in my opinion...

I scrolled to the end of the post where I see you have a mention to it after all! I missed it down there! :)

Or alternatavily just have a look in:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallMembership.sql
you may need to run InstallCommon.SQL before that which is in the same folder.

In the .Net framework installation folder you will find plenty of sql scripts for various scenarios
;-)

I agree that webforms are unmaintainable myself, but for the following reasons:

To me webforms when used with its server controls is just a leeky abstraction of HTML. Id much rather be able to see the actual html when I am looking at the aspx code file as is the case with MVC. But overcoming this issue whats worse is that, In order to understand what the page is trying to render one has to be flicking between the markup and the codebehind, since they are just so tightly coupled together. The codebehind needs to know all the controls on the ui and needs to set all their values etc. Personally I dont see how this makes a maintainable frontend.. Multiply this by the number of pages that you have in your site...

Viewstate is just being abused too much, in my opinion it should have just been off by default so that users have to explicitely enable it for the controls that actually need it. That way it saves us from having to toss around 1MB+ of viewstate data. Again the __dopostback paradigm means that we are completely ignoring the 5% of the users that dont have javascript disabled, (this is 5000 for every 100k visitors) as well as any WAI and WCAG accessibility guidelines...

I much rather prefer the tidyness of the proposed MVC approach where the UI is simply 'pulling' the information it needs from the viewdata, and the controller is not pushing this info to specific controls, it doesnt need to know them, its just pushing it to the viewdata - the UI logic in our markup kicks in to put the right viewdata at the right places. (sweet :-) At a glance you can understand how the page is about to be rendered without having to flick between controller and markup as you need to do with webforms...

Simple is better, all we are talking about is HTTP request... all the page lifecycle events just adding to the complication where things could have just been simpler, (again take a look at MVC lifecycle http://weblogs.asp.net/stephenwalther/archive/2008/03/17/asp-net-mvc-in-depth-the-life-of-an-asp-net-mvc-request.aspx)


just my 2c

by the way, didnt mark it as spam!

Tried seeing the blog but it was down at the time...
Here is the direct link: http://labs.live.com/volta/

Sorry, I guess I was a little to hasty on the keyboard there! Thats true, stepping back a little and looking at the overall picture what counts is that you have some information about the error. In fact, if you are the only guy working on the development of the application this is perfectly ok. But I think it is quite important for example, in a scenario where you are creating a reusable library or component, It is good practice to make use of InnerExceptions to rethrow errors in a way this post describes. When you wrap up the exceptions like this you are more likely to throw a more meaningful error to the developers who are trying to use your library in their application. More meaningful errors = better debugging experience for those developers.

Yeap, this is the right way,
The other previous article saying the 'rethrowing exceptions the right way' kicked to the front page needs burying in my opinion (if there was such an option..) Simply for the reason that it mislead people to believe that, that was the right way when in fact the one described here is

Edelman, you cant get any clearer than that, and I have to admit that your solution is elegantly right!:)

I was missing the point you were trying to make but this example is pretty clear, didnt expect it to work in all honesty, I was pretty sure that, the layout would break but of course it didnt!
Maybe you should include this example in your post to make it a bit clearer for annoying people like me and save you from some future arguments :D

@Edelman:
I dont think I fully understood what you are trying to say, but if I understand correctly, you are providing different class names to your divs (with the rationale that future changes could occur) , and because of this your solution is different to the one posted here.
In my personal opinion using the naming convention you have employed is misleading, because looking at the html one gets the impression that they can write text between the other three surrounding divs and at the same time retain the layout and the rounded corners. However if some tried to go ahead and add text to those divs as you say, the layout would brake.

One could use the divs as wrapper divs containing textual content only in the case when they eventually decide to ditch the rounded corners. As far as I can see in your example the sole purpose of each individual div is to hold one rounded corner, so you might as well name have named them as blue-top-left etc, at least then it will not potentially mislead a third developer into thinking that they can write content into those divs without breaking the layout.
Please let me know if I am missing something here, and what else is different in your proposed solution than this one posted here.

@Edelman: I dont see how your solution is sematically any different than the one proposed in this post. From the point that empty nested divs are being emplyed to accomodate a visual effect semantics have been broken. I agree that round corners on a *fluid* layout arent worth it really as the standard support stands currently.

Oh, if you simply want rounded borders, as an alternative you can do this the CSS way also (mozilla/FF and safari only)
-moz-border-radius: 15px; /* mozilla/FF */
-webkit-border-radius: 15px; /* safari */

Again there is a W3C CSS3 recommendation of border-radius
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius

And that draft has been around since 2002...
I wonder Is this such a demanding feature that the browsers have not implemented it yet (5 years later and counting)
and when they do implement it, it is with some custom css markup instead of the proposed... ah the joy of browsers!

trying to have round corners using the background-image technique for a fluid layout I'd say that this article shows the way to do it,
but admittedly having to code 4 levels of empty divs for every 'box' that requires round corners just seems a little bit too much.

Ideally what we want to accomplish here is to have multiple backgrounds on one div. This scenario is specified in the CSS3 draft
ref: http://www.w3.org/TR/css3-background/#layering
but the only browser that supports this feature at the moment is safari.

There is an alternative if you need rounded corners and you feel like cheating a bit , check this out if you havent seen it already:
http://acko.net/blog/anti-aliased-nifty-corners

I only call it a cheat because it uses javascript
;)

Well I guess im not, now im getting a different error:
[HttpException (0x80004005): Server Too Busy]

I guess this was to be expected to some extent.

Am I the only one getting an error trying to access the microsoft subscription page?

It seems to be redirecting through
https://msdn.one.microsoft.com/home.aspx

Error: The file '/home.aspx' has not been pre-compiled, and cannot be requested.