To continue the last post about the //BUILD/ Conference, what else is new? What should you look at now? A few things stand out and I will go through them in order.

See Function Return values in debugger

For F# or any functional language, return values of functions are pretty crucial to be able to see when you debug your code or else you are sort of robbed of the idea of a debugger. Of course, you do have less code and fewer bugs per user story in functional languages vs imperative languages in general, so debugging probably isn’t as important, but the fact that you had to change your code to be able to double check return values must have been a huge pain. The point is, now in VS2013 Preview, when you step past a return statement, you will see the return value in the Autos window as well as being able to access it in the Immediate windows as $ReturnValue. I know I missed it in C#, it must have been super annoying for our functional friends. The takeaways are YAY and  – try F# (still near the top of my to-do list).

64-bit Edit & Continue

ORLY? I will be happy to see the 64-bit dialog box go but would have been happy to just have the debugging stop immediately when somebody tries to type in a code window. That probably indicates that the programmer knows what’s wrong and needs to make changes, not that they would like to go full VB3. To me it’s just embarrassing to see VS handle 64-bit as if it was magic. There should be no difference for a real programmer how you handle 64 or 32 bit (beyond the obvious, but that’s a five minute conversation among stakeholders over coffee) and the fact that the segregation remained is a bit of an embarassment.

ADO.NET Connection Resiliency

EF/ADO.NET Connection resiliency. When you use SQL Database in Windows Azure, you will notice that you only get a brief window of connectivity so as to not waste server resources. This is brilliant and should have been the default on your vanilla SQL Server back in the nineties as well, it would have given us less sucky client / server apps back in the day, but the point is the folks over at ADO.NET now gave us connection resiliency, which means your connection autoresumes when you remember to access your database again. This means simpler code in your app and the database abstraction layer also abstracts connection failures, the way $HigherPower intended.

Hosting and Runtime Features

IIS App Suspension – Another Azure-derived feature is that they will allow web apps to run, but to be suspended in its current state when it has been idle for a while. This feature is available in IIS 8.5, Windows Server 2012 R2 Preview.

Large Object Heap compaction – the Large Object Heap can be now compacted as part of the 2nd generation GC run, as in a full stop-the-world GC, so use carefully. You will need to use a separate API to invoke this feature, but if you are having problems with the Large Object Heap not being compacted, you are probably aware of that and are prepared to add a line of code.

New runtime features that will affect you without you doing anything include automatic multi-core support to make app startup time faster and ASP.NET apps and also the fact that you will get Windows Updates of the .NET framework with precompiled native images. In previous versions of Windows your .NET apps will JIT mscorlib.dll et c as you run them when the dllis different from the cached binary installed with Windows, VS or a service pack.

Cadence – pleasing both camps

A huge deal is that the .NET Framework will go full Ubuntu style versioning, with many small incremental changes, with big bang Long Term Support versions made for the enterprise. They wouldn’t call it “ubuntu style versioning”, so I did it for them. They have implemented this by deploying new features as NuGet packages continuously, while they collate mature features and include them in big releases. This is pretty significant and a great decision.

As the returning reader may have noticed I have used the Model-View-Controller framework for ASP.NET again and again in the few posts I have produced so far. This is because unlike the ASP.NET standard framework, the MVC framework allows and simplifies actual programming in lieu of VB3 style component hell. To show proof of my benevolent and magnanimous generosity, I have however decided to let go of my loathing for the standard ASP.NET setup and actually try to make something out of it, utilizing every bit of it just to see if it can be used for anything real.

Orientation

There is a plethora of Server Controls, at least one for every imaginable application known to man. The idea is that when you have a business problem you want to solve, you simply write <asp: in front of a general description of your problem. switch to Design view and edit the properties of your server control.

Example:

I would like to create a wizard that allows me to create a ASP.NET Forms user account… Let’s try it:

Hmm… that would mean…  ‘<asp:’ and then, let’s try .. ‘ CreateUserWizard />’ … Switch to design view… Woah!!!

This is just one example, but the amount of server controls  out there is limitless and you can watch your ViewState go from 0 – 60MB in seconds with ease, building your website with themeable data bound server controls fully integrated with your web.config.

I have seen people dismiss the MVC framework as it means ‘a move away from Server Controls back to spaghetti code’. I find this unfathomable. Server controls try to abstract away the fact that this the application runs on a web server which is inherently stateless. Through the use of ViewState and other constructs the server controls use a variety of dirty tricks behind the scenes to hide this basic fact from the confused developer. In practice however I have never seen a case where this abstraction has been successful and there have always been places in a web application that have deteriorated into near-ASP Classic monstrosities.

I have always put the blame for this squarely on the shoulders of the ASP.NET Server Control concept.  However, I have decided to actually put my money where my mouth is on this one and actually make a serious effort to build something usable out of a bucket of server controls and see if it can actually be done. For real. All the way. 

Example

I am going to build an application that uses the following aspects of the ASP.NET basic features:

• ASP.NET Forms Authentication
• Themes
• Profiles
• Wizard
• DataGrid
• GridView
• DetailsView
• DataGrid
• MultiView
• … any other controls that I find irresistibly disturbing

I have a useful scenario which I have been working with, however I will not release the details of this yet, and I will only briefly discuss the actual application. The point of this exercise is whether or not the controls are useful, how difficult they are to manage in a professional way and the amount of ugly code that is necessary to patch things up.  I  will go through this anxiety ridden journey on my own and spare you most of the details and only report back when I need to vent or when I, maybe, reach points of success. I do this so that I will reach a point where I can disrespect the ASP.NET framework with greater authority. I admit there is a risk I may come out on the other side a changed man, a born-again VB3 fanatic, touting opaque server logic, horribly leaky abstractions and other features as reigning supreme over so-called real programming, we never know.