Talk:.NET Framework

Template:WikiProjectss=B {{WikiProject Insert non-formatted text hereportance=high}}

Criticism cleanup

That microsft has applied for patents on some parts of the Framework is not a valid complaint on the framework itself, the comment about Novel and MS:s patent deal is quite a bit offtopic and speculative. Thus I was bold and removed this section.

• Microsoft has applied for patents on some parts of the Framework. An agreement was made however between Microsoft and Novell whereby Microsoft agreed to not sue Novell or its customers for patent infringement, allowing the implementation of these parts in the open-source Mono implementation of .NET. According to a statement on the blog of Mono project leader Miguel de Icaza, this agreement extends to Mono, but only for Novell developers and users. It was criticized by the Open source community because it violates the principles of giving equal rights to all users of a particular program (see Patent Agreement with Microsoft). In February 2007, rumors circulated that the Free Software Foundation is reviewing Novell's right to sell GNU software, which makes up much of a Linux operating system, because of this agreement. However Eben Moglen later said that he was quoted out of context, and referring to possible changes that could be made to the GPL version 3, that would block similar deals in the future.

Signed User:Swetha Rani Peddaboina 09:45, 20 September 2007 (UTC)

Speaking of cleanup, this point:

• Several developers have reported issues with something known as "the parking window". There are times when the parking window will put itself into a condition which Windows treats as fatal, and thus the .Net application is terminated.

This is not .NET-trac, an arbitrary obscure bug is not proper criticism. 85.8.4.157 23:02, 5 November 2007 (UTC)

I removed the GetHashCode complaint on breaking changes between FW versions. The result of GetHashCode was never designed to be stored/used/etc. beyond a single application run. 24.124.103.251 04:23, 9 November 2007 (UTC) Mach

I find the entire criticism section of dubious value. The first few points don't seem very significant. Then, those regarding performance, reverse engineering of code, and garbage collection are (as noted) not specific to the .Net framework, and "criticism" seems too strong a label. I'm inclined to remove the first points, and retain these last three under a new heading named "Disadvantages" . What do y'all think? Leotohill (talk) 03:04, 27 November 2007 (UTC)

• Personally, I think the main criticism is the simplest one: The entire framework is a bargelike white elephant that shouldn't exist in the first place. There is nothing particularly clever about it, its basically a cleanup and re-sell of their DCOM architecture, and it yet again reinvents wheels that were already spinning as far back as the 80's. It is complicated to use, requiring the use of specialized tools to sort out the mess for the developer (thereby removing control and certainty from them), slow, resource hungry, and from what we've seen so far, a complete security nightmare.

60.240.111.29 (talk) 14:40, 24 December 2007 (UTC)

Sorry but "I don't like it" does not constitute as criticism. --soum ^talk 15:12, 24 December 2007 (UTC)

• C++ Memory allocation error. One has two options for creating a variable in C++, on the stack, or on the heap. If we interpret "grab a variable" to mean "use the 'new' operator" then the comment is reasonably correct. However it is generally preferred to use the stack unless there is good cause to alloc() something. Using the stack (also called automatic variables, or statically allocated variables) means there is no system call, and is very fast.

Cshuller (talk) 04:27, 5 March 2008 (UTC)

• Comment on the general tone. I am looking for real criticisms of .Net. What I read were real critisisms of other development tools. The "bargelike white elephant" comment above gave me more information than the entire published section: Very Large, Repackaging of Old Ideas, Hard to use, Resource intense. Many of which I was able to infer from the features the .Net framework provides, but I saw no clear rebuttals. For instance, the size of the .Net framework is in question, compare it to the size of the Java environment. How much larger is it really? (I happen to know on my system they were comparable, except I had 3 .net versions and only 1 Java version.). Another interesting question is size of the GNU C++ library (with the STL) and the size of the .Net framework. It's not really apples to apples, but gives me a solid basis for comparison. We all expect C++ to be relatively feature poor compared to .Net, so we expect it to be quite a lot smaller, perhaps it's only a bit smaller though....

Cshuller (talk) 04:27, 5 March 2008 (UTC)

• "Applications running in a managed environment such as the Microsoft framework's CLR or Java's JVM tend to require more system resources than similar applications that access machine resources more directly. Some applications, however, have been shown to perform better in .NET than in their native version.[citation needed] This could be due to the runtime optimizations made possible by such an environment, the use of relatively well-performing functions in the .NET framework, just-in-time compilation of managed code, or other aspects of the CLR."

Yeah, a citation's definitely needed there. I've never once seen .NET code that can outperform native code, either in test cases or real-world software. In my own tests, the same code in Delphi for Win32 and Delphi for .NET (one of the few languages where you can actually do a straight-up comparison of the exact same source code) tends to require 5-20x more memory and 3-5x more "CPU %" to accomplish the same task, and I've never once seen a commercial .NET application that I'd describe as "fast" or "responsive". I'm removing everything after the first sentence. Someone feel free to put it back in if you can find a valid source to reference. --Masonwheeler (talk) 23:01, 22 December 2008 (UTC)

I'm ok with the removal of the uncited claim, but I'm not ok with replacing it with another uncited claim. I reverted your edit. Leotohill (talk) 01:31, 23 December 2008 (UTC)

I don't buy into any of the speech about the .NET framework being cross-platform. It's designed to be cross-platform, but in practice the only implementation is on Windows. Compare this to Java or Python or Ruby, or what the heck, C++, where each release is more or less simultaneous for all platforms. Mono is not a compatible implementation of the .NET framework. It's a very interesting platform on its own, but not reliable at the same level as Java or C++. Maybe tie this to the lack of will by Microsoft to support its technology on other platforms? --Ruijoel (talk) 16:32, 11 February 2009 (UTC)

Installation

