|
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
|