How to set an IIS Application or AppPool to use ASP.NET 3.5 rather than 2.0
Sponsored By
A question that comes up a lot is this: How do I tell my IIS Application or Virtual Directory to use ASP.NET 3.5 rather than ASP.NET 2.0?
Folks often go into the IIS6 or IIS7 manager and setup an AppPool and see a properties dialog like this, and when the pull down the option, they often expect to see .NET 3.0 and .NET 3.5 in the list and it's not there, and they freak out, rightfully so.
Here's an explanation of why this is confusing, and hopefully by the end, it won't be confusing anymore.
Marketing
This is where marketing and reality part ways. I didn't initially like the naming, because I assumed that each major version of the Framework meant a new CLR, but it's growing on me as I understand it more. I get now why they named them this way. Additional fundamentally new functionality has to be named something.
.NET 2.0
The meat of .NET is in %windir%\Microsoft.NET\Framework\v2.0.50727. That's where, along with the GAC (Global Assembly Cache) all the libraries and compilers you know and love live. When folks ask "where is .NET" I usually start here.
.NET 3.0
The addition of .NET 3.0 didn't mean new compilers or a new CLR. Instead, it's three major new libraries: WCF (Windows Communication Foundation née Indigo), WPF (Windows Presentation Foundation née Avalon) and Windows Workflow or WF.
Bottom line: Installing .NET 3.0 doesn't fundamentally change your system in any way you should fear. Your 2.0 apps still run on a system with 3.0 installed. They are 2.0 apps using the 2.0 compilers and 2.0 CLR.
Try this. If you go into Visual Studio and File | New | Project (or Web Site), take note of the drop down in the upper right corner.
Select ".NET Framework 3.0" and make a new "WCF Service" take a look at the web.config. Note that it's pretty conventional, and should look like a typical .NET 2.0 ASP.NET application with a few additional.
Basically, remember Framework version != CLR Version. If you configured an IIS Application to use .NET 2.0, you're talking about the 2.0 CLR. WCF Applications use the .NET 2.0 CLR with the new 3.0 WCF libraries.
- .NET Framework 1.x = CLR 1.x
- .NET Framework 2.0 = CLR 2.0
- .NET Framework 3.0 = CLR 2.0
- .NET Framework 3.5 = CLR 2.0 + (C# 3.0 | VB9)
You can also use the new 3.5 compilers and the 3.0 libraries, of course as well. Each subsumes the previous as seen in Tim Sneath's fine stacked diagram above.
In your new app's web.config, there's a <system.serviceModel> section that is WCF specific, but otherwise the web.config looks pretty 2.0 typical.
.NET 3.5
The marketing term ".NET Framework 3.5" refers to a few things. First, LINQ, which is huge, and includes new language compilers for C# and VB. Second, the REST support added to Windows Communication Foundation, as well as, third, the fact that ASP.NET AJAX is included, rather than a separate download as it was before in ASP.NET 2.0.
There's a few other things in .NET 3.5, like SP1 of .NET 2.0 to fix bugs, but one way to get an idea of what's been added in .NET 3.5 is to look in c:\windows\assembly. Here's just the 3.5 versioned assemblies in the GAC (Global Assembly Cache).
Also, looking in %windir%\Microsoft.NET\Framework\v3.5 we can see the new compilers, MSBuild Target files, etc.
So, getting to answering the original question, try this experiment.
Go into Visual Studio and make a .NET 2.0 Web Site. Once it's loaded up, note your web.config. Next, right-click on the project and select Properties. Under Build, select 3.5 Framework.
Now, load up your web.config and notice the changes that just occurred. There's some new handlers that are added to support Ajax and some new ASP.NET Features, but the really important stuff is the <system.codedom> and the newly added assemblies in the assemblies section.
<compilation debug="false">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
warningLevel="4">
<providerOption name="CompilerVersion" value="v3.5"/>
<providerOption name="WarnAsError" value="false"/>
</compiler>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
warningLevel="4">
<providerOption name="CompilerVersion" value="v3.5"/>
<providerOption name="OptionInfer" value="true"/>
<providerOption name="WarnAsError" value="false"/>
</compiler>
</compilers>
</system.codedom>
There's the magic. Well, not really magic, and there's nothing hidden. This where your web site is told what version of the compiler to use, and the new supporting libraries.
This is where you tell ASP.NET to use .NET 3.5, not in IIS. IIS AppPools know about CLR versions, not Framework and compiler versions, those are set by the application.
Now, this is just my opinion, but I like to name my AppPools in IIS like this...
...which looks the way my brain thinks it is even though it's not reality. I keep my 1.1, 2.0 and 3.5 applications all running under the same instance of IIS, but each in their own AppPool. Note again, the there's nothing keeping me from having 3.5 apps under my 2.0 AppPool, I just keep them tidy on my own.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
I had posted on the same issue but this is much more complete :)
Click <a href"http://blog.lyalin.com/2008/02/iis-60-and-net-35-website-configuration.html">here</a> to view my post on this subject
Click <a href"http://blog.lyalin.com/2008/02/iis-60-and-net-35-website-configuration.html">here</a> to view my post on this subject
Looking at that diagram, and the whole situation really, makes me a bit sad. It would be interesting if you wrote something about ".NET from the ground up" or ".NET without any legacy stuff," in the vein of "what would the framework/class library look like, if we got rid of all the cruft, and learned from our mistakes?"
I'm thinking... kill all non-generic collections and all the infrastructure built on them (CookieCollection? MatchCollection? Seriously.), maybe fix some other collection stuff in light of LINQ; XLinq replacing all of the XmlDocument stuff; WCF replacing asmx web services; WPF replacing WinForms?; and of course mundane stuff like DateTimeOffset instead of DateTime. It'd be so... refreshing :P.
That said, it's a testament to the guys in charge that whenever a new version introduces something important, I am compelled to start using it because it will make my life so much easier. (Generics and LINQ are the obvious examples here.) So, good job for continual improvement and even continual revolution!
(I'd be happy to attempt such a writeup myself, but I'm sure I would have a less complete perspective and much less interesting opinions/anecdotes to share.)
I'm thinking... kill all non-generic collections and all the infrastructure built on them (CookieCollection? MatchCollection? Seriously.), maybe fix some other collection stuff in light of LINQ; XLinq replacing all of the XmlDocument stuff; WCF replacing asmx web services; WPF replacing WinForms?; and of course mundane stuff like DateTimeOffset instead of DateTime. It'd be so... refreshing :P.
That said, it's a testament to the guys in charge that whenever a new version introduces something important, I am compelled to start using it because it will make my life so much easier. (Generics and LINQ are the obvious examples here.) So, good job for continual improvement and even continual revolution!
(I'd be happy to attempt such a writeup myself, but I'm sure I would have a less complete perspective and much less interesting opinions/anecdotes to share.)
I've seen before where companies use odd numbers for patches and even numbers for functionality. So, 2.0 SP1 should have been 2.1. 3.0 should have been 2.2. 3.5 should have been 2.4 and so on and so fourth.
Good explanation. Thanks Scott! The versioning definitely trips people up.
@Domenic: You write "continual revolution" - I think of it more like a continual evolution; That’s why everything that is released to customers sadly must be backward compatible.. Me so think MS would be happy if they didn’t have to support legacy windows :-)
Of course I vote yes to revolution – but sadly I can't, our customers would lynch me real bad.. I think MS does a great job on both parts – and we should be happy that .NET is not an evolution of Quick Basic – but a rather "new" evolution.
Of course I vote yes to revolution – but sadly I can't, our customers would lynch me real bad.. I think MS does a great job on both parts – and we should be happy that .NET is not an evolution of Quick Basic – but a rather "new" evolution.
Most .NET developers know this, but in my experience most server administrators are completely confused by this. Thanks for the in-depth blog on the subject. This will be great to forward to my server administrators.
I agree with Bob that your tip for running .NET 3.0 and 3.5 apps in IIS could have been summed up in a single sentence, but I really enjoy hearing the why and how of things. Thank you for taking the time to lay it out so simply!
Yes, it took me also some time to understand the naming/versioning in .NET, but it actually makes sense. MS needs however to cleanup a lot of documentation and legacy UI in order to use the terms "CLR 2.0" where it makes sense. The confusion comes from the fact that with frameworks 1.x and 2.x, "framework" and "CLR" we used without much thinking. Now, it matters.
"Additional fundamentally new functionality has to be named something"
And it is: WCF, WPF, LINQ, etc.
I do not think they need to be named something collectively. I do not think LINQ needs to be tied to AJAX under a common ".NET Framework 3.5" name. I would not have any problem describing my application as being built on the .NET 2.0 platform, using the Microsoft LINQ and WCF libraries. In fact, I think it would be incredibly clearer and communicate more to other developers, system administrators, management, and enterprise architects that dictate standards.
You seem to agree that it is driven by marketing. Can you expand on why you think this is the right decision (it is growing on you)?
And it is: WCF, WPF, LINQ, etc.
I do not think they need to be named something collectively. I do not think LINQ needs to be tied to AJAX under a common ".NET Framework 3.5" name. I would not have any problem describing my application as being built on the .NET 2.0 platform, using the Microsoft LINQ and WCF libraries. In fact, I think it would be incredibly clearer and communicate more to other developers, system administrators, management, and enterprise architects that dictate standards.
You seem to agree that it is driven by marketing. Can you expand on why you think this is the right decision (it is growing on you)?
Good post, but it should haven't been necessary. If it takes a 4 page post to explain why you don't need to set a dropdown to 3.5, then something went wrong somewhere. Why not just fake it and put a dummy 3.5 selection in the dropdown. I'm sure thousands of developers/admins would have just made that setting and moved on instead of scratching their heads, re-installing the 3.5 framework, then googling the subject.
I'm a big .net fan, but I'd prefer not to have to know the details the developers went through in developing it.
I'm a big .net fan, but I'd prefer not to have to know the details the developers went through in developing it.
@Nick N:
That resonates with my experience as well. This is why we were so thankful to get onto IIS7/Win2008, because web server configuration is now 100% within the developer's domain. Which is the way it should be, IMHO. *
@Scott:
Nick N raises a very interesting point about delegation of responsibilities to development versus operations. I think you could write an entire series of blog posts on the topic of how to appropriately divide ASP.NET administration duties.
* Note: this is not a knock against server administrators - they are a scary smart group and need to keep a metric ton of obscure pieces of data in their heads at all times. So I am in support of making their lives easier.
...but in my experience most server administrators are completely confused by this.
That resonates with my experience as well. This is why we were so thankful to get onto IIS7/Win2008, because web server configuration is now 100% within the developer's domain. Which is the way it should be, IMHO. *
@Scott:
Nick N raises a very interesting point about delegation of responsibilities to development versus operations. I think you could write an entire series of blog posts on the topic of how to appropriately divide ASP.NET administration duties.
* Note: this is not a knock against server administrators - they are a scary smart group and need to keep a metric ton of obscure pieces of data in their heads at all times. So I am in support of making their lives easier.
Good, now I have some documentation I can show my boss and coworkers. I'm curious why I needed to install the Asp.net AJAX extensions standalone installer (though it's included in .Net 3.5) inorder to install the AJAX templates for VS2008. I thought I didn't need to install those separately anymore. Also, it's nice that there is a standalone version, as many of our customers still use Windows 2000 servers which .Net 3.x cannot be installed on.
Best ASP.NET and .NET Framework version stack explanation I've seen. Thanks for taking the time.
>> I get now why they named them this way. <<
Really? I still don't.
They upgrade the major version from 2.0 to 3.0 for WCF, WPF and WF but only from 3.0 to 3.5 for LINQ (which you even said is huge), AJAX and new compilers. Seems backwards to me. If anything they should have been consistent and made 3.5 - 4.0. But then, it wouldn't look good for developers to request upgrade from 2.0 to 4.0 would it...
Really? I still don't.
They upgrade the major version from 2.0 to 3.0 for WCF, WPF and WF but only from 3.0 to 3.5 for LINQ (which you even said is huge), AJAX and new compilers. Seems backwards to me. If anything they should have been consistent and made 3.5 - 4.0. But then, it wouldn't look good for developers to request upgrade from 2.0 to 4.0 would it...
Hey, i was having difficulties in setting up IIS7 for Asp.net 3.5, can you tell what would be the handler mapping for IIS7 interms of running MVC app in IIS.
Some people have commented that this post was pointless but I was just happy to finally read this blog and find something I already knew! I usually glaze over when trying to keep up with Scott's mind haha
It's useful to know about IIS and web.config for .NET 3.5. Thank for you post.
This was a really helpful post. I didn't even know about .NET 3.0; I thought it jumped right to 3.5.
Just one question though: I know most of the new stuff in C# 3.0 are done at the compiler level, but I thought Extensions methods (and therefore LINQ) required modifications to the CLR and therefore .NET 3.5 introduced a new CLR as well. If that isn't the case, I would love to read a post (either one you write in the future, or an existing one you can point me to) about how Extension Methods actually work. Have they been in the CLR 2.0, and just finally been made available in C# 3.0?
Just one question though: I know most of the new stuff in C# 3.0 are done at the compiler level, but I thought Extensions methods (and therefore LINQ) required modifications to the CLR and therefore .NET 3.5 introduced a new CLR as well. If that isn't the case, I would love to read a post (either one you write in the future, or an existing one you can point me to) about how Extension Methods actually work. Have they been in the CLR 2.0, and just finally been made available in C# 3.0?
Given your explanation above is seems a trivial matter to support mutli-targeting between .net 2.0, 3.0, and 3.5. It seems all the developers had to do was manage a few web.config settings and a hard-coded "reference paths" project setting for each framework version. Is there any more to it than that?
I think you could write an entire series of blog posts on the topic of how to appropriately divide ASP.NET administration duties.
+1 for PWillis' suggestion
"If it takes a 4 page post to explain why you don't need to set a dropdown to 3.5, then something went wrong somewhere."
"They upgrade the major version from 2.0 to 3.0 for WCF, WPF and WF but only from 3.0 to 3.5 for LINQ"
Amen. This was clearly a major mistake in the marketing of the framework; I wish Microsoft employees would come out and admit the obvious instead of trying to defend such a colossal fubar.
"Additional fundamentally new functionality has to be named something."
Absolutely it does; it needs to be named something that indicates that it is additional functionality, not a replacement for previous functionality. There is absolutely no justification for naming WCF, WWF, and WPF as ".NET Framework 3.0" when all it did was add a new set of complementary libraries.
Furthermore, if you are going to name a new set of compilers and libraries with a new major framework version (i.e. 3.0 = 2.5, 3.5 = 3.0, which is at least defensible, if not obviously correct), then you must make a distinction between the "Framework" and the CLR. The dropdown in IIS should clearly say ".NET CLR Version" instead of ".NET Framework Version", since that is in fact what it controls: which version of the CLR gets loaded into the AppPool.
I have lost count of how many times I have had to explain this to junior developers (the fact that you felt the need to write this post is evidence that you have had the same experience), and every experienced non-MS developer I have ever talked to has agreed that it should not be this way. As you say in the beginning of your post, "This is where marketing and reality part ways." Why is it a good idea for naming to not reflect reality? Does Marketing have a gun to your head, or do you honestly believe that this tangled mess was the right way to handle this?
"They upgrade the major version from 2.0 to 3.0 for WCF, WPF and WF but only from 3.0 to 3.5 for LINQ"
Amen. This was clearly a major mistake in the marketing of the framework; I wish Microsoft employees would come out and admit the obvious instead of trying to defend such a colossal fubar.
"Additional fundamentally new functionality has to be named something."
Absolutely it does; it needs to be named something that indicates that it is additional functionality, not a replacement for previous functionality. There is absolutely no justification for naming WCF, WWF, and WPF as ".NET Framework 3.0" when all it did was add a new set of complementary libraries.
Furthermore, if you are going to name a new set of compilers and libraries with a new major framework version (i.e. 3.0 = 2.5, 3.5 = 3.0, which is at least defensible, if not obviously correct), then you must make a distinction between the "Framework" and the CLR. The dropdown in IIS should clearly say ".NET CLR Version" instead of ".NET Framework Version", since that is in fact what it controls: which version of the CLR gets loaded into the AppPool.
I have lost count of how many times I have had to explain this to junior developers (the fact that you felt the need to write this post is evidence that you have had the same experience), and every experienced non-MS developer I have ever talked to has agreed that it should not be this way. As you say in the beginning of your post, "This is where marketing and reality part ways." Why is it a good idea for naming to not reflect reality? Does Marketing have a gun to your head, or do you honestly believe that this tangled mess was the right way to handle this?
Domenic, "kill all non-generic collections and all the infrastructure built on them" C# is a strong typed language, you rely on the Framework to handle that for you. Nothing is free!
What I'm wondering is if there will be versioning of things like WPF and WCF....right now there is only one WCF correct? And when an update comes around will it be WCF 2.0 but only runs on .NET 4.0? Or will there be a massive rollup at some point soon?
Ryan
Ryan
I miss the old good days; when we could simply say "this program requires .NET Framework 1.1 (or 2.0 for that matter)."
If you add the extensions ( http://www.asp.net/downloads/3.5-extensions/ ) to the picture, and the separate updates that are going to possibly a specific library (a WPF bug-fix here and a WCP update there), the whole thing feels like a runtime versioning hell.
All the libraries that are provided by Microsoft on top of .NET Framework are great, but when I think of versioning an application against the runtime, it somehow reminds me of Segal's Law: "A man with a watch knows what time it is. A man with two watches is never sure."
If you add the extensions ( http://www.asp.net/downloads/3.5-extensions/ ) to the picture, and the separate updates that are going to possibly a specific library (a WPF bug-fix here and a WCP update there), the whole thing feels like a runtime versioning hell.
All the libraries that are provided by Microsoft on top of .NET Framework are great, but when I think of versioning an application against the runtime, it somehow reminds me of Segal's Law: "A man with a watch knows what time it is. A man with two watches is never sure."
Good explanation! I was a little apprehensive to create a 3.5 application and put it on my server because I too couldn't find v3.5 in IIS (even though I installed it). Being as busy as I am, I just held off until I could find sometime to look into it further.
Now, I feel more confident to convert some of my 2.0 apps into 3.5 apps and push them up to my server.
Now, I feel more confident to convert some of my 2.0 apps into 3.5 apps and push them up to my server.
Bob, yes, I could have said "To Run .Net 3.0 / .Net 3.5 ASP.Net apps, select the .Net 2.0 runtime in IIS." But I really like understanding the why. I don't usually write about the how without covering the why.
Domenic, I hear what you're saying about wanting to kill older stuff, but wouldn't you (or your enterprise/company) be pissed if stuff just stopped working? MSFT has handcuffs on, and they're called backward compatibility. :(
Michael - Yes, multitargeting IS trivial, as you point out, although there is the new compilers on the 3.5 side.
David: You said "There is absolutely no justification for naming WCF, WWF, and WPF as ".NET Framework 3.0" when all it did was add a new set of complementary libraries."...I dunno, WCF is pretty huge and WPF is totally new. Should they have been named ".NET 2.0 + WCF"?
This is a really interesting statement:
In this post I wasn't intending to defend the confusing marketing names. I thought I was pretty clear is saying "this is where marketing and reality part ways." What I am saying is that, after the fact, and after spending years selling .NET 2.0 and .NET 3.0 to my bosses at my last job, that it was easier to refer to it that way than to say "we're using .NET 2.0 plus WCF, plus REST, AJAX and some WPF."
I would say, though, that by naming it this way, it was easier for business people to understand and harder for technical people to understand.
Lemme phrase this another way to try and make my point. Marketing names don't always line up with technical reality, and Microsoft is certainly not the only company that does that, although we do it a LOT. As a technical person I'll always lean towards reflecting reality. For example, we (most of us in the blogosphere) all thought that it was a good move to make Silverlight 2 called 2 and not 1.1, because it felt like a lot had changed.
On the Framework side, though, a developer like us feels that LINQ has changed their lives MORE than WCF, so of course we feel like .NET 3.5 should be called 4.0, because it's bigger and better. However, from a business guy's point of view (like my old CTO or CEO), they can't point their business fingers and heads at LINQ and figure out what business problem it solves. "We're upgrading to 4.0, WHY?" But if we add WS-SECURITY support, etc to a library, changing the Web Services stack completely and enabling a bunch of new business scenarios, business guy says "OK, so 3.0 has Web Services."
I'm not saying I totally agree with it, what I said was explicitly:
Where I was unclear, I think, was when I said "fundamentally new functionality." I should have added "business" or "integration" in there.
Maybe this deserves a whole blog post.
Domenic, I hear what you're saying about wanting to kill older stuff, but wouldn't you (or your enterprise/company) be pissed if stuff just stopped working? MSFT has handcuffs on, and they're called backward compatibility. :(
Michael - Yes, multitargeting IS trivial, as you point out, although there is the new compilers on the 3.5 side.
David: You said "There is absolutely no justification for naming WCF, WWF, and WPF as ".NET Framework 3.0" when all it did was add a new set of complementary libraries."...I dunno, WCF is pretty huge and WPF is totally new. Should they have been named ".NET 2.0 + WCF"?
This is a really interesting statement:
Amen. This was clearly a major mistake in the marketing of the framework; I wish Microsoft employees would come out and admit the obvious instead of trying to defend such a colossal fubar.
In this post I wasn't intending to defend the confusing marketing names. I thought I was pretty clear is saying "this is where marketing and reality part ways." What I am saying is that, after the fact, and after spending years selling .NET 2.0 and .NET 3.0 to my bosses at my last job, that it was easier to refer to it that way than to say "we're using .NET 2.0 plus WCF, plus REST, AJAX and some WPF."
I would say, though, that by naming it this way, it was easier for business people to understand and harder for technical people to understand.
Lemme phrase this another way to try and make my point. Marketing names don't always line up with technical reality, and Microsoft is certainly not the only company that does that, although we do it a LOT. As a technical person I'll always lean towards reflecting reality. For example, we (most of us in the blogosphere) all thought that it was a good move to make Silverlight 2 called 2 and not 1.1, because it felt like a lot had changed.
On the Framework side, though, a developer like us feels that LINQ has changed their lives MORE than WCF, so of course we feel like .NET 3.5 should be called 4.0, because it's bigger and better. However, from a business guy's point of view (like my old CTO or CEO), they can't point their business fingers and heads at LINQ and figure out what business problem it solves. "We're upgrading to 4.0, WHY?" But if we add WS-SECURITY support, etc to a library, changing the Web Services stack completely and enabling a bunch of new business scenarios, business guy says "OK, so 3.0 has Web Services."
I'm not saying I totally agree with it, what I said was explicitly:
I didn't initially like the naming, because I assumed that each major version of the Framework meant a new CLR, but it's growing on me as I understand it more. I get now why they named them this way. Additional fundamentally new functionality has to be named something.
Where I was unclear, I think, was when I said "fundamentally new functionality." I should have added "business" or "integration" in there.
Maybe this deserves a whole blog post.
I wish the framework was more modular...allow me to download WPF as a seperate 'library'...but make .NET 2.0 a system requirement...
I had to talk my network admin off the ledge after I explained the differences in the framework/CLR versioning. I'm still expecting him to slash my tires soon.
I had to talk my network admin off the ledge after I explained the differences in the framework/CLR versioning. I'm still expecting him to slash my tires soon.
Great explanation, I could never find this information when I looked for it. Some of us just really want to know the what and why even of the file and folder layout for the technology we work (and play) with. It was Scott Guthrie who first pointed me out that the reason the web.config was such a mess was that they couldn't put all that new stuff in a default config file, since the CLR still uses the 2.0 config files, even if you use .NET 3.5!
It's weird that the CLR and the config are related like that, if they could do something about that that would be nice. There's bound to be another CLR, right? I mean, they got this far with compiler magic, but adding Ruby support and all that has to result in a 3.0 CLR someday I think.
Also, why is no strict naming in the folders, 2.0.572 followed by 3.0? And under 3.0 WCF is abbreviated while the rest is not? I really prefer a nice (and documented) layout, because I feel lost in the current one, and yes, sometimes you need to be down there, even if it's just to learn.
Good tip about that AppPool, man we really should upgrade our server to 2003...
It's weird that the CLR and the config are related like that, if they could do something about that that would be nice. There's bound to be another CLR, right? I mean, they got this far with compiler magic, but adding Ruby support and all that has to result in a 3.0 CLR someday I think.
Also, why is no strict naming in the folders, 2.0.572 followed by 3.0? And under 3.0 WCF is abbreviated while the rest is not? I really prefer a nice (and documented) layout, because I feel lost in the current one, and yes, sometimes you need to be down there, even if it's just to learn.
Good tip about that AppPool, man we really should upgrade our server to 2003...
Ugh, marketing. Bosses deciding what technology to use because some sales dude pitches 3.0. In the mean time, my boss was saying we need to upgrade to 3.0 but all we do is ASP.NET webforms! I'd like to see the marketing guys explain him that 3.0 is actually 100% nothing to us.
And then comes 3.5 with a new bloody brilliant version of Visual Studio, and I'm having a hard time getting my boss to upgrade us to VS 2008, because "it's just a 3.5 update, and we are already on the 3.0 level, let's wait for 4.0!"
Yeah, great job marketing guys, very smart! Microsoft might sell to bosses, but WE are their users. In the end, because I'm the professional in my company, I have more influence than the sales/marketing guy. All it means, is that I need to explain MORE, so no, I don't appreciate it. Sorry.
/more ranting
Thanks for listening!
And then comes 3.5 with a new bloody brilliant version of Visual Studio, and I'm having a hard time getting my boss to upgrade us to VS 2008, because "it's just a 3.5 update, and we are already on the 3.0 level, let's wait for 4.0!"
Yeah, great job marketing guys, very smart! Microsoft might sell to bosses, but WE are their users. In the end, because I'm the professional in my company, I have more influence than the sales/marketing guy. All it means, is that I need to explain MORE, so no, I don't appreciate it. Sorry.
/more ranting
Thanks for listening!
great explantion. Wished that MS was sooner with this.
this what happened: .NET 3.5 was installed on one of our webservers because of the improved Ajax stuff. It unexpectedly updated .NET 2 to .NET 2.1 and the update broke the filemanagement component of a LOT of websites.
I expected it to run in its own 3.5 clr. NOT funny at all. This costed us days to fix. I don't respect the guy who made this decision and this has nothing to do with marketing.
Sincerly Ed
this what happened: .NET 3.5 was installed on one of our webservers because of the improved Ajax stuff. It unexpectedly updated .NET 2 to .NET 2.1 and the update broke the filemanagement component of a LOT of websites.
I expected it to run in its own 3.5 clr. NOT funny at all. This costed us days to fix. I don't respect the guy who made this decision and this has nothing to do with marketing.
Sincerly Ed
Scott,
Great post. In terms of ability to sell .NET 3.5 to the business, I've found that the fact that ASP.NET 3.5 really runs on the 2.0 framework is a major bonus! Because many businesses make decisions based upon risk, they consider upgrading to a newer version of the runtime to be something quite scary. Once I explain that anything post 2.0 is really just like including a bunch of third-party tools the sell becomes much, much simpler. It removes the term "upgrade" from the proposal as instead it is more of an augmentation.
-- Stu
Great post. In terms of ability to sell .NET 3.5 to the business, I've found that the fact that ASP.NET 3.5 really runs on the 2.0 framework is a major bonus! Because many businesses make decisions based upon risk, they consider upgrading to a newer version of the runtime to be something quite scary. Once I explain that anything post 2.0 is really just like including a bunch of third-party tools the sell becomes much, much simpler. It removes the term "upgrade" from the proposal as instead it is more of an augmentation.
-- Stu
Hi Scott,
Great post, it really helped me to understand how the framework all fits together.
In my eyes I think .Net releases should have a better naming convention, why not have .Net x.0 for CLR changes, and then .Net x.x for framework additions. E.G really .Net 3 should have been .Net 2.1 and 3.5 should have been 2.5 or something. This surely is clearer and the natural CLR version assumptions wouldn't exist?
Now I understand when it comes to marketing that a x.x doesn't sound as good as x.0 but surely marketing shouldn't drive version numbers?
Great post, it really helped me to understand how the framework all fits together.
In my eyes I think .Net releases should have a better naming convention, why not have .Net x.0 for CLR changes, and then .Net x.x for framework additions. E.G really .Net 3 should have been .Net 2.1 and 3.5 should have been 2.5 or something. This surely is clearer and the natural CLR version assumptions wouldn't exist?
Now I understand when it comes to marketing that a x.x doesn't sound as good as x.0 but surely marketing shouldn't drive version numbers?
Thank you for the great post!
It'll save me an hour next time I have to explain this to my friends. I'll just give this link, that's it.
It'll save me an hour next time I have to explain this to my friends. I'll just give this link, that's it.
"WCF is pretty huge and WPF is totally new."
Yes they are. They also do not compose the ".NET Framework". When you roll a framework version number, you are saying that you are releasing a new version of that framework, i.e. a replacement or an upgrade to an older version. But that is not in any way what WW/C/PF are; they are additional feature sets on top of an existing framework version. To describe them as the ".NET Framework 3.0" is completely nonsensical; they are not the framework, they are not a new version of the framework, they are additional bolt-on features to an already existing framework.
I cannot tell you how many times I have had to explain to people that just because I am using the ".NET Framework 3.0" doesn't mean that they will have to install a new version of .NET on all of the client computers or configure new trust environments or anything like they had to do with .NET 2.0. And its great that they don't have to do those things (as Stuart said it reduces the risk of "upgrading"). But it is also extraordinarily confusing, especially to managers and decision makers who don't spend all day every day in the .NET space, because the version numbers don't make any sense.
"I would say, though, that by naming it this way, it was easier for business people to understand and harder for technical people to understand."
This is the exact opposite of my experience. Technical people see that it doesn't make any sense, but once it is explained to them, they "get it", at least enough to remember it. Its easier for them to get because they understand the technical details behind the technologies collectively known as the .NET framework. But non-technical decision makers never get it, because it doesn't make any sense, and they don't have any context in which to make it make sense. So every time the issue comes up, it has to be explained again.
Try this experiment. Find your average corporate technology manager, someone who is not a developer but who is a decision maker on technology projects. Now tell him that in some fictional framework, upgrading from version 2.0 to 3.0 (a major version upgrade) does not require a new IDE for development, but upgrading from version 3.0 to 3.5 (a minor version upgrade) does require a new IDE. See if that makes any sense to him.
"However, from a business guy's point of view (like my old CTO or CEO), they can't point their business fingers and heads at LINQ and figure out what business problem it solves."
Hopefully its your CTO's responsibility to explain to your CEO the business value of whatever platform you are using. And if your CTO can't understand how new language features can improve developer productivity and increase software clarity and maintainability (arguably what LINQ does), then I seriously doubt that any tweaking of version numbers is going to help him.
"In this post I wasn't intending to defend the confusing marketing names."
Then I apologize. It certainly seemed to me as if the purpose of the first section of the post was to defend the version naming. "This is where marketing and reality part ways...I get now why they named them this way." These two statements are paradoxical to me. It is true that technical people and non-technical people can have different views of reality. But I find that making technical issues align with technical reality makes them easier to explain and easier to maintain. When you start trying to align technical issues with a perceived "business reality" in such a way that they do not align with technical reality, you force every explanation of those issues to come with a list of exceptions and addendums (like this blog post) which make understanding them a nightmare for technical and non-technical people alike.
Yes they are. They also do not compose the ".NET Framework". When you roll a framework version number, you are saying that you are releasing a new version of that framework, i.e. a replacement or an upgrade to an older version. But that is not in any way what WW/C/PF are; they are additional feature sets on top of an existing framework version. To describe them as the ".NET Framework 3.0" is completely nonsensical; they are not the framework, they are not a new version of the framework, they are additional bolt-on features to an already existing framework.
I cannot tell you how many times I have had to explain to people that just because I am using the ".NET Framework 3.0" doesn't mean that they will have to install a new version of .NET on all of the client computers or configure new trust environments or anything like they had to do with .NET 2.0. And its great that they don't have to do those things (as Stuart said it reduces the risk of "upgrading"). But it is also extraordinarily confusing, especially to managers and decision makers who don't spend all day every day in the .NET space, because the version numbers don't make any sense.
"I would say, though, that by naming it this way, it was easier for business people to understand and harder for technical people to understand."
This is the exact opposite of my experience. Technical people see that it doesn't make any sense, but once it is explained to them, they "get it", at least enough to remember it. Its easier for them to get because they understand the technical details behind the technologies collectively known as the .NET framework. But non-technical decision makers never get it, because it doesn't make any sense, and they don't have any context in which to make it make sense. So every time the issue comes up, it has to be explained again.
Try this experiment. Find your average corporate technology manager, someone who is not a developer but who is a decision maker on technology projects. Now tell him that in some fictional framework, upgrading from version 2.0 to 3.0 (a major version upgrade) does not require a new IDE for development, but upgrading from version 3.0 to 3.5 (a minor version upgrade) does require a new IDE. See if that makes any sense to him.
"However, from a business guy's point of view (like my old CTO or CEO), they can't point their business fingers and heads at LINQ and figure out what business problem it solves."
Hopefully its your CTO's responsibility to explain to your CEO the business value of whatever platform you are using. And if your CTO can't understand how new language features can improve developer productivity and increase software clarity and maintainability (arguably what LINQ does), then I seriously doubt that any tweaking of version numbers is going to help him.
"In this post I wasn't intending to defend the confusing marketing names."
Then I apologize. It certainly seemed to me as if the purpose of the first section of the post was to defend the version naming. "This is where marketing and reality part ways...I get now why they named them this way." These two statements are paradoxical to me. It is true that technical people and non-technical people can have different views of reality. But I find that making technical issues align with technical reality makes them easier to explain and easier to maintain. When you start trying to align technical issues with a perceived "business reality" in such a way that they do not align with technical reality, you force every explanation of those issues to come with a list of exceptions and addendums (like this blog post) which make understanding them a nightmare for technical and non-technical people alike.
David, Great comment, thanks for taking the time to write it! I see what you're saying, particularly about that 3.5 needs a new IDE and 3.0 didn't. That's of course, where it gets messy as it's the 3.0 Compilers (having moved from 2.0 to 3.0) that required the new IDE, not the Framework (moving from 3.0 to 3.5 (but technically from 2.0 BCL to 3.5 BCL with W?F being the aberration)).
Let me ask you this...(perhaps I need a whole new post about this), let's assume that products are what we know them to be - what would you name them? Give me a bulleted list with the names for each release?
Let me ask you this...(perhaps I need a whole new post about this), let's assume that products are what we know them to be - what would you name them? Give me a bulleted list with the names for each release?
Hi Scott...if I were the benevolent dictator of .NetDeveloperWorld they'd be named thusly:
.Net 2.0 = .Net Framework 2.0
.Net 3.0 = .Net Framework 2.0 Extensions Pack 1
.Net 3.5 = .Net Framework 2.0 Extensions Pack 2
At least this sounds good at this moment...
However being the benevolent dictator of .NetDeveloperWorld I reserve the right to change my mind later.
.Net 2.0 = .Net Framework 2.0
.Net 3.0 = .Net Framework 2.0 Extensions Pack 1
.Net 3.5 = .Net Framework 2.0 Extensions Pack 2
At least this sounds good at this moment...
However being the benevolent dictator of .NetDeveloperWorld I reserve the right to change my mind later.
The topic probably does deserve its own post; this post was about IIS Application Pools, and I hijacked it. Sorry about that.
You make a good point about the new IDE being necessary for new language versions, not new versions of the "Framework", i.e. the BCL. You and I understand the difference, because we readily make the distinction between the CLR, the BCL, and the individual languages that target the .NET Framework. However, most technology managers, and many .NET developers, do not make that distinction, primarily because most of the time Microsoft does not make that distinction.
Since you're asking me to put it in writing, let me think a little bit about what my "ideal" naming would be before I commit to it :) I will probably try to post it on my blog rather than push these comments any farther off topic, but I will post a link here.
You make a good point about the new IDE being necessary for new language versions, not new versions of the "Framework", i.e. the BCL. You and I understand the difference, because we readily make the distinction between the CLR, the BCL, and the individual languages that target the .NET Framework. However, most technology managers, and many .NET developers, do not make that distinction, primarily because most of the time Microsoft does not make that distinction.
Since you're asking me to put it in writing, let me think a little bit about what my "ideal" naming would be before I commit to it :) I will probably try to post it on my blog rather than push these comments any farther off topic, but I will post a link here.
Better late than never...I have posted about how I would version the .NET Framework at Why I Hate Marketing.
Slightly off topic i guess, but can you guid me about "How many web sites should be assigned to a single application pool in IIS 6."
is there a magic number? should one create a new pool for each new site or should we create a pool for a bunch of sites?
is there a magic number? should one create a new pool for each new site or should we create a pool for a bunch of sites?
Comments are closed.
BOb