The .NET Framework Final [RTM]: An Analysis

By Peter Bromberg and Robbe Morris

 

On the evening of January 15th, 2002, Microsoft released the long -awaited .NET Framework SDK to the public, as well as the three official versions of Visual Studio .NET to MSDN subscribers. In this article we'll just cover some of the basics such as installation issues and API changes. Later on, as more information and user experiences come out (and as people begin to get enough bandwidth to actually complete a download!) we'll get into Visual Studio and other issues. As is our practice, if you have comments, questions, or information you'd like to contribute, please post it at our forum here : http://www.eggheadcafe.com/forums/.



First, lets cover installation issues:

1) You must uninstall everything related to Beta 2 before you install the .NET Framework Final SDK, redistributable runtime ("dotnetfx.exe"), or Visual Studio .NET. You cannot, for example, uninstall the Beta 2 Framework, install the FINAL Framework, and expect to use Visual Studio .NET Beta 2 with it. ALWAYS uninstall Visual Studio FIRST, then the Framework, and always do so using the Control Panel "Add/Remove" applet.    We've already installed the .NET Framework on several developer machines as well as a production webserver with no problems.

2) At this point we know of only three installation issues. One is covered in the readme, and the others, although not specifically covered, can be figured out easily enough:

Issue # 1: Some uninstalls of Beta 2 do not remove mscoree.dll from the system32 folder. The new installation sees this file and tells you there is still a BETA installation there, and installation fails. Solution? Remove mscoree.dll from your system folder. You may, as a possible alternative, wish to use the MSIZAP utility, but you'll need the product key and we can't help you with that cause ours is GONE! Look here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/app_099h.asp

Issue #2: ASP.NET BETA 2 ran the ASP.NET Worker process under the "System" account identity. This is a highly privileged account, and probably not always a good idea for a public webserver. The new RTM .NEt Framework Final version installation has ASP.NET worker process under a "machine" account identity, and this can cause permissions errors.

userName="[user]" - Windows user to run the process as.
Special users: "SYSTEM": run as localsystem (high privilege admin) account.
"machine": run as low privilege user account named "ASPNET".
Other users: If domain is not specified, current machine name is assumed to be the domain name.
password="[AutoGenerate | password]" - Password of windows user. For special users (SYSTEM and machine),specify "AutoGenerate".

So if, in machine.config, you have:

<processModel
enable="true"
timeout="Infinite"
idleTimeout="Infinite"
shutdownTimeout="0:00:05"
requestLimit="Infinite"
requestQueueLimit="5000"
restartQueueLimit="10"
memoryLimit="60"
webGarden="false"
cpuMask="0xffffffff"
userName="machine"
password="AutoGenerate"
logLevel="Errors"
clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
responseRestartDeadlockInterval="00:09:00"
responseDeadlockInterval="00:03:00"
maxWorkerThreads="25"
maxIoThreads="25"
/>


--- this means that the ASP.NET worker process runs under the identity of the account "ASPNET" and whatever groups it belongs to permissions- wise. Of course the neat thing about ASP.NET is the easy ability to have a particular page impersonate any account in order for it to be able to do certain things it's supposed to do. If you currently have web sites running .NET oriented applications/pages, we'd suggest setting the userName in the processmodel tag to system upon completion of the install. You can then make your decisions on what the ASPNET user should have permissions to with minimal site downtime.

There is a pretty good whitepaper available that covers most of the above issue: http://www.gotdotnet.com/team/upgrade/v1/aspnet_account_readme.doc

Issue #3: You will likely find that your Visual Studio created WebForms applications or Webservices applications develop errors reading web.config because of incompatibilities from BETA 2. Specifically the httpHandlers section. The simple solution (for now, until we've had a chance to review the docs and stuff) is to simply comment out the section, like so:

<httpHandlers>
<!--
<add verb="*" path="*.vb" type="System.Web.HttpNotFoundHandler,System.Web" />
<add verb="*" path="*.cs" type="System.Web.HttpNotFoundHandler,System.Web" />
<add verb="*" path="*.vbproj" type="System.Web.HttpNotFoundHandler,System.Web" />
<add verb="*" path="*.csproj" type="System.Web.HttpNotFoundHandler,System.Web" />
<add verb="*" path="*.webinfo" type="System.Web.HttpNotFoundHandler,System.Web" />
-->
</httpHandlers>

 

The other big area is API changes. First, be advised you will definitely need to recompile any projects build under previous versions of the CLR. As you can see from our handy chart below, there have been 2266 members added since BETA 2, and 211 removed for a total net change of 2,055 class members. We've arranged the table so you can see the classes with the most changes near the bottom. In particular, system.data, system.windows.forms, system.xml, and System.web among the public classes have the most API changes. You can download a copy of the zip file containing all changes in HTML format along with a detail page explaining each change from the link at the bottom of this article.

 

 

API Changes from Beta2 to RTM
Assembly Members Added  Members Removed Breaking Changes
microsoft.visualstudio.vshelp (157) 0 0 167 breaking
soapsudscode (46) 0 0 49 breaking
tlbexpcode (33) 0 0 36 breaking
tlbimpcode (41) 0 0 44 breaking
accessibility (20) 1 0 2 breaking
iehost (36) 1 0 0 breaking
microsoft.visualbasic.vsa (141) 2 0 0 breaking
microsoft.vsa (273) 2 1 3 breaking
system.serviceprocess (807) 2 1 13 breaking
system.runtime.remoting (436) 3 0 31 breaking
system.web.services (2561) 3 3 32 breaking
system.directoryservices (412) 4 2 3 breaking
system.configuration.install (384) 5 1 2 breaking
system.management (1302) 6 4 0 breaking
system.security (330) 7 0 4 breaking
isymwrapper (139) 8 8 8 breaking
iiehost (15) 12 0 13 breaking
system.enterpriseservices (944) 22 6 26 breaking
microsoft.vsa.vb.codedomprocessor (24) 24 0 7 breaking
system.messaging (1497) 28 1 7 breaking
microsoft_vsavb (50) 50 0 51 breaking
system.drawing (4724) 67 7 65 breaking
microsoft.visualbasic.compatibility (3099) 72 15 80 breaking
system.design (4360) 73 15 21 breaking
system (8959) 81 12 151 breaking
system.data (3592) 93 45 58 breaking
system.windows.forms (22344) 95 25 219 breaking
microsoft.visualbasic.compatibility.data (779) 144 1 4 breaking
system.xml (4425) 183 22 42 breaking
system.web (10887) 229 10 113 breaking
mscorlib (15589) 239 31 175 breaking
microsoft.visualbasic (1090) 363 1 393 breaking
mscorcfg (889) 447 0 4 breaking
TOTAL CHANGES: 2266 211  
NET CHANGE: 2055    

Finally we have our "Guerilla Install Tactics article ready to help you with additional issues installing the Visual Studio.NET product.

Download the API Changes pages that accompany this article

 
Do you have a question or comment about this article? Have a programming problem you need to solve? Post it at eggheadcafe.com forums and receive immediate email notification of responses.