For that matter what is plain old .NET? Is this something of interest primarily to developers or do ordinary computer users need to know about it also?
Argghh!!! I blew the title. It’s supposed to be What is .NET Framework.
Can a mod fix that for me? I’ll preview from now on, I promise.
IANAMSE (Microsoft Engineer), but as far as I know:
basically the .net framework is microsoft’s answer to java.
It allows a programmer to write code in lots of different languages and compile it (sorta) into MicroSoft Intermediate Language (MSIL). MSIL is still kinda readable. It’s not compiled, but it’s not source code.
When you run a .net program it compiles the MSIL code on the fly (for your computer). This allows (in theory) programmers to write programs once and have them run on multiple different OS’s (assuming they have the .net framework).
I haven’t heard of a non windoze OS supporting this yet, but it seems to work fairly well on NT and 2000 and XP.
I 'm a .NET developer (I mean I use it every day, not that I had anything to do with creating .NET itself).
Essentially it’s Microsoft’s Next Big Thing for programmers. Their idea is that all new programs (including all of Microsoft’s products) will be built using .NET rather than the heretofore traditional languages and tools. It does have a lot of really cool features to rationalize the hodgepodge that Windows’ internals have become over the years. And it’s also a real boon to Web development versus MS’s previous offerings.
And as ghostman said, they intend that other companies could build adapters so .NET programs could run on their non-Intel hardware and non-Windows software, but I doubt that’s gonna happen any time soon.
So that’s the programmer perspective.
From the ordinary user perspective it goes like this. a .NET program looks to you just like an ordinary .exe file, perhaps with some .dll files as well. It installs the same and once it’s running it looks the same to you.
But the guts are utterly different, as different as Mac programs are from Windows programs are from Unix / Linux / blahblahblah-nix programs.
So a .NET program is NOT usable unless your Windows installation has a copy of the “.NET Framework” already installed. The framework is essentially an adapter layer between that program and the real underlying Windows. If you try to run the program without .NET installed, it’ll quit immediately with a message box saying “Hey, I need the .NET framework to run & you don’t have it.”
The framework now comes included in Win XP and is available for free download to retro-fit older Windows versions.
Right now very little commercial desktop software is written in .NET yet. It’s used in a lot of commerical websites, but that doesn’t require your machine to have the framework to use the website.
Bottom line: If you have XP, you’ve got it and don’t need to worry about it. If you have an older OS, you don’t need it until you install some program that needs it.
Hope that’s sufficient.
I’m a programmer too. Mostly GIS (ESRI) stuff. Some VB.
But aren’t we basically using the same languages? I’m just getting into .NET (literally yesterday). The VBscript looks the same.
It sounds to me that it is just compiled differently, so that with the framework, other systems can run it. Is that correct?
ehhh? Is the MSIL the executable? If not, why is there an intermediate (sorta) compile? Is it for debugging?
Like I said, I’m just starting. The install didn’t go for shit. I need to be able to remote debug, and the instructions for configuring it tell you to set Registry Keys that don’t exist. Great fun. 
:mad: :mad:
Thanks -
The MSIL gets JIT (just-in-time) compiled the first time you run the executable, so .NET code can be quite slow the first time it gets run. After that, the compiled code is cached on the computer, so it runs normally.
Non-developers don’t need to know much about it. I like it a lot, it allows me to do a lot of things far more easily than in any other development environment. End users will eventually see the benefits of this, in richer functionality and improved reliability.
enipla,
The programmer-level point of .NET is that it’s several things:
-
A completely new object model so you never have to touch the Win API, the MFCs or use COM/DCOM. Ever. Good riddance.
-
Language commonaltiy, so C++, C#, VB, J# and whatever else they invent next year, are all using the exact same object model for everything, including memory variables, so a VB program can call a C++ procedure which can call a J# procedure and everyone is using the same memory model, with no thunking or type conversions or …
-
The language syntax itself is just barely changed from the previous versions, so VB.NET looks a lot like VB6, managed C++ looks a lot like C++, etc. C# isn’t umuch different from Visual C, etc.
Remember that in a modern language, almost everything other than flow-of-control statements are object manipulations, so in many ways the available object inventory IS the language.
- .NET is a security tool. It provides a way to control the exact rights a peice of code has. e.g. Subroutine X can access the screen, but not the file system, and can read the registry but only these specific subkeys x, y, and z. This has nothing to do with WHO is running the code(admin, power user, SYSTEM, etc.), like traditional Windows security, but is intrinsic to the code itself.
And that can be enforced, so even if a hacker substitutes his malicious code for yours within that subroutine, the Framework will still prevent the code from getting outside the declared sandbox boundaries.
This is, IMHO, the real point of .NET. It provides a method where eventually hacking will become very difficult. Right now if somebody can substitute his bytes into your execution stream, he takes over your process at the hardware level. Not anymore, at least assuming the programmers actually use the security features to keep their routines as locked down as possible.
And administrators can lock code down as well, so corporate policy can preclude all unknown code from running, etc.
This area is HUGE in its future implications as .NET code becomes more widespread.
As to MSIL …
The output of the .NET development tools are .exes and .dlls, just like always.
But they do NOT contain Intel x86 opcodes like a traditional exe/dll would. They contain a small stub that IS a traditional windows exe which produces an error messagebox and quits, plus the body of the code wrtten in MSIL, which is essentially assembler for a fictitious virtual processor. Sorta like java p-code.
Back when DOS was king and Windows was new, exes went through a similar transformation. A Windows exe contained a small stub of a DOS program that displayed the message “This program requires Windows” and quit. The DOS loader only knew about that part so that’s what ran when the program was started from DOS.
But if you had Windows installed & running, the Windows loader was smarter and knew to look for the Windows-format exe hiding behind the DOS stub.
Today Windows is the dumb one and we have a .NET loader that looks behind the Windows stub to see the .NET MSIL-exe.
When you ask Windows to run a .NET exe, the .NET loader compiles the MSIL into X86 opcodes and runs the result. So every user PC has the MSIL-to-X86 translator program installed as part of the Framework. The compiled code is maintained in a cache so it loads quickly the second time, for example if the code is really a webpage it only gets compiled once.
So that’s that.
As to remote debugging and missing registry keys, I suspect think you’ve missed something critical.
To do remote debugging in .NET you MUST install the .NET remote debug tools (hereafter “RDT”) on the machine where the code is running, in addition to installing VS.NET on the machine you’ll be working from. Note that the .NET remote debugger is different from any non-.NET remote debuggers you may already have installed on that server.
For the typical web server debugging, that mans the RDT must be installed on the webserver while VS.NET is installed on your programmer’s workstation. The documentation leaves this point pretty hazy, so it’s easy to screw this up.
To install the RDT on the server, take your VS.NET CDs (all 4) to the server and start the install, as if you wanted to put the whole development environment on the server.
But when you get that very first 4-paragraph dialog box, which says something like 1) check for prerequisites 2) install vs.net 3) install documentation, 4) check for updates, STOP right there.
At the very VERY bottom of the box is a hyperlink-like thing which says something about remote tools. I forget the exact verbiage & I’m at home right now. But it doesn’t exactly say “click here to install remote debugging” like it ought to. It’s sorta kinda in that ballpark, but not exactly.
At any rate, click THAT instead of doing the steps 1-4. That’ll put the remote debuggger onto that server and NOT install the whole development environment.
Once that install is finished, THEN you can connect to the server easily from your workstation.
The server install will create a machine-level “debugger users” group. To access the debugger from your workstation your domain userID must be manually added to that group. If the process you’re debugging on the server is running under your userID that’s all you need.
But if, and this is by far the more likely case, the server process to be debugged is running under some other userID (system, IUSR_…, etc, asp.net, etc), then your userID also needs to be a member of the server’s machine builtin\Administrator group.
Good luck. It works real slick once you get it set up, but its easy to get stuck with a half-completed setup that doesn’t work and there’s no clues why.
Thank you, LSLGuy, for that excellent explanation of .NET Frameworks. Before I posted this I spent some time on the Internet trying to figure out what it was all about. If you google on “.NET Framework” the first site is Microsoft’s .NET Framework Home page. You would think that that would be the place where they would give you an idea of what its purpose is, but nope. Here’s what they give you, and I quote:
Right. That helps.
You have to go to their FAQ page before they clue you in at all:
That could describe any development tool that has been released since Windows existed. The reader still knows nothing of any value about .NET. (By the way, when people talk about .NET is that the same as .NET Framework?)
I could go on, but now I’m starting to rant. Thanks again for your lucid summary.
Power went out, killed my response. I’ll try again.
So, the MSIL gets compiled by the .NET framework on each individual machine. Provide they have the framework installed?
What about VBscript, JavaScript and HTML? Running on IIS. Does that get compiled somehow?
I literally, just started with .NET yesterday. The install didn’t go for shit. I need to be able to remote debug. The debug config instructions told me to “set” (add string values[thank your for clear language MS]) to two REGISTRY KEYS. One of those keys does not exist. I have know Idea if it will work.
or ‘no idea if it will work’.
It almost works either way.
Yesterday was a very, very bad day. I also tried to install Visual Studio 2003. It asked for a pre-install disk, to set up the computer.
No problem. Got it. You sent it to us. I’ll stick it right in the old D: drive. Let’s get this configured. Maybe you have my missing REGISTRY KEY.
Beep…
Wrong disk, please insert the pre-install disk in drive D:
WTF. I got a co-worker to look at this for me. “Yep, that’s the disk, yep, that’s the application. Good thing you’re not a violent person.”
Bad, bad, day
.
Thank you, LSLGuy
I need more time to digest your post, and I will print it out. I have thought about the ‘commonality’ between languages. And the ability to intercomunicate.
.NET seems to do that.
I did it. I reinstalled, I did a repair. The configuration asks you to set two REGISTRATION KEY’s . One exists, the other doesn’t (I’m away from work, don’t know the KEY #).
The set up also asks to make some other settings that simply don’t exist.
I’m away from work so I can’t say exactly what they are.
VS 6 asked to connect to a remote server for and existing IIS project. I don’t see that in .NET.
I’m at home, I’ll do some more searching about the REG KEY I am missing.
I am also going to meet my wife tonight for dinner and a movie (she is working tonight so we can go to the Dominican Republic in two weeks). Sort of a surprise vacation, for both of us. We are in Colorado.
Thank you very much for your well thought out and intelligent response. I hope I can ask you some more questions when I get back to work on Monday.
I’ll find out that REG KEY # on Monday and may ask you if it is on your box. There are two other programmers using .NET where I work. One of them does not have it (he does not remote debug). The other is on vacation.
I’m sorry if I sound a bit pissed off. I just had the most frustrating day of my life.
I also tried to install VS.NET 03. It asked me to install the ‘requirements disk’ (something like that).
No problem, got it right here. The sequence number is correct. That’s the disk, no question.
Nope, won’t do it. MS tells me it is the wrong disk. I had a co-worker come look at what was asked, and what disk to install, and he agreed.
VS.NET 03 will not install because it does not recognize the requirements disk. All of this is straight from MS. Original Packaging. I’m starting to wonder if I have a problem with my CD drive.
Best regards
Doug
The .NET Framework also includes the runtime libraries needed for more traditional code compiled with Visual Studio.NET, including that needed for C++ programs compiled with VC7. That’s what you’re most likely to see the requirements for at the moment, as developers take advantage of the slightly improved performance of code generated with the Visual Studio.NET compilers.
bnorton:
Technically, “.NET Framework” is the adapter layer required on the user PC to run prgrams written for it. “.NET Framework” is a package installed on PCs.
“.NET” alone refers to the whole technology: the object model, the development tools, the underlying services AND the run-time framework component.
As a practical matter, the two terms have sorta blurred together. I tried to use them correctly in my two articles but I may have failed.
For awhile back in 2001/2002 MS muddied the waters by refering to what’s now called “Windows 2003 Server” as “.NET server.” They don’t use that terminolgy anymore, but there are still dozens of articles on microsoft.com and in the trade press using that terminology.
enipla on installs & debugging:
There are 2 versions of the .NET Framework and 3 versions of VS. You can only use them in the correct combinations. IF you’re working from CDs of dubious parentage that might be a problem.
The Framework comes in v1.0 and v1.1. For all new development you REALLY want v1.1.
VS comes in versions for 2003, 2002 and 2001. I know VS 2003 only works with Framework v1.1. And 2001 only works with v1.0. I’m not sure whether 2002 works with v1.0 or v1.1 or both. IF somehow you ended up with a Framework v1.0 requirements disk that’d explain the mismatch with VS2003.
One of the cool features of .NET is that multiple versions of the same software can happily coexist. So it’s OK to have both v1.0 & v1.1 Frameworks on the same machine. In fact, if you have any user software that uses v1.0 it’ll only run as long as v1.0 framework is installed.
Unlike the new-version-overwrites-old “DLL Hell” we’ve had for 10 years, under .NET old code never dies, it just takes up disk space forever.
I have NEVER been able to recover a damaged install of any major MS product. For a developer’s machine which is usually wreckage internally anyhow, I’d consider scraping the hard drive & trying again.
Don’t bother messing with server debug installs until you get a clean developer station install. When you can debug the IIS on your own machine, then you know you stand a chance of successfully introducing remoting into the picture. This is one of those cases where baby steps get you there quicker than running and falling with scissors.
Enipla on IIS, VBScript, ASP, HTML:
If you’re used to ASP development with VBscript for delivery by IIS, you’re in for the culture shock of your life. Almost nothing you know will carry over to ASP.NET. If you have ever done straight desktop development with VB you’ll find ASP.NET is a LOT closer to that than it is to ASP. But that can be good news.
I’m gonna simplify this a bunch and I’m only gonna talk about the most common cases. There are exceptions to nearly everything I’m about to say. Here goes…
Every webpage consists of 2 parts, a file of conventional HTML & XML (.aspx) and a file of VB code (.vb). NOT VBScript code. VB code. Like for non-web-based desktop Windows programs. That “code-behind” file can be C# or J# or .NET COBOL (yes it exists!) for that matter. The VS IDE keeps the the parts together for you automatically.
The webpage has ordinary HTML, plus any client-side jscript or vbscript you may want to stick in there. And for each live (non-static) UI object on the page, there’s some XML code. You use a visual designer in the VS IDE to drag buttons, grids, labels and textboxes onto the webpage, just like for Windows desktop programming. Each of these UI objects has a property page too, just like in desktop programming. The designer creates all the corresponding XML for those objects behind the scenes and stores it in the .aspx file. As a .NET web programmer you can go for several days without seeing any HTML. You CAN still write conventional HTML in there if you want, and sometimes that’s convenient; but usually it’s unecessary and more trouble than it’s worth.
You also write code in the code-behind file. That looks just like the code for a Windows desktop program. You create form objects, write code to access databases and write event procedures to respond to button clicks, etc. You CAN write code sorta like traditional ASP which will emit HTML towards the browser, but again that’s not the normal way to do things.
When you “build” (compile) the project, the webpage .aspx is saved on the IIS server as you see it. It looks like an ordinary HTML <head> section but the <body> is pure XML. The compile step also converts the code behind .vb (or .cs or .js) file into a DLL on the IIS server.
If you have a 20-webpage application, yo’ll end up with 20 web pages (.aspx files) and one dll file containing all 20 code-behinds. Each code-behind translates into a separate class within the dll. So each webpage is essentially a class, just like each form in a desktop Windows program is really a class.
Now the application is ready to run.
When a browser contacts IIS and requests an ASP.NET page a LOT of magic happens next.
IIS passes the request to the ASP.NET worker process (totally separate from any old-style ASP worker processes on that server). That process retrieves the .aspx file of HTML/XML. That file has an XML reference to the code-behind dll file & the appropraite classname within the dll.
Now the ASP.NETworker process starts to translate the aspx file. The HTML goes more-or-less straight out the response stream towards the browser, and the XML is translated into calls into the guts of the ASP.NET objects to create HTML equivalents to the ASP.NET objects. Those HTML equivalents are then sent out the response stream too. Calls to the ASP.NET UI objects also trigger calls to your form-creation code.
Now as soon as the ASP.NET worker process calls any of your code, your code-behind dll is loaded. BUT, like all other .NET dlls, this one is really in MSIL, not x86 machine language. So we have a short timeout while the server’s .NET Framework is called to convert the dll to x86 machine language. That result is cached so the compilation time (1 second or so) is only spent once.
Now the ASP.NET worker process has an x86 dll to call. And so the page is assembled UI item by UI item. And finally it gets sent to the brower as pure industry-standard dumb-browser compatible HTML.
Now suppose the user clicks a submit button.
The browser sends a request just like always. The server re-creates the page from scratch, just like I outlined above. But (due to some hidden encrypted <form> fields) it knows it’s getting one of its own pages back, so it overlays the UI info as modifed by the user into its own objects. And then it calls your code-behind button-click-handling procedure to react to the button push. What your code sees is that the value of the textbox you originally sent out as blank is now “whatever”, and your code can react accordingly.
So then your code, say, calls some server side routines, sets some values on labels and grids and dropdowns and whatnot on your page and magically the server converts it all to dumb HTML on the fly and sends it back to the browser.
And the cycle continues and continues and continues … WOW!
Bottom line: The overall application behavior is a LOT more like conventional Windows event programming than it is like the request/response programming of traditional ASP. You see a stateful event pump, not a stateless request/response cycle.
Again that was simplified a BUNCH, but I think it gives you the right conceptual mindset to approach learning the beast.
Editorial commentary: I think a LOT of programmers from the ASP world will get scraped off in the transition. Desktop programmers might actually have an easier time of it.
But if they are VB4 became VB5 became VB6 programmers, they’ll have a steep learning curve too. VB.NET is fully object oriented, not the half-assed quasi-mess that VB6 was. And the object model is HUGE and totally new.
The C and C++ folks may have a better time because they’re used to thinking in pure object terms, but they also have to deal with the same totally new object model. Their expertise in MFC and the Win32 API is now irrelevant.
One last gotcha. A LOT of the documentation on MSDN or in the installed help system was written for the beta version of .NET, before the IDE was available. So many of their examples put all the code into the aspx file along with the HTML. You CAN put all the code-behind vb code into the webpage file (like ASP) and the compiler will sort it out. But that’s really muddying the waters of A) how it’s supposed to be done, and B) what’s really going on behind the scenes.
Their goal was to make major performance improvements by getting away from purely interpretted script on web pages like ASP is/was. They made it 95% of the way there. All the meat of your code is compiled in the dll, and the aspx is really only a few bytes of HTML and an XML laundry list of compiled objects for the ASP.NET process to call. So ASP.NET executes VASTLY faster than ASP for any non-trivial server-side processing.
I’m keeping long hours this upcoming week at work so I may not be on the SDMB much more than say Sun eve, Wed eve and Sat AM again. So if you/anyone have any more .NET questions I’m not gonna be a timely resource.
Cheers …
Wha? I have XP Home, and it tells me I need the .NET framework when I try to run a program that needs it. Well, at least the only program I’ve tried to run that I knew used the framework did. sighs
And unfortunately, with 24k dialup, I’m not going to download a file of that size. I find it painful enough to download Firebird.
kushiel,
Sorry about that. When I said “XP” I was referring to XP Pro, the stuff we have at the office. I wasn’t aware that XP home doesn’t have the framework. I’ve avoided MS’s “home” versions of Win32 ever since day 1.
MS’s approved .NET development practices say that any commercial software released ought to include a copy of the framework to take care of situations like yours. It really isn’t that big on a CD (24MB). But to download over a modem, now that’s a huge chunk.
If you work in an office or have a friend with a fast connection, you could download it there & burn it onto a CD for install at home. Here’s a link for a page for downloading it as a file, rather than installing it directly.
As I mentioned, I am having difficulty setting up ASP remote Debugging.
From the MS site – ASP Remote Debugging Setup
· Using regedit.exe, you must set these two registry keys on the remote machine:
· [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID{6EB22881-8A19-11D0-81B6-00A0C9231C29}]
· @=“Catalog Class”
· “DllSurrogate”=""
·
· [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{6EB22881-8A19-11D0-81B6-00A0C9231C29}]
· @=“Catalog Class”
“AppID”="{6EB22881-8A19-11D0-81B6-00A0C9231C29}"
I do not have the first KEY listed here. The one under AppID.
Could I ask someone with a full Visual Studio .NET check to see If they have that KEY?
Thanks, you can respond here or email me at dougp@co.summit.co.us
Enipla,
On my home machine I have Win 2KPro, Vis Studio .NET 2002 (v7.0) with .NET Framework v1.0. It does have the full debugger for local use; I’ve never tried using it for remote debugging, either as debugGER or debugEE.
That machine does NOT have
[quote]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID{6EB22881-8A19-11D0-81B6-00A0C9231C29}]
[quote]
in the registry.
It DOES have this in the registry
[quote]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{6EB22881-8A19-11D0-81B6-00A0C9231C29}]
@=“Catalog Class”
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{6EB22881-8A19-11D0-81B6-00A0C9231C29}\InprocServer32]
@=“C:\WINNT\System32\Com\comadmin.dll”
“ThreadingModel”=“both”
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{6EB22881-8A19-11D0-81B6-00A0C9231C29}\ProgID]
@=“MTSAdmin.Catalog.1”
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{6EB22881-8A19-11D0-81B6-00A0C9231C29}\VersionIndependentProgID]
@=“MTSAdmin.Catalog”
[quote]
My workstation at work has Win XP Pro, Vis Studio 2003 (v7.1) and .NET Framework v1.1.
It’s registry has exactly the same situation as my home machine: no AppID keys and the above CLSID keys.
My development server at work has Win Server 2003, IIS, .NET Framework v1.1 and the Vis Studio 2003 remote debugger installed. It does NOT have the full Vis Studio 2003.
It’s registry is exactly the same as the other two for these keys.
Hope that’s helpful.
I didn’t say it explicitly, but remote debugging of ASP.NET running on my server’s IIS 6.0 works just great from my workstation with the registry setup above.
That info about registry keys was not in the documentation for VS 2002. It is for VS 2003.
Looking at the debug-related documentation as a whole, I suspect they’re talking about use VS.NET to debug traditional non-.NET ASP apps.
If that’s not what you’re trying to do, then IMHO the registry keys will be irrelevant.