How about a criticism on the installation? More and more applications see "no .net framework" as a selling point, typically listed as a bullet point saying "written in C++" or "written in native code", "simple installer" etc. Whether true or not, many users refuse to install the .net framework because of the size and complexity of the installers. For this reason, consumer products using the .net framework can lose out to applications with quick and easy installers. It is difficult to sell a 1 MB application online if you require end users to download and install a 50MB framework using a complex installer, simply to try the product. Frank Hileman (talk) 18:01, 29 November 2007 (UTC)

I've now added some text that mentions this concern, because I believe it has some merit. However, I do think your phrasing exaggerates it. Is the .net framework install complex? I think it's just one or two clicks. And I question your "more and more" claim... some verifiable facts would be nice. Leotohill (talk) 00:55, 30 November 2007 (UTC)

EVERY damn library ever written must be present before it can be used. Whether they are C/C++ libraries (which generally tend to be statically linked) or dynamic libraries like .NET Fx, Java, or even the interpreted languages like Python, Ruby and even JavaScript is immaterial. Even C++ requires the runtime library pre-installed. Just because they can be embedded with every application does not mean it is not required to be installed. There is nothing exceptional about .NET Framework to deserve a criticism. You can have your installer automatically download and install the framework - even silently if you will. Or packages exists to even embed the parts of .net fx into your installer. Where is the complexity? --soum ^talk 07:41, 30 November 2007 (UTC)

I do think there is a significant quantitative difference between, say, a small app that is entirely supported by a single EXE, and the .Net framework. If I wanted the widest-possible adoption of my calculator program, for example, that's the way I'd plan it. A 5-second download, and it runs. I also think the demand for little apps like this is pretty small, but I think it's ok to mention the consideration. Leotohill 14:11, 30 November 2007 (UTC)

The "plan" would also depend on the amount of dev effort you are willing to put in. If you want the calc to be done in half an hour, you would go for either .net fx or java (okay, generalizations are bad, but, I hope you get my point). Plus there is a very good chance that .net fx will already be there on the client machine. Btw, my previous post was directed mainly at the gross exaggeration of the first post. --soum ^talk 16:19, 30 November 2007 (UTC)

I was speaking purely from the perspective of the end user and not the developer. The complexity and hassle is perceived primarily as the download size and separate installation steps. While C++ applications require libraries, they can be statically linked, meaning we do not need a giant end user download containing lots of code never exercised by the application. The concern is real and if you discuss the problem with shareware authors, you will find they recognize the problem. End users want small downloads for trials, and they want the installation process to be as simple and reversible as possible. .net installers are getting larger and larger with each new version of the framework, and they are not always robust. I personally went through hell trying to apply a service pack for a released version of the .net framework; it was a buggy installer from Microsoft that caused the problem. No KB was ever posted on Microsoft's site for this problem and Microsoft support was helpless to solve it. I discovered many others had the same problem by googling. To summarize, if you use a later .net framework for a small application you risk being labeled bloatware or people have fears of installing Microsoft "packages" because of previous poor experiences with Microsoft applications and installers. This is not a "gross exaggeration" and I suggest anyone who believes it is an exaggeration, to discuss the problem in a mailing list or newsgroup for shareware authors, to see for yourself. Some other comments: [1]Frank Hileman (talk) 15:08, 8 December 2007 (UTC)

Static linking - self contained apps...a good thing? Thats NOT at all a yes or no question. Depends on a lot of thing. For something as basic as a NIO library or a web services stack (which is potentially used by dozens of apps) ... shared library is better, and that mandates dynamic linking. Now if each such library (numbers rivalling as many separate components are there in .net fx) were to be separately installed, that would be a nightmare to manage. In that case, .net fx is definitely a better idea. So, as I said, its all subjective and depends on a lot of things, and not a "real concern" without any other variables.

That said, there is a very high probability .net fx is already installed (either because it was installed for some previous installation or already as a component of the OS). So most apps will not need a "hefty download". IBtw, isn't this the same behavior as Windows Installer itself? Thats not too lite a download. As for increase in size, the later versions are inclusive of older versions (e.g., 3.5 includes 2.0 SP1 and 3.0 SP1). You have the online installer, which is free of this "bloat".

As for the installation issues, I know. I had the problem too. Even verbose installer log was of very little help. For three different issues. But the problem twice was traced to some non-standard system setup. True a part of the blame lies with MS but blaming all on MS isn't the solution. Depends on the issue - for this case as well.

As such, you need to provide claim that this is a problem faced by the majority, not someone's wishlist, and reproducible on demand. Plus attested by a reliable source (sorry, but mailing lists and forums are not). As I already showed, all the problems are very subjective, and depends on a lot of other things. As such, justifying them as criticism would not be so easy. WP is not a bug database. Just because of a bug, something does not get included here. Everything is judged on their own notability. --soum ^talk 16:12, 8 December 2007 (UTC)

"Page views vs downloads has decreased from about 80% to 60%" -- that is not a "reliable source"? That is as reliable as we can get for such a topic. I humbly suggest you provide a reliable source indicating there is no problem : ) .--Frank Hileman (talk) 15:08, 18 January 2008 (UTC)

That's a anonymous comment regarding an unnamed application. Of course it's not a reliable source. Leotohill (talk) —Preceding comment was added at 03:44, 19 January 2008 (UTC)

[2] Not reliable either? Now lets apply the same "reliable source" request to the claim that end users are not burdened or turned off by large, unreliable Microsoft installers running when they attempt to install a small application. Lets see some reliable sources please. Until we have such a reliable source, not based on any statistics from Microsoft, we must not assume everything is peachy in the .net redistribution world. Frank Hileman (talk) 15:45, 25 January 2008 (UTC)

