Clean Web.Config Files (VS 2010 and .NET 4.0 Series)

Clean Web.Config Files (VS 2010 and .NET 4.0 Series)

This is the first in a series of blog posts I’m doing on the upcoming VS 2010 and .NET 4 release.

Today’s post is about an admittedly small, but I still think kind of nice, change coming with ASP.NET 4.0: clean, simple, web.config files. 

You’ll encounter this improvement the first time you do a File->New Project within Visual Studio 2010 and create an empty ASP.NET 4.0 Web application (which is why I thought it might be appropriate to-do as the first post).

Web.config files in .NET 3.0 and 3.5

Over the last few releases, the web.config files within new ASP.NET projects have steadily increased in size. For example: the default web.config file that is added to a new web project in Visual Studio 2008 SP1 is now some 126 lines long, and contains everything from tag definitions to definitions of handlers and modules to be included in the ASP.NET HTTP pipeline.

This increase in size is because .NET 3.0 and .NET 3.5 use the same CLR and machine.config configuration file as those shipped with .NET 2.0 – and simply add and update assemblies in the framework when they are installed.  To avoid the risk of us accidentally overwriting customized settings within the original 2.0 machine.config on the machine, we didn’t register the tag definitions, handlers and modules that shipped with the new ASP.NET functionality that came with the .NET 3.0 and .NET 3.5 versions.  Instead, we defaulted to having new projects register these settings within the application’s local web.config file instead.  This was safer – but caused the web.config files to increase and become more complicated and harder to read.

Web.config files in .NET 4

.NET 4 includes a new version of the CLR, and a new .NET 4 specific machine.config file (which is installed side-by-side with the one used by .NET 2, .NET 3 and .NET 3.5).

The new .NET 4 machine.config file now automatically registers all of the ASP.NET tag sections, handlers and modules that we’ve added over the years, including the functionality for:

  • ASP.NET AJAX
  • ASP.NET Dynamic Data
  • ASP.NET Routing (which can now be used for both ASP.NET WebForms and ASP.NET MVC)
  • ASP.NET Chart Control (which now ships built-into ASP.NET V4)

What this means is that when you create a new “Empty ASP.NET application” project in VS 2010, you’ll find that the new default application-level web.config file is now clean and simple:

The first config section above just tells ASP.NET to enable debugging by default for the application, and indicates the version of .NET that Visual Studio should target when it provides intellisense (VS 2010 supports multi-targeting – and the intellisense within the IDE will automatically vary depending on which version of the framework you are targeting).

The second config section indicates whether to use “integrated” mode when running the ASP.NET application within IIS7 – which controls whether to run ASP.NET HttpModules for all requests within the application or just for the ASP.NET specific URLs.  We enable this by default at the application level web.config file for new applications – since for compatibility reasons the default IIS7 setting registered at the machine-wide is to run modules only for ASP.NET URLs (and not for all requests).

Summary

The simplified web.config file in .NET 4 is an admittedly small change – but I think a nice one nonetheless, and one which makes the default experience when you create a new ASP.NET application a little cleaner and more approachable.

In the posts ahead I’ll be delving into many of the more substantial improvements coming with ASP.NET 4. (as well as a few more of the “small but nice tweaks” coming too)

Hope this helps,

Scott

VS 2010 and .NET 4 Series

VS 2010 and .NET 4 Series

Over the next few months I’m going to be doing a series of posts that talk about some of the cool things coming with the VS 2010 and .NET 4 release. 

VS 2010 and .NET 4 are the next major releases of our developer tools and framework.  Together they contain a ton of new functionality and improvements that I think you’ll really like, and which make building applications of all types easier, faster and better.  The improvements range from nice small tweaks to major, major enhancements – and can be found across the .NET Framework, the languages, and the IDE.

We are still a little ways off from the “Betat2” release of VS10 and .NET 4 – which is the version I’m going to be basing my posts on.  I wanted to start ahead of the actual Beta2 release, though, because there are a lot of things to do blog posts about (and it is fun to get a chance to blog about a few of the new Beta2 things before everyone else does! :-).

I will update this page with links to the individual posts I do as I publish them along the way:

Hope this helps,

Scott

“Pro BizTalk 2009” Book is Finally Available

“Pro BizTalk 2009” Book is Finally Available

Yeah! Pro BizTalk 2009 is now published and available. It was an interesting project to be involved with (even in just a small way). You can find it on Amazon now at http://www.amazon.ca/Pro-BizTalk-2009-George-Dunphy/dp/1430219815/ref=sr_1_2?ie=UTF8&s=books&qid=1251208723&sr=8-2

I wanted to thank Richard Seroter who acted as the technical reviewer for my chapter. I also wanted to point out his great book “SOA Patterns with BizTalk 2009” (in case anyone hasn’t already seen it).

