Archives
-
System.Transactions.TransactionScope and IDbTransaction
I've enjoyed reading about the new System.Transactions namespace and the easy to use TransactionScope object. But there was always something that I wasn't sure about, and from questions I've received its clear I wasn't the only one. The question is basically what happens if you have a traditional ADO.NET IDbTransaction and you enclose it in a TransactionScope? I finally got around to testing out this scenario and I'm pleased to report that everything works exactly as you would hope. In other words, even though you may have an IDbTransaction that you have committed, it will still get rolled back if its enclosed in a TransactionScope that does not Complete. This means that you can continue to use all your existing code and libraries that work with IDbTransactions -- and still use the new TransactionScope when you need something more. It also means that I don't need to do anything special for my ORMapper -- I can continue to use IDbTransaction and my users can use the new TransactionScope also. By the way, I knew Access didn't support distributed transactions, but I was pleasantly surprised that I got an exception when I tried out of curiosity. Finally, for all my readers that think this behavior with IDbTransactions should be obvious, I agree but I've also learned to test things instead of assuming.
-
Scott Guthrie and Web Projects in VS 2005
Scott Guthrie's promised post with more details on the VS 2005 web projects is now up. I very much appreciate the new capabilities that the ASP.NET team has worked very hard on. I'm still not sure why any of that required getting rid of the project file though. :) Anyhow, its obviously what we will live with, and while its a change, there are many good changes too.
-
Went to See March of the Penguins
Go see March of the Penguins if you have not -- its really good -- more like a traditional movie than a documentary.
-
WilsonORMapper v4.1.1 Released -- With a Big Thanks to Paul Welter
Update: WilsonORMapper v4.1.1.0 (8/13/2005) includes the following:
- Added new InitialState.Updated enum value for the StartTracking method.
- This allows immediate PersistChanges -- useful for distributed systems.
- Now supports generic relation collections -- even for the lazy-load case.
- This feature was added by Paul Welter -- his templates are also updated.
-
Scott Guthrie Comments on Web Projects in VS 2005
Check out the comment on my previous post from the man that started this whole ASP.NET thing.
-
Is the Sky Falling? Do we need a Beta 3? Do I even care?
Why do I complain about the lack of project files in VS 2005? Do I think the sky is falling and that a Beta 3 is needed?
No, I don't think .NET v2 is going to be a failure, nor do I think there should be a Beta 3. But the reason I don't think there should be a Beta 3 is because I know how big a deal a beta is and I want v2 as soon as possible and not slowed down -- because I will be gladly using it.
But then why do I make my "negative" posts and complain about VS 2005? Because the whole point of the open process is to get our feedback, and I'm giving it -- sometimes loudly. Why? Because I want the RTM to be as good as it can be, because I don't plan on waiting until a SP.
Will I survive without a project file? Most assuredly YES. I can make multiple server forms possible, and make web apps stay alive, and do just about anything I want -- given the time. And that's the rub -- why should it take lots of my time to do something that is very easy today?
-
MS Changes Internal Implementation of Nullable Types
The MS .NET teams have heard some of our pain with nullables and have implemented some post Beta2 changes described here by Soma:
After looking at several different workarounds and options, it became clear to all that no amount of tweaking of the languages or framework code was ever going to get this type too work as expected. The only viable solution was one that needed the runtime to change. . . . The outcome is that the Nullable type is now a new basic runtime intrinsic.
Hopefully this also addresses a lot of the other issues with nullables not being integrated into the entire platform, but I'm not convinced yet. -
MS Responded to Yesterday's Post with Another Work-Around
The MS ASP.NET team has apparently heard some of our pain with web projects no longer having project files in VS 2005 and created another work-around since my last post:
Thanks to Andy Miller for pointing this out. I wouldn't exactly call this the "right" solution (that would be giving us at least an option to have a project file), but they are listening.Closed by Microsoft on 2005-08-10 at 11:42:12
Here is an update on this bug. Based on user feedback, we made a post-beta2 change to allow file-based assembly references to be updated. In VS03, this is equivalent to setting the CopyLocal flag to true and saving the flag and path information in the project file. In VS05, we do not have a project file, so this information is saved into a new type of file called a Refresh file, located in the Bin folder along with the copied assembly. When the compiler sees this file, it will get the path and check to see if a newer copy of the file-based assembly is available and will copy it to the Bin folder if it is found.
For example, if you have a file-based assembly reference to
c:\libs\foo.dll
then your web app will contain
c:\webapp1\bin\foo.dll
c:\webapp1\bin\foo.dll.refresh
I have changed FDBK27472, which was originally postponed, to reflect this new change. Thank you again for your input -- as you can see it makes a difference!
-- The Web Platform & Tools Team
-
ASP.NET Simplicity -- When Is Too Much Simplicity a Bad Thing
I'm a big fan of simplicity -- but some of the things the MS ASP.NET team is doing in the name of simplicity are adding complexity -- and some don't even have realistic workarounds. I started thinking about this post while writing my last one about multiple server forms, but there are other examples where MS is making things harder in the name of simplicity.
1. A big cause of grief going around right now is the impact on real enterprise developers of the decision to have web projects not have project files. Yes, this was a decision made in the name of simplicity -- and for 99% of the web developers out there that ASP.NET targets it probably was a very good decision. But once again the problem is that this simplicity is being forced on the rest of us, and many of us enterprise developers really need many of the capabilities the project file gave us. Should MS have known better -- most definitely yes -- I for one tried to warn them about this very issue at the first Whidbey preview in October of 2002, and I think I was probably the one attendee that best represented real enterprise developers as opposed to authors and trainers.
2. Another "problem" that was introduced with ASP.NET v1 and is now getting worse is that MS gives us "rich" web controls with properties like backcolor, font, and width. Unfortunately, there are no such html attributes -- everyone of these properties is instead actually part of the html element's style. Yes I realize this simplifies things greatly for newbies, but all its done is "teach" more people that CSs isn't important -- and its made real CSS stylesheets much more troublesome to use in ASP.NET. Think I'm off my rocker? Did you know that the Calendar's Title CssClass did not work at all in v1 since no one ever bothered to test stylesheets adequately? Want another example? Did you know that WebPartZones, yes that new wonderful portal technology in ASP.NET v2, will not work with the CssClass properties -- and according to MS that's "by design" and "postponed"? I was really hoping to use WebParts, but all I had to do was try to use it with CSS stylesheets (don't most portals work that way) and I realize they are pretty much worthless -- not to mention take a look at the ugly html they produce. And what's the work-around for this you ask -- Themes and Skins. I know that Themes and Skins are one of the cool new features of ASP.NET v2, but have you ever stopped to think that they wouldn't be needed if we just used CSS stylesheets!
3. My last example is harder to explain -- its not really an issue with "postbacks" so much as a problem with the way most controls handle the postback to determine what to actually do. I'll use the ever popular ASP.NET Forums as an example -- specifically the moderator tools to approve a post or unmoderate a user. I'm looking at a post right now where the Approve link-button has the following link: javascript:__doPostBack('ContentControl$_ctl0$PostRepeater$_ctl0$_ctl0$_ctl0$Approve',''). So what's the problem? This is all based on the relative position of controls, and the data they are assumed to contain, instead of using the actual data key. Sure you can make an argument that its more secure to not expose the data key, but the problem is that without it there is no good way to reliably know what data we're supposed to be talking about! If you use viewstate to move all the data with the postback then its not a problem -- but of course we all hopefully know that moving all of the data in viewstate (the default though in most cases in ASP.NET) is not a good thing. So instead the data is re-queried on postback to determine what data goes with which control, and therefore what post should be approved in this case. But the data can and does change on a real website with lots of activity (hmmm, like the ASP.NET Forums)! So what ends up happening is that the wrong posts are often approved and/or the wrong users are often unmoderated (or we just don't bother to unmoderate anyone).
Now to their credit, they have fixed a lot of these issues in the ASP.NET Forums over the years -- the delete post link now uses the actual key for instance -- but many of these very real bugs persist. The standard method of not using the key is also not very performant, since even if you forget the case of data changing you still have to re-query the database just to do something (and then query it again to get the final set of data to display after the change) -- unless of course you put all the data in viewstate. Note that I do not want to imply that postbacks, viewstate, controls, or any other feature is inherently wrong -- I only want to point out that the simplification has went too far and can actually affect data integrity and/or performance if you use a lot of the defaults. For me this means that I never use the datagrid for more than the simplest of pages or prototypes (if even then) -- and that's really not even a burden once you've used the repeater a few times, or written your own "grid". But the problem persists (and most people don't even realize it) -- and just as bad there are now thousands of articles out there to help you figure out how to get around all the various short-comings of these simple controls. Why? Because this simplicity is great when it works, but unfortunately its teaching many web developers to never do anything else -- I can't even begin to count the number of "huhs" I get when I respond to questions about the datagrid that I don't know because I don't use it.
OK, end of post -- I hope I didn't lose everyone -- or make you think I've lost it. I really do love ASP.NET, and I do appreciate the folks on the MS ASP.NET team, and I do understand the needs for some of this simplicity so that they can reach out to a much wider pool of web developers -- I do not want their job. I just think that sometimes what is simple in the short-term or small cases ends up being anything but simple in the long-term or bigger cases -- so there needs to be a better balance in some cases to not make things too easy just because someone wants it that way. I encounter the same types of things even with my ORMapper -- why can't you just do this thing that would make my code go from 3 lines to 1 line, even though it will make other situations far worse -- that's not simplicity to me. -
Yes Virginia, You Can Have Multiple Server Forms in ASP.NET
A current article in MSDN Magazine by a respected author is just wrong -- you can have multiple server forms in ASP.NET, and they can post to other pages. For those of you that still aren't aware of this, my WilsonWebForm has been around for quite some time, and its been totally free and open source for a while now too:
The ASP.NET WilsonWebForm enables Multiple Forms and Non-PostBack Forms, finally allowing you to overcome this built-in ASP.NET restriction. This is a real Server Form that supports WebControls, ViewState, and Events, as well as the Action attribute to Post to other pages/sites. The only limitation is that Validation controls are not supported, but a single regular server form can still be used at the same time. The typical usage is to continue to use the regular server form for the main page content, with validators, while using the WilsonWebForm for small side forms for things like search, login, or preferences. The source code of this control is available in both C# and VB.NET, along with a simple demo application that fully show's how to use it.
I can probably even update it to support validators in ASP.NET v2, since the problem was only the fact that the ASP.NET model assumed all validators we're scoped to the whole page, but now with ASP.NET v2 there are validation groups -- so maybe I'll get around to looking at this, or someone else can since its open source. :)
Note: I do agree that the ASP.NET single-form approach simplifies development and it should not be discarded lightly just because you can. But the fact is that all web browsers do support multiple forms (can someone say "standard"), they do make some things easier (can someone say multiple default buttons without javascript), and they are sometimes even required (ever need to post to an external site). So while I applaud the ASP.NET team for trying to simplify things, I do not agree with the approach that completely eliminates the use of a wide-spread standard approach that is sometimes even required -- all in the name of simplicity. Its actually almost funny watching them now add back some work-arounds for cross-page posting, default buttons, and validation groups -- things that would all have automatically been supported in the first place. :) -
Tim Haines is putting up $150 to get some AJAX brainstorming underway
Tim Haines is conducting a "blogversation" to get people brainstorming some ways to use AJAX with his e-commerce store. The interesting thing to me is the incentive -- he's putting up a $150 Amazon voucher to the "winner". See his blog post for the rules if you want to compete, and if nothing else leave a comment for one of the participants as your "vote". Sure I think AJAX is cool (just like it was 5-6 years ago when some of use were doing it without the fancy name), but I'm more intrigued by Tim's method here than anything else -- will this result in some novel ideas?