The installers are considerably better than in the past. Let's assume that you install the .Net Framework once... you no longer have to install it when new applications targeting the framework are installed. To test this I just created a .Net 2.0 program with an installer... total size, 681K. That's all I distribute. So, if the client/user does NOT have the .Net Framework on their machine then the installer will download and install the framework which is then the larger package. In the past with Visual Basic 6 as an example your installation package often included everything with it and very frequently could include differnt versions of the same file which was an extraordinary headache for devlopers, something that has been remedied with the Framework's setup. As per the size concern, if we look at Java for a comparison of another managed language framework, the runtime for it is currently 13.92MB for an offline install on Windows and nearly 18MB on Linux [3]. So further, think about this, The .Net Framework 3.0 is installed by default in Vista... that being the case, any program targeting it can have extremely small installation packages because the framework is already there by default. —Preceding unsigned comment added by 74.129.237.241 (talk) 00:12, 5 February 2008 (UTC)

Here is a small example of some frustration felt by an end-user installing a later version of the .net framework. I believe earlier versions of the framework were relatively painless, but .net 3.0 and 3.5 are a pain in the butt for end users. From a review of "ID Vault" on Amazon: "After multiple reboots, software updates, uninstall/reinstalls, uninstallation/reinstallation of '.NET Framework 3.0', installation of '.NET Framework 3.5', installation/reinstallation of same using both the ID Vault install disc and the 'dotnetfxsetup.exe' separately, trying both the downloaded ID Vault software and the original disc, etc. etc., nothing could get ID Vault to recognize the presence of the device." While we might attribute this to poor quality of other software, I believe the frustration with later versions of the .net framework is common. As for reliable sources, none of the Microsoft sources that unconditionally praise .net are reliable. [4] --Frank Hileman (talk) 13:36, 17 April 2008 (UTC) More notes on the pain of the .net framework 3.5 installation: [5] An excerpt: "The install takes forever on XP and installing patches for .NET take forever as well." --Frank Hileman (talk) 13:45, 17 April 2008 (UTC)

(deindent) Just one instance (that too arguably where a separate software is being crticized) cannot be used to demonstrate it being "common". Need reliable citations to claim that its "common" - original research won't work, nor will self published sources. Plus, you might want to educate yourself what reliable sources are. --soum ^talk 13:48, 17 April 2008 (UTC)

According to my personal experience, "reliable sources" are the ones which happen to support the unconfessable biases of some "truth-guardians" @ Wikipedia ^__^ KSM2501ZX, IP address:= 200.155.188.4 (talk) 18:58, 1 May 2008 (UTC)

You win souma. I am tired of digging up sources and having them labeled unreliable. No academic paper will ever be published describing various end user hells created by .net framework installers. The only organization that has any good statistics on this, Microsoft, will never tell us how bad the situation is. By the same standard for reliable sources, probably most of this article should be deleted. What is your name, souma? Are you a "reliable source"? Frank Hileman (talk) 23:17, 22 June 2008 (UTC)

• Hi, just wanted to voice my support for Frank here. I'm a non-techie and wanted to download Paint.net - only to find that this small programme needed the whopping big .net Framework for it. So I didn't download that - instead I came here to see if the programme was useful (and having read the impenetrable article - I'm not really sure if I'll ever need this programme again since there's no list of progs that use it). So basically, Frank has a point that the size is a turn off - and I sympathise with him that there are no good places to quote to use as a source for his comment. BUT Frank, don't give up - only controversial claims need sources - and your claim is logical and intuitive. Soum should be a little less fanatical here and allow what you say because it makes sense god dammit. Malick78 (talk) 15:53, 13 January 2009 (UTC)

.NET on the Mac (via Silverlight)

Since Silverlight (as virtual machine / browser plug-in / standalone app) now supports, contains, or otherwise executes .NET code, and runs native on the Mac OSX, I for one, find it misleading to paint .NET as a single-platform platform.

Can we have a reasoned consensus on this? 72.242.6.114 14:28, 11 October 2007 (UTC)

While it is possible to execute .NET code on non-Windows platforms, through mono or silverlight, the limitations of these solutions still make multi-platform .NET development difficult and often impractical. I think the article should reflect that.Nimrand 03:03, 6 November 2007 (UTC)

I agree with you on Silverlight (infact the current silverlight 1.1 for everything has nothing to do with .NET yet). However, Mono is not as limited as you seem to think. Making anything work on Mono that works on .NET takes very little work if any most of the time unless you are doing something platform specific to windows (like COM interop). The 3.5 features are little behind but it's almost head and head with .NET 2.0 (and some of the features in 3.0). -ZacBowling ^(user|talk) 05:25, 27 November 2007 (UTC)

Silverlight isn't meant for cross-platform .net development. While it does include the (almost) same runtime and gc, the class library is too bare-bones to be called a .net port. If you are interested in writing cross-platform .net apps, write them on mono. Since it is a subset of .net fx, it will work on both .net fx and mono. --soum ^talk 06:11, 27 November 2007 (UTC)

Versions

The versions table is way overkill. Having all of these listed here really clutters up the article. Perhaps all of the detailed information could be moved to another page? This table should contain one RTM for each version, and it should have the latest beta for the version that is not finalized yet. Calwiki 19:34, 10 November 2007 (UTC)

I agree, it is hugely distracting - an ugly blotch on a article that could yet become featured. I'm inclined to just keep the table of versions, and delete all the details. Still, that could be considered useful information, so I do like the idea of moving it to another page. How would that page be titled? "A history of releases of the .NET Framework" ? Is there any precedent for this sort of split? Leotohill (talk) 03:09, 27 November 2007 (UTC)

Ideally we'd change it from a table into prose. A "history of" section would be a pretty interesting addition to the article. -/- Warren 03:16, 27 November 2007 (UTC)

if you mean prose as in an descriptive narrative of the history of .net, identifying participants, key decisions, etc., then yes that could be nice. But what I am suggesting is that we remove the existing text that provides minutiae of each minor version, and leave the existing table which is concise. Leotohill (talk) 03:59, 27 November 2007 (UTC)

Seeing as how people are starting to add to the table again, I am going to ahead and move it. It's just too big, but I'll put the information in another place so that it will not be lost. Calwiki (talk) 00:47, 24 February 2008 (UTC)

I suggest nuking the table and replacing it with a link to the article titled "List of .NET Framework versions" (which for some strange reason isn't listed is the "See also" section; WWTT?) 72.251.90.15 (talk) 14:58, 20 August 2009 (UTC)

Garbage collection

The main article only mentions garbage collection once and gives no details. I feel that G.C. is a very important feature of the .net framework, and the fact that the .net framework is capable of moving objects to eliminate holes and virtually eliminate memory fragmentation. As a programmer, this allows one to not worry about when to free an object, and circular references between objects don't require any special consideration by the programmer--any object that can't be traced back to a static or stack variable eventually gets destroyed.

--Robert Richter Robertbrichter 14:41, 14 November 2007 (UTC) ==

GA nom

I guess it is time for a GA nom. What say? --soum ^talk 13:45, 21 November 2007 (UTC)

We're still short a few references for the architecture and design goals sections. Otherwise I think it has a chance, yeah. -/- Warren 16:12, 21 November 2007 (UTC)

I think it still needs work. See my recent comments on this page. Leotohill (talk) 03:10, 27 November 2007 (UTC)

Title

According to the naming policy mentioned here, shouldn't this article should be moved to .Net Framework or something? - Onmyounomichi (talk) 15:47, 13 December 2007 (UTC)

I'll go ahead and move it if there are no objections. - Onmyounomichi (talk) 16:58, 14 December 2007 (UTC)

Both WP:NAME as well as WP:MOSPN says to disregard the convention and go with all caps when the general usage is almost always in caps. .NET Framework, in all official usage is spelled with capital N-E-T. So, this does qualify for the exception to the convention. Btw, as long as all the proper redirects are in place, how does it matter? --soum ^talk 17:15, 14 December 2007 (UTC)

I'm with Soumyasch. .NET (all caps) is the official name, not .Net. — EagleOne\^Talk 18:26, 14 December 2007 (UTC)

But according to WP:MOSTM, if it's a standard English word, it should use the English capitalization, "Net", right? - Onmyounomichi (talk) 18:52, 14 December 2007 (UTC)

NO. .NET Framework is the official name, not .Net. Therefore the page should stay at .NET Framework. — EagleOne\^Talk 22:39, 15 December 2007 (UTC)

According to WP:MOSTM, "don't invent new formats". .NET Framework IS the standard usage in English. Not .Net framework. (.net framework is not a standard english word. the "word" comes from the trademark). --soum ^talk 01:22, 16 December 2007 (UTC)

"Official name" is not a strong consideration if the formatting violates English language conventions. However, I think that regardless of what is "official", ".NET" is the formatting used by just about every publication, so there would be an "inventing formats" concern with moving it. Croctotheface (talk) 19:49, 20 December 2007 (UTC)

So, the fact that MS uses ".NET Framework" in all of it's official literature and product names means nothing to you? Since when are we supposed to correct the English language violations of companies? I must have missed that memo. No matter what you say, the official name remains ".NET Framework", and therefore the page should be named likewise. — EagleOne\^Talk 18:35, 23 December 2007 (UTC)

Doesn't MOS:TM say to avoid exactly that. Like, where it says KISS should be Kiss? - Onmyounomichi (talk) 15:17, 28 December 2007 (UTC)

And I quote from MOS:TM, the style guide on trademarks: "but, don't invent new formats: For the standardized test, SAT is standard English, while 'Sat' is essentially never used." Why the hell do you want to invent a new name format for the .NET Framework? I still don't see a reason why we should ignore the official literature and name this page ".Net Framework". — EagleOne\^Talk 15:55, 28 December 2007 (UTC)

Quoting from the MOSTM talk page:

Because Wikipedia, like many publishers (e.g. the NYTimes), has an internal style guidelines for consistency and does not simply reproduce the style that any organization chooses to use. For example, REALTOR® is the official style propogated by the National Association of Realtors, who hold a trademark on that word, but saying "REALTOR®" all the time instead of "Realtor" is silly. In the same way, the Wikipedia community decided not to use all caps except for things that are actually acronyms (or psuedo-acronyms like MCI, which is read M-C-I, even though the letter don't stand for anything). Fox, being derived from the publisher's name, is clearly a word and not an acronym and as such our convention is to treat it in Title Case rather than ALL CAPS. Dragons flight (talk) 19:33, 21 December 2007 (UTC)

- Onmyounomichi (talk) 20:05, 5 January 2008 (UTC)

As soum already said, ".NET" isn't just a fancy spelling of the English word "net"; it's actually pronounced "dot net". As such, I don't think the guideline of using standard casing for English words applies here. For brandified but standard english names like Fox, it can use nice to use standard spelling rules. But here, we have something that doesn't exist in the English language. Or at least not in any form other than ".NET". That, and then there's still WP:SENSE of course. – Chip Zero 22:19, 6 January 2008 (UTC)

Still, like "FOX," it's presumably based on a real word, "net" (short for "network"), and the "dot" actually invokes another part of the policy:

Avoid using special characters that are not pronounced, are included purely for decoration, or simply substitute for English words (e.g. ♥ used for "love").

- Onmyounomichi (talk) 05:00, 10 January 2008 (UTC)

I just wanted to say that MOS is not policy, it's a guideline, meaning it's always possible to reach compromise as how a title has to be spelled. Regarding this case, I think ".NET" could be changed to ".Net", but not to "Dot Net"; the latter would be a totally new title. In such a case I would be concerned about the "don't invent new formats" premise: I have seen the title as .NET and also as .Net (and even as .net) but I have never seen it as Dot NET/Net/net. Thus ".Net Framework" seems like a good compromise to me. Kazu-kun (talk) 05:37, 10 January 2008 (UTC)

(de-indent) @Kazu-Kun, you saved me a lot of typing.

That's my point actually; the guideline says that words are equal regardless of unpronounced characters. But the 'dot' is not an unpronounced character; '.NET' is a different word. – Chip Zero 09:17, 10 January 2008 (UTC)

@Onmy...: MOS is a guideline and is not binding. If there is a genuine need to disregard it, it can be done so without consequence. And interpreting the lines you quoted, the "." isnt used in place of "dot" rather its the other way round wherever the exception is made (the filenames, as windows doesnt allow a filename to start with a .)

WP:NAME, which is a binding policy, however, states that "Do not capitalize second and subsequent words unless the title is almost always capitalized in English". .NET Framework falls in this category exactly. True, it has been colloquially called .net framework, .net fx, .Net framework, .Net Framework, .NET Fx and what not. But it is like arguing since leetspeak is also used colloquially, it should be used for official speak. And from the same policy, "Editors are strongly discouraged from editing for the sole purpose of changing one controversial name to another. If an article name has been stable for a long time, and there is no good reason to change it, it should remain. Especially when there is no other basis for a decision, the name given the article by its creator should prevail." I don't see any basis for your request to change the title. What can you possibly gain by changing the title? You are the only one arguing for a name change without any concrete reason, only hopping from one policy to another hoping one would convince others without providing any concrete evidence for a need to change the name. This is strongly discouraged. This discussion is sure to end the dead horse way. --soum ^talk 08:39, 10 January 2008 (UTC)

I started out, after seeing it on the .hack//Sign talk page, thinking the policy was absolute and trying to apply it on other pages where I saw problems. Now I just want to understand it, since I've heard conflicting things (for instance, Kazu-kun saying that the "official" name should be compromised with the policy, e.g. ".Net Framework"). The MOSTM policy (the only policy I've been "shopping") has been used many times to change article titles in the same way suggested here, hence my confusion. Has this been wrong, or why is this an exception? - Onmyounomichi (talk) 04:43, 11 January 2008 (UTC)

Please, don't put words in my mouth. ".Net Framework" was a suggestion from my part; I never say the title should be changed. I'm not interested on changing articles' titles, let alone stable articles. Kazu-kun (talk) 05:16, 11 January 2008 (UTC)

The only thing that defines the name of the article is its most common usage (no that does not mean the usage in casual im talks, but in formal circles). Earlier it was a necessary navigational tool (before redirects) but now it not absolutely necessary but the practise has still prevailed. The guideline serves to summarize the common usages for a large number of scenarios (but by no means all). But if there is anything whose most common usage is different, that is given precedence over any guideline. Also with redirects, handling of alternate names isn't a problem. As such, moving from NET to Net does not give any advantage (even if you could argue with the alt name clause). Without any advantage, stable articles are not to be disturbed. However, say the name is changed to .OFR Framework, then the article should be moved, as it is not an alternate name but a new name altogether. Till then, its best not disturbed. --soum ^talk 05:45, 11 January 2008 (UTC)

Kazu-kun: That's not what I said, I never meant that you thought that specific change should be made. On the Sign page you were pretty adamant about some compromise being necessary on pages like this, and that's all that I said. Has your opinion changed, or was ".hack//SIGN" unstable? - Onmyounomichi (talk) 16:17, 25 January 2008 (UTC)

soum: Wouldn't something important like that be in policy form? If there's one thing Wikipedia likes to do, it's put things is writing. I'm not well-versed in WP, so there could easily be something I've missed somewhere, but unless I see it this will just sound like hand-waving to me. - Onmyounomichi (talk) 16:17, 25 January 2008 (UTC)

Oh, hell,.. give it up, man! Yes, policies are written down here, but they're not written in stone! Just about every rule, guideline, and policy allows for some exceptions. It seems like you want to apply those guidelines simply for the sake of following of a rule. That is NOT a sufficient reason for changing a high-importance article. If you were to effect this change, not only would you be going against the mountain of offcial documentation AND common usage, you'd disrupt the all of the links that point to this article, which is over 500 (see the What Links Here function for proof), all for the sake of following a silly rule! — EagleOne\^Talk 18:18, 25 January 2008 (UTC)

Wikibooks reference

There has been some work done lately on the study guide for certification exam 70-536 on Wikibooks (title .NET Development Foundation). Although incomplete it is usable as is and contains some references back to Wikipedia for related articles. I was wondering if this was the kind of links you would put in the see also section of the article. BTW feel free to comment and modify the book as you see fit :-) --Jacques (talk) 15:32, 15 December 2007 (UTC)

Go ahead and add the template above to the External links section (not see also, as it leads off Wikipedia). Btw, the link you used in the template does not work. --soum ^talk 18:19, 15 December 2007 (UTC)

Thanks for the response. Update is done. The link works (at least for me). Regards --Jacques (talk) 20:17, 15 December 2007 (UTC)

The link is working now. No idea what happened earlier. --soum ^talk 01:23, 16 December 2007 (UTC)

I'm pretty occupied now with the wikibook but if I can be of any help for anything around .NET I'll be happy to try. --Jacques (talk) 02:01, 16 December 2007 (UTC)

This Article Reads Like a Microsoft Press Release.

This reads like PR for MSFT. Where is the reflection of independent criticism that one looks for and comes to rely on from Wikipedia? There is plenty of criticism of .NET published in existing sources. Indeed, .NET has accomplished very little, despite the massive hype and push given to it by Microsoft. Most power-users I know who must use IE remove .NET from their system (or use a scaled back v.1.1 instead of v.3.0, to avoid all the drain on system resources). Is Wikipedia (and the .NET project here) succumbing to the juggernaut of persistence by Microsoft employee sockpuppets, who now are evaluated (in part) by descriptions of their projects on Wikipedia? How sad. NetNot (talk) 01:25, 20 December 2007 (UTC)

You'll need to be specific about what you'd like to change. Or just change it. <be bold!> But be correct, and not POV. Leotohill (talk) 16:23, 20 December 2007 (UTC)

I took a look at the articles for Java_Standard_Edition , J2ee, and Jvm to compare to this one. Those articles have little to say about the reasons for using those technologies, so in comparison I guess this article may look like it is promotional rather than factual. However, in my opinion the articles should describe the justification and goals for the technology. As they (the Java articles) exist today, they are only valuable to a limited audience. They should be improved Leotohill (talk) 21:54, 20 December 2007 (UTC)

The comment about power users using a scaled back version 1.1 instead of 3.0 to save system resources leads me to believe there is a lack of knowledge by that poster on the specifics of the .Net Framework. First, system resources (other than hard disk) aren't used unless a program targeted for that version of the framework is being run. Second, programs are written against a version of the framework, so the user in most cases doesn't have the option of picking and choosing which version of the framework to use (there are cases where, a system admin can setup something like Sharepoint to use 1.1, or 2.0 as an exception) but for compiled programs, users can't choose which version of the Framework to run because said program was compiled against a specific version of the Framework and must use that version to run. If these power users removed the .Net framework 3 and no programs were affected, they weren't using it anyway. The user has the option to install or not install a version of the framework but they can't force a .Net program to use a "scaled back v1.1" if they simply don't want to have version 3.5 on their system. How can your argument be taken seriously with incorrect information and flat out insults included in it? —Preceding unsigned comment added by 74.129.237.241 (talk) 06:20, 23 December 2007 (UTC)

I think that 74.129.237.241 meant to say "leads me to" rather than "doesn't leads me to". Then his argumeent is self-consistent. I agree that NetNot's claims reflect a lack of understanding. Leotohill (talk) 16:00, 23 December 2007 (UTC)

My mistake, and yes, you are correct in how it should have read, my apologies for that. I went ahead and fixed the typo to avoid confusion. Thank you for pointing that out, I appreciate it. —Preceding unsigned comment added by 74.129.237.241 (talk • contribs) 16:40, December 23, 2007

I am an admiring newbie to Wikipedia edits; pardon any protocol error. I write under this 'press release' comment because I logged on to try to figure out more about pitfalls. I am a fairly advanced end-user running WinXP Pro SP3 on a six-year old fairly powerful quite standard Win PC. A new ATI video card required .NET 2.0 for it's "Catalyst" drivers so I tried it. Next I was bedeviled by error messages that were indecipherable (it had made at least 100 registry entries). So not knowing what to do, I uninstalled both .NET 2.0 and the ATI catalyst drivers. Monitor works fine. Usually Wikipedia better helps me understand pitfalls. I come here, and while "press release" may be a bit unfair, I find the article to be very much about what the program does *if it works* which it didn't. This is a pretty clean 1 year old rebuild I'm working with.71.139.14.229 (talk) 16:33, 22 January 2008 (UTC)

I would be surprised if the .Net Framework 2.0 was the problem.. more likely the "catalyst" drivers that were the offending culprit. My suggestion would be to install the .Net Framework seperate and see if you have any issues... if not, then you know it's the drivers. The framework is simply a set of managed libraries. It is designed so that different versions can be on the same system without causing problems to the last (e.g. you didn't corrupt or overwrite anything when you installed it breaking the video). If I write a program targeted for the framework 1.1, installing 2.0 causing no problems because my program will continue to use the 1.1 libraries. Your culprit is likely the drivers. The article is about what it does though as this isn't a troubleshooting forum. I could suggest some sites to help you but I'm also kind of a newbie at this not sure if that's acceptable (my only other edit was on this topic a month or two ago, I was actually reading to see if anyone responded).

The problem is not the drivers per se. I'm another (virtually)new-to-Wikipedia-edits end user who's had the ATI .NET problem. Specifically, it relates not to the actual drivers but to ATI's own grossly bloated (because it's .NET-dependent?) "control panel" application, which can be separately uninstalled, leaving the drivers to be managed in the usual Windows way, which removes all the problems I saw. Unfortunately I've had similar problems with other .NET-dependent apps. Fortunately none of them were essentials so I've ended up uninstalling them all and never wish to see .NET on any of my machines again. Colleagues at work have had similar experiences and reached similar conclusions.

