ASP.NET 2.0 hits ZBB

I don't know about you, but I am eagerly anticipating the beta 2 release of ASP.NET.  Why, you say?  Because it's the one that contains a go-live license.  The go-live license gives the ability for production systems to use the technology outside of the development environment.  Now I'm not suggesting that a beta 2 release is suitable for every production environment.  That would be patently silly.  However, there are some instances where running a beta version in production is not a big deal.  Like when we redesign the ObjectSharp web site in ASP.NET 2.0.  Which will be done as soon as the go-live license is received.  So you understand my desire to get to beta 2.

Scott Guthrie, the source of much goodness about the inner workings of the ASP.NET 2.0 development team, announced that beta 2 hit zero bug bounce this past Saturday. In terms of release dates, it means that we're probably looking at 8-10 weeks from now.  I'm keeping my fingers crossed.

An Update on Whidbey/Yukon Release Dates

In case you missed it, in this article key microsoft executives are quoted as saying that Whidbey and Yukon are still slated to ship together but that won't be by end of June as earlier stated. They are now estimating that “summer” is a better statement of expected arrival. This may align itself nicely with the PDC 2005 September date. It sounds like both teams blame each other, but really, a lesson can be learned here for all of us: Cross product integration means longer delivery cycles. This is going to be a tough nut for our industry to crack moving forward, not just Microsoft. Is that what SOA promises?

An offer you can't refuse

Tomorrow is Halo2 day.  And why would you want to spend the evening being shown the goodness that is Visual Studio Team System by my colleague Barry Gervin?  Because at the end of it, you get a change to win not only an XBox console, but also a copy of Halo2.  Check out Barry's post for more information.

Visual Studio Team System and XBox/Halo 2

What does project management, test management, defect tracking, build servers, methodology, automated testing, code coverage, and software diagramming have to do with Halo 2? I'm not sure really, but if you want both - then you need to come to the Toronto Visual Basic User Group meeting tomorrow night. I'll be doing a “powerpoint free” drive through of Visual Studio Team System AND raffling off an xbox console and a copy of Halo 2, worth about $270.  More details here:

Refactoring for VB.NET 2005 Going Away?

Well, not completely.  You have to read a little bit into this post, but it appears that the only support for refactoring in VB.NET Whidbey is the Rename Symbol function. To me, this means that one of the major differences between C# and VB.NET in Whidbey will be refactoring support, as C# Refactoring implements a few more functions. 

By the way, this shouldn't completely surprise anyone.  Check out the following post from a year ago.  It describes the refactoring features that C# Whidbey will support (subject to change, of course).  But in one of the comments from Scott Wiltamuth (a C# Product Unit Manager) it is suggested even then the VB.NET might not get much more than Rename Symbol. 

Very prescient.

Random ASP.NET AppDomain Restarts

Are you having a problem with apparently random application restarts in your ASP.NET application?  Does your session information mystically disappear with no discernable pattern?  Well, the following may help you out.

One of the things that ASP.NET does to help make it easier for developers to modify running web sites is to keep an eye on files that are part of the virtual directory.  If you drop a new version of a DLL into the bin directory, it takes effect from the next request on.  If you make a change to an ASPX file, it too is detected and becomes 'live' with any subsequent request.  No question that this is useful functionality.

A little known fact about this process is that ASP.NET is also aware of the amount of memory that maintaining two versions of the same assembly takes.  If changes were allowed to be made without a restart, eventually it could become detrimental to the overall performance ogf ASP.NET. To combat this, ASP.NET also tracks the number of files that are changed and after a certain number, performs an Application Restart.  As with any other restart, this causes the current session information to be lost.  By default, the number of changes before a restate is 15.  To modify this, you can change the numRecompilesBeforeApprestart attribute in the machine.config file.

While all of this is useful information, there is a small twist that can make our life more difficult.  The files that ASP.NET is watching while looking for a change is not limited to those with an .aspx extension. In fact, it is any file in the virtual directory.  Also, the name of the setting implies that the Recompiles are what is being counted.  It's not.  What is being counted is the number of files that change.  Or, more accurately, the number of changes to any file in the virtual directory. 

How can this cause problems?  What if you were to put a log file into the virtual directory of a web site.  What if that log file were opened and kept open while the information was written to it.  When that log file filled up, it is closed and a new one opened.  Of course, this close counts as a file change.  That would mean that after 15 log files are created (assuming no other changes to the web site), the virtual directory would automatically reset.  And since the amount of information written to the log file will be different depending on which pages/web methods are called, the frequency of the reset is dependent on factors that are not immediately apparent.  Imagine the joy of trying to discover why ASP.NET applications are being randomly reset without the benefit of this blog.

The moral of this story:  Don't put any non-static files into an ASP.NET virtual directory. My good deed for the day is done. 

Moving Data Across Service Boundaries

Yet another question that has come across my inbox more than once in the past week.  Which is a good enough reason to become the topic of a blog.  The question:

"Can a SqlDataReader by return by a web service method?"

The short answer:  No

If you attempt to do so, you will get an InvalidOperationException indicating that the SqlDataReader could not be serialized because it doesn't have a public constructor.  And while that is the technical result, the true reason is slightly different.

The SqlDataReader class is stream based.  That is to say that the connection to the database that feeds the SqlDataReader is kept open and busy for as long as the reader is working with data. If an instance of SqlDataReader were to be returned from a web service method, the client would attempt to do a Read.  Which would use the connection to retrieve data from a database that is no longer around.  And certainly not where the connection expects it to be.  Not a situation that's amenable to success.

Assembly Reference Resolving in Visual Studio.

I got a question today about a problematic assembly references during a build of a large project.

Visual Studio projects have a user file (*.csproj,user, *.vbproj.user) that stores a “References Path”. You can edit this list of paths in your project properties dialog and it works like a PATH variable.

The twist comes in when you add a reference to a project. The IDE creates a relative formed path to the assembly you picked in the add reference dialog and places that as a “hint path” in the .csproj/.vbproj file.

So imagine you have some carefully crafted hint paths in your project file references, and no references paths in your user file. It's still possible, for your assembly to not be found where you expect it.

Did you know that VS.NET will automatically add References Paths for you as part of it's build process. Let's say you have a list of references in your project. As VS.NET iterates through the list of them one at a time, it will first check the references path. If the assembly is not found, it will use the hint path. If it finds it with the hint path - it will take the fully qualified path to that assembly - and put it in references path of your user file. When it gets to the next assembly it will check all those references paths - including the one it just automatically added.

What happens if you have multiple copies of your referenced dll hanging around? It could find one other than the one you referenced in your hint path.

This is all pretty rare to happen, but if you are like some folks who use Visual Studio itself as your build server (not NAnt) and as a matter of practice you delete your .user files as part of that build (with the predefined reference paths), you could find yourself in hot water. The only solution in this mixed up process is to make sure you don't have multiple copies/versions of your referenced assemblies lying around. Or better yet, use NAnt.

My head-shaking moment for the day

Talk about telling a fascinating story.  In Scott Guthrie's most recent post, he continues on with a description of the testing process for ASP.NET.  100,000 test cases?  Yawn.  500,000 test scenarios?  Sure it's a big number, but what have you done for me lately. 

But his description of Maddog had my jaw hitting the floor.  An application that automatically formats and re-images systems.  And builds on them And coordinates test results.  Now that's something you don't see every day.

A look inside the process

For the past few months, I have been working as part of a large team of developers working on the new release of a product.  By large, I mean that there are probably over 100 working on various pieces of the code.  Going through the process has given me a great deal of respect for the issues that must face any large team of developers. For some reason, the efforts that must be going on at Microsoft as they prep for Whidbey, Longhorn, et al came to mind. Check out the following post by Scott Guthrie about the process that the ASP.NET team is going through as they get ready for Whidbey Beta 2.  Quite enlightening.