Cheers and keep on BizTalking

Peter

LIDNUG: Free Online Virtual Chat with Me Tuesday Morning

LIDNUG: Free Online Virtual Chat with Me Tuesday Morning

A few months ago I did a free online chat hosted by LIDNUG (Linked .NET Users Group) that was a lot of fun (and which people seemed to really like).

This Tuesday (August 25th) I’m doing it again from 9am-10:30am (PST – Pacific US time). 

The agenda format is open and anyone can join in.  Basically you type your questions and then you can listen to me online answer as many of them as I can.  Any question is fair game! 🙂

Click here to register to join the talk for free.

Hope to chat with some of you soon!

Scott

WCF Essentials Chapter 2 – WCF Templates and Tools

WCF Essentials Chapter 2 – WCF Templates and Tools

We’ve just published Chapter 2 in the WCF Essentials series.  This new chapter is about WCF Templates and Tools.

There are several Visual Studio templates available to help you to be more productive with WCF. In addition there are a few essential tools – some that are most useful as you are getting started, and others that you will use more regularly. In this chapter Michele Bustamante summarize the available project templates and when to use each; discusses some side-effects and workarounds; and discusses the limitations and benefits of the core WCF tools.

And be sure to participate in the forum discussion thread for this chapter.

BizTalk Azure/Cloud Adapters are being born

BizTalk Azure/Cloud Adapters are being born

Folks I recently came across this site on codeplex – http://btsazureadapters.codeplex.com

Where a hard working Danny(not sure of further details) has created a send and receive
adapter for the cloud.

The adapter surface and publish the required information into the cloud so for e.g.
your endpoints show up publically in the .NET Servicebus domain – we can do this through
the apis, but it’s nice to have them all wrapped up.

There’s even some great piccys as well (just over look the ’Microsoft Confidential’
at the bottom 😐 – I did ping him over this.)

BizTalk Adapter for Live Framework.jpgBizTalk Adapter for .NET Services.jpg

The adapters are WCF based adapters, meaning they will run in or outside of BizTalk
using the .NET LOB Adapter SDK Framework.

As a Plan B to this – you can always use a Custom WCF Adapter with the basicHttpRelayBinding
or netTcpRelayBinding
to punch through to the cloud.

I reckon this will be a very exciting area going forwardkeep your eyes peeled.

Go and grab the bits and start playing 🙂

Microsoft StreamInsight and BizTalk Server – Preliminary Thoughts

Microsoft StreamInsight and BizTalk Server – Preliminary Thoughts

Richard Seroter talks here about feeding BizTalk events into StreamInsight or receiving events out as BizTalk messages. I spent a little time considering the possibility of using StreamInsight in conjunction with BTS messaging infrastructure by building custom BTS adaptersor pipeline components that directly hook into StreamInsight. A preliminary look through the code samples (the best way, currently, of understanding this new engine, given that the CTP documentation is somewhat sparse) suggests to me that this is probably not the way to go. As I understand things, there seems to be an impedance mismatch between BTS messaging and the concept of an event stream. The closest thing BTS offers to an ’event stream’ is its concept of a batch, used by adapters to submit multiple messages to BTS via the transport proxy as a single transactional interaction. I say ’closest’, but in reality a BTS batch is quite different to an event stream, and consequently a BTS adapter is not at all similar to a StreamInsight adapter. Event streams may be continuous over extended periods of time, and don’t naturally fit a transactional model.
Of course, in constrained circumstances, it may be possible for the two models to co-exist.The sample TextFile input adapter, for example, reads a single CSV file and converts its contents into a stream of events. A second CSV files would be processed as a separate event stream. In this case, StreamInsight could co-exist nicely with a BTS pipeline that processes each CSV file as a separate message. However, in other scenarios, you would have to ensure that a StreamInsight adapter continues to run over an open-ended number of BTS batch submissions. Worse still, how would you cope with multiple instances of the same Receive Ports running in different host instances? Somehow you would have to share a single event stream between those multiple BTS host instances.
So, I think that as far as BTS is concerned, the obvious places you might use StreamInsight are:
a) outside of BTS, feeding events to a BTS Receive Port
b) from within a BTS orchestration, probably exploiting the convoying and long-running
transaction facilities of the orchestration to handle submission of event messages to
a single event stream.
c) outside of BTS, receiving events emitted by a BTS Send Port.
A special case of a) would be using StreamInsight in conjunction with RFID Server. Remember that RFID Server can be used for more than just RFID devices.c) would, I think, prove to be a rare scenario.b) and c) would both significantly compromise the raw performance of StreamInsight by inserting the relatively high latencyBTS message box in front of a StreamInsight input adapter.
Having spent little time yet with the CTP, I reserve the right to make mistakes! Maybe I have not properly grasped the StreamInsight model, but this is how it looks to me at present.