If .NET is the common factor when multiple different disparate apps misbehave in similar ways, it seems to me that .NET *is* likely to be the problem (or at least that will be the perception). Either it's a broken implementation, or it's too difficult for today's typical developers to use correctly (which may mean it's architecturally broken, or that the implementation is insufficiently robust when handling erroneous applications, or just that decent architects/designers/programmers are few and far between these days).

The more important thing which actually brought me here was an attempt to find out whether .NET is a "language-independent" runtime, as it is largely described, or more accurately, a "this-year's-Microsoft-languages language-independent" runtime, which so far seems to me to be closer to reality. Specifically, a truly language-independent runtime would be architected, designed, and documented in a way which would permit the *simple* integration of non-MS languages such as Ada, COBOL, FORTRAN, etc (amongst other dinosaur ones which won't go away any time soon). As far as I can tell, unhelped by the main article, .NET barely has the language independence of the gcc world, although the justification would presumably be that gcc and .NET are different paradigms. Would any clued-up and neutral contributor care to clarify this, 'cos I surely don't see anything in .NET which matches the simple language-independence which VMS had thirty years ago (and still has today, for anyone who cares to look: Ada, BASIC, C, COBOL, Coral, DIBOL... etc)? 80.229.247.139 (talk) 22:01, 24 February 2008 (UTC)

You seem to be asking why the CLR can't work with all languages from all vendors, and suggesting that if it can't, it's not language independent. Language independence means, among other things, that programs written in different languages must be able to share instances of their Types. Therefore it requires that the languages have a common means of expressing their Types, or require a intermediary to translate Type representation. COM and Corba use the intermediary approach, meaning that the solution lies outside the programming language itself. The .NET Common_Type_System (CTS), on the other hand, defines a common representation of Types, which must be implemented within the language. So yes, .NET language independence applies only to .NET languages. The collection of .NET languages (which includes non-MS languages) cannot really be compared to the gcc, which is just a collection of languages that do not have a common type system, and thus cannot share object instances without intermediation. If VMS offered a common type system, then good show, it was ahead of its time in many ways. Leotohill (talk) 06:42, 25 February 2008 (UTC)

(de-indent) All language implementations are outside the scope of the main article. They are not a headache of the runtime, so they are only tangentially related. It would be foolish to expect that info in the main article. Use the navigation aids at the footer to find all related article. For Ada, there is A#. A more comprehensive list can be found at .NET languages. —Preceding unsigned comment added by Soumyasch (talk • contribs) 04:06, 25 February 2008 (UTC)

I agree with the press release portion, but at least there is a criticism section (and a good one that could use some expanding and links). I found the following tidbit interesting, as it applies to me:

"Since the framework is not pre-installed on older versions of Windows an application that requires it must verify that it is present, and if it is not, guide the user to install it. This requirement may deter some from using the application."

I run AdAware on my computer and while the program is usually useless, it noted registry changes associated with the .NET update. The mere fact that there is a suppressed criticism section on the Wikipedia article led me to cancel the installation. Thank you, Wikipedia.Eccomi (talk) 08:15, 7 January 2009 (UTC)

What is the meaning

What is the meaning of ".NET"? —Preceding unsigned comment added by 121.120.83.12 (talk) 12:12, 28 December 2007 (UTC)

I am an admiring newbie to Wikipedia edits, pardon if haven't followed any protocol.Well, to my knowledge the dot in the .NET represents to the current version of the framework. —Preceding unsigned comment added by 202.71.158.90 (talk) 06:34, 1 April 2008 (UTC)

".NET" is simply the name Microsoft gave to this platform. It doesn't really mean too much. Microsoft had to come up with some sort of name. Microsoft probably chose the "net" part to hint at the platform's internet/networking abilities. The dot part does not mean anything in regards to version number. Unless you're actually interested in the etymology of the word...there's no great meaning to the name. In fact, the original (public) name for .NET was NGWS (Next Generation Windows Services). 12.10.248.51 (talk) 13:56, 17 April 2008 (UTC)

The official Microsoft course MS2373, "Programming with Microsoft Visual Basic .NET", states: "The .NET platform is a set of technologies designed to transform the Internet into a full-scale distributed computing platform." --Negrulio (talk) 18:20, 27 August 2008 (UTC)

Design goals and principal features

The Design goals and principal features paragraph should be modified, because it is not backed up by references, and these are not the goals stated by Microsoft itself (see .NET Framework Overall Design Goals. Design Goals as stated by Microsoft are:

• provide a consistent object-oriented programming, whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely (not stated in the paragraph),
• Simplified Deployment: provide a code-execution environment that minimizes software deployment and versioning conflicts,
• Security: provide a code-execution environment that promotes safe execution of code,
• provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments (not stated in the paragraph),
• make the developer experience consistent across widely varying types of applications, such as Windows-based applications and Web-based applications (not stated in the paragraph),
• Interoperability : build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code.

Common Runtime Engine, Language Independence, Base Class Library, and Portability are NOT stated as design goals by Microsoft, so they should be removed from the paragraph. Hervegirod (talk) 11:38, 3 February 2008 (UTC)

These seems to be some marketing-perspective on the topic ("VS 2005 Guided Tour" - says anything, doesn't it?). The principal features currently explained are essentially basic technical features and goals. You can find these in the official standard specification: http://www.ecma-international.org/publications/standards/Ecma-335.htm --Fox —Preceding unsigned comment added by 88.65.66.189 (talk) 00:56, 5 February 2008 (UTC)

Standardization and licensing

I have added a note to the first paragraph to the effect that both proposed ISO standards were withdrawn, going of the status pages linked to in the same paragraph. RobbieAB (talk) 22:32, 31 March 2008 (UTC)

Another .NET Criticism: "Runtime Hell"

Another criticism of .NET is that MS solved one problem (DLL Hell) and created a new one (Runtime Hell). I have taken the latter term from here: [6] A (hopefully) verifiable source for the problem is Don't do Shell Extension Handlers in .NET I'm not sure if this belongs in the article, and how it should be written, but maybe someone will put it in. 84.46.0.134 (talk) 00:50, 20 April 2008 (UTC)

Its not "hell", yet. Have .net 1.1 and 3.5, the chances of facing the problem is greatly reduced. But anyway, the problem is very close to being solved. The Microsoft Silverlight CLR supports side-by-side loading. Just wait for that CLR to show up in .NET, and the problem is solved. Btw, its not just .NET. MSXML, MSHTML, JRE, and lots of others suffer from the same problem - multiple instantiations in the same process not allowed. This problem at least (I believe) is mentioned, whether the dramatized version (runtime hell) should be, I am not sure. --soum ^talk 04:30, 20 April 2008 (UTC)

The phrase "runtime hell" is a neologism. -/- Warren 05:49, 20 April 2008 (UTC)

History section?

I think this article would benefit from a section detailing the history of .NET; how/why it came about etc. - even why it is called .NET in the first place (I have never found an answer to this question). SteveRwanda (talk) 08:11, 26 June 2008 (UTC)

I agree. I came to this page looking for information on the history of .Net. I am especially interested in the personalities involved. I think the guy behind Turbo Pascal http://en.wikipedia.org/wiki/Anders_Hejlsberg was involved. But I came here to find out. Worik (talk) 09:03, 18 August 2009 (UTC)

Suggestion for citation

If you are a .NET developer here I suggest you guys can look at Paint.NET and see if they are written in ASP native code, because I have tested on Celeron processor that codes written in native version do take roughly 30% or less time to load, thus making it suitable for a citation accordingly, Paint.NET v3.35.

I am only guessing they probably are written in native code, because I am a JWS developer not a .NET guy. So...anyhow good luck

== Criticisms==
 Some concerns and criticisms relating to .NET include:
 * Applications running in a managed environment such as the Microsoft framework's CLR or  
 Java's JVM tend to require more system resources than similar applications that access machine 
 resources more directly. Some applications, however, have been shown to perform better in .NET 
 than in their native version.

--Ramu50 ([[User talk:Swetha Rani.P]) 22:45, 30 July 2008 (UTC)

How Many Versions Are Needed?

I realize this sounds more like a forum question, but could someone address the question of how many .NETs do you need installed at one time? Some say the latest version always covers the others, others say you need to install 1.1, 2.0, and 3.0, and now maybe 3.5 too. —Preceding unsigned comment added by 76.111.72.122 (talk) 14:47, 3 September 2008 (UTC)

You need the version that the program you want to run was written against. One version does not cover another version though it is true that some versions are built off of previous versions (for instance, 3.5 is built off of 2.0).

I would find it useful if there was a chart that reported on which versions of .net support applications asking for an older version. For example, I have a machine with a corrupted .net 1.0. I removed it and could easily install .net 1.0 again but could I instead install .net 1.1, 2.0, 3.0, or 3.5 and will existing applications that want 1.0 components/behaviour work?64.60.120.145 (talk) 01:33, 10 November 2008 (UTC)

I am not sure how to format such a table. But here is the answer: .NET Framework 1.1 would suffice for 1.0 and 1.1 apps, and .NET Fx 3.5 would be enough for 2.0, 3.0 and 3.5 apps. I am not sure about 4.0 - while it looks like it is an incremental update over the version 2.0 runtime (which powers .NET Fx 2.0, 3.0 and 3.5) and so should take care of the older apps, it is nevertheless a different one (as it supports side-by-side loading, which the 2.0 runtime did not). So there might be incompatibilities. Best would be to install 4.0 as well once it is available. --soum ^talk 05:04, 10 November 2008 (UTC)

giant .NET 3.5 SP1 KB951847

On about 27jan09 MS pushed out the giant 250MB .NET 3.5 SP1 KB951847 via auto-update. Some users report various problems, typical of giant Service Pack installation. It is reported that even if the file is downloaded manually and installed that way, the auto-update tries to download the whole thing again:

http://www.annoyances.org/exec/forum/winxp/1233328930

"This is a large file and takes a bit to D/L and install. I install NetFramework on all our customers XP Pro new builds. So I thought that I would just D/L and save the file to my thumbdrive with the rest of my needed installation files and then just install it manually. Well, surprise, even after a manual install, MS Update insists upon D/Ling and installing it again, same KB951847. What am I missing here?"

This SP forces new extensions and plugins into Firefox, without notice or option, and does not allow removal. The article should mention this.

http://forums.mozillazine.org/viewtopic.php?f=37&t=1064265&start=0&st=0&sk=t&sd=a

"I found that this Microsoft Update had installed the extension Microsoft .NET Framework Assistant 1.0. It also installed the plugin Windows Presentation Foundation."

"I am incandescent about MS adding this to MY FF installation without so much as a "by your leave" AND THEN not giving the option to uninstall it. The naive arrogance of MS is the absolute limit and why, after 10 years of web development on MS platforms I'm now moving to Linux."

-68.236.103.195 (talk) 15:08, 31 January 2009 (UTC)

See Also section

This section is supposed to be for related issues which are not discussed and linked in the article, not a list of randomly chosen topics that someone happens to find pertinent (what is the justification for the links if they're already discussed and linked? Why those links? What makes them more important than the other few hundred in the article? etc...).

As such, I have removed all the links which are already linked. Please do not add them again without specific reasoning.-Localzuk^(talk) 10:55, 4 May 2009 (UTC)

This comment is supported, in general, by WP:SEE ALSO:

Links already included in the body of the text are generally not repeated in "See also"; however, whether a link belongs in the "See also" section is ultimately a matter of editorial judgment and common sense.

PL290 (talk) 11:48, 4 May 2009 (UTC)

v1.0 SP1 and SP2: Did they ever actually exist?

Yesterday I was attempting to set up a series of virtual machines with different version of .NET for testing changes to some legacy software.

To my surprise, v1.0 SP1 and SP2 apparently are not available on any Microspft website or on any of the usual sites that archive this sort of thing.

The "Did they ever actually exist?" title above is tongue in cheek, but those particular service packs certainly appear to have managed to do a complete disapearring act. Is a "no longer available" note in the article justified, or am I just really bad/unlucky at web searching?

Also see my comment on the talk page for the "List of .NET Framework versions" article where some of the links are bogus. 72.251.90.15 (talk) 14:58, 20 August 2009 (UTC)

.NET Framework 3.0 SP2 is also completely missing from the Internet.

Also, .NET Framework 3.0 and .NET Framework 3.0 SP1 are downloader files only; they dowload the actual software from Microsoft (until the day that Microsoft decides to close that page, at which time hey too will be completely missing from the Internet.) I think there may be a way to extract a full copy from Windows temporary files.

Another oddity; you can download and install .NET Framework 3.5 SP1, but when you run Windows Update it will install something else also called .NET Framework 3.5 SP1.

75.84.238.18 (talk) 12:20, 23 August 2009 (UTC)

a jargon free overview section on common uses needed

  99% of the folks looking up this subject probabbly are like me and want to know if these gigantic files are really necessary on their computers. Nowhere did I see (before I fell asleep from all the techical speak) any mention,in laymans terms,why we actually can't live without this framework stuff. Can it all be deleted? What are some examples of every-day programs which MUST have this Framework stuff?
PLEASE! Not everyone is a computer scientist.BrianAlex (talk) 14:24, 7 September 2009 (UTC)BrianAlex

funny the little corners of the internet you can find, like when opening a doll's door in the antic reveals a cubby space of dust and cobwebs. Anyway, I'm with BrianAlex, I went from downloading a simple open source avi to flash converter to downloading a 50mb runtime library or whatever this is -- I just want to know if this is an industry standard or if I should move on to finding another free program with less of a headache to install. A section detailing industry reception, common use, and current trends would be helpful. Wiki can sometimes feel like a front in forever raging wars, culture or otherwise... StevenPine (talk) 19:12, 9 September 2009 (UTC)