Talk:.NET Framework

From Wikipedia, the free encyclopedia

Peer review .NET Framework has had a peer review by Wikipedia editors which is now archived. It may contain ideas you can use to improve this article.
This article is part of the .NET WikiProject, an attempt to improve and organize the .NET content on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
B This article has been rated as B-Class on the quality scale.
High This article has been rated as high-importance on the importance scale.
This article is part of WikiProject Microsoft Windows, a WikiProject devoted to maintaining and improving the informative value and quality of Wikipedia's many Microsoft Windows articles.
B This article has been rated as B-Class on the assessment scale.
High This article has been rated as high-importance on WikiProject Microsoft Windows's importance scale.
To-do list for .NET Framework: edit · history · watch · refresh

Here are some tasks you can do:
  • Verify: Add sources and references
  • Stubs: Expand criticism section
  • NPOV: Work on the "Significance" section
Priority 2  
Archive
Archives
About archives • Edit this box

Contents

[edit] 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.[1] 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.[2][3] According to a statement on the blog of Mono project leader Miguel de Icaza,[4] 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.[5] However Eben Moglen later said that he was quoted out of context,[6] and referring to possible changes that could be made to the GPL version 3, that would block similar deals in the future.


Signed Lyml 09:45, 20 September 2007 (UTC)


Speaking of cleanup, this point:

  • Several developers[7][8] 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)

[edit] 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)

[edit] .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)

[edit] 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)

[edit] 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) ==

[edit] 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)

[edit] 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)

[edit] Wikibooks reference

Wikibooks
Wikibooks has a book on the topic of

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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)