Colloquial name for the CommonLanguageInfrastructure/CommonLanguageRuntime (and probably several other CommonLanguageSomething abbreviations that i can't think of right now). See MicrosoftDotNet for MicroSoft's implementation, and MonoProject and PortableDotNet for OpenSource/FreeSoftware implementations. ---- '''When Should We Use .NET ?''' * ''When you boss asks you whether you are with him, or want to seek better opportunities elsewhere '':) This is the most important or at least the very first question to be answered of all. But here, just as everywhere else, silence reigns. I've been raising the why-question for over a year now, but got only two answers, both of 'm not very convincing: * ''because everyone's going to use it'' * ''because Uncle Bill wants us to'' WdW Ok, if you want some real answers from Microsoft, use .NET...: * because you get stuff done faster - building stuff is easier * because what you build runs more reliably and faster These are essentially the same reasons people moved from C++ to Java. Now hold on, I hear all you C++ weenies saying, "wha? Java faster than C++?" and the answer is, "Sure!" in many cases. And the same applies to .NET. Complicated things get much simpler in the managed runtime of .NET, and therefore run more reliably. Also, because the common language runtime does lots of work for you, in an optimized way, oftentimes real world apps will be faster. a micro-benchmark like linpack will still be faster in C++, but most real-world apps will run better in a managed environment. This is borne out by customer experience. .NET 1.0 was introduced in February 2002, 1.1 in April 2003, and 2.0 in November 2005. In all cases customers began using it because they get stuff done faster, and the stuff they get done, works better. If you listen to MiguelDeIcaza, progenitor of Mono, he selected the .NET model because it fostered re-use. --DinoChiesa ---- '''When Should We Not Use .NET?''' * ''When BillGates tells us he has the NextBigThing ready'' Again, for some real answers from Microsoft, don't use .NET when...: * you want maximum possible performance and you are comfortable with C++ * you are building device drivers (in which case use C++) * you want maximum performance in database logic (in which case use T-SQL) * you don't want your executable to be decompiled (as in reverse-engineered) Otherwise, .NET is the mainstream model for applications that run on Windows clients, devices, and servers. --DinoChiesa ''heh, I initially read 'in other words' for otherwise'' ---- ( rant removed, because BadCodeCanBeWrittenInAnyLanguage ). Please point me to some programs which use DotNet that do anything useful? i.e. what exactly is the point, in real world terms? (bill-me for Smilies, bill-me for emotioncons? bill-me for conversations? Through a virtual machine of some sort, versus through TCP/IP? Sorry, I'm missing something here.). The point is, it's easier to build. Some examples of real things built on .NET: * Snap''''''Stream's BeyondTV - PVR built entirely in managed code. * Paint.NET - open source photo editing package built in .NET, see http://www.eecs.wsu.edu/paint.net/ * Broderbund PrintShop 20 Deluxe and PrintShop 20 Professional Publisher Deluxe * Autodesk's AutoCAD 2005 * SVCD2DVD - see http://www.svcd2dvd.com/ * Dot''''''Net''''''Nuke - portal built on .NET and ASP.NET * Rss''''''Bandit - free RSS aggregator , see http://www.rssbandit.org/ * Community''''''Server - portal, forums, blogs, gallery; see http://communityserver.org/default.aspx * SQL Server Reporting Services * Jet''''''Brains Omea Reader - see http://www.jetbrains.com/omea/download/reader.html * Windows UDDI Services - part of Windows, built in .NET * Office 2003 Business Contact Manager - part of Office, built in .NET * GB PVR - personal video recorder (currently free) - http://www.gbpvr.com/ * Windows Media Center - extensions almost entirely built in .NET * other PVRs too * SharpDevelop - open source IDE built entirely in .NET, see sourceforge.net/projects/sharpdevelop * HgLab - source control management system for MercurialVersionControl with push and pull server, streaming support, repository browser, ActiveDirectory integration and a whole slew of other goodies - http://hglabhq.com * FlexWiki - open source Wiki built in C# (and running on .NET), see sourceforge.net/projects/flexwiki/ * a number of other wiki's too ---- '''Frequently and Not So Frequently Asked Questions''' Q. '''Is MicrosoftDotNet just a fancy term for Client/Server?''' A. No. .NET implies managed code, a common language runtime and base class library. Q. '''Is MicrosoftDotNet better thought of as a system of federated services (on servers) for clients?''' A. No. There was a thing called MicrosoftHailstorm, which was intended to be a federation of services. But that did not happen. It was announced around the same time as the .NET Framework, but never delivered. Q. '''Why the confusion around MicrosoftDotNet ? ''' A. Probably because Microsoft attached the .NET moniker to every product that got revised within a certain window, and so the marketing term had no value or meaning. But since then .NET has been "pulled back" to refer primarily to the common language runtime, the base class library, and the associated technology. ---- '''Discussion about Reformatting this Page''' ''note: this page currently has 171 BackLink''''''s, whereas MicrosoftDotNet has 104. One of them should probably be refactored out, but not without someone updating the relevant pages - replace references to DotNet used in a vendor-agnostic context with links to CommonLanguageRuntime or CommonLanguageInfrastructure, maybe, and references where it's used to refer to Microsoft's implementation with links to MicrosoftDotNet?'' --MikeRoome * MicrosoftDotNet is a mouthful, and I also use DotNet in the same page later on. If I edit a page that discusses a generic technology, and I want to introduce an MS perspective, then I would be tempted to use the full name the first time around. I think for searching related topics one should probably look at it from CategoryDotNet, then go through DotNet links for additional entries. I would not use MicrosoftDotNet What do you think, Mike? -- DavidLiu Given the existence of GNU pNET and Mono, MicrosoftDotNet would not be an accurate WikiName. Granted, .NET is specifically a microsoft term (when it's not a TLD) but it's become pretty much generic * I take your point, but at this moment (2004) DotNet from nonMicrosoft sources is not commercially viable (or am I wrong?). When we start seeing other versions of DotNet being used in Fortune 500 companies then it is time to re-examine the names used here. -- DavidLiu * I suggest for now it is sufficient to mention that other DotNet initiatives exist (outside MS), and these efforts are laudable. -- dl * I think the Mono guys would be very unhappy with that statement, they have released 1.0 as of June, and I've heard it's pretty damn good. ---- ''because you get stuff done faster - building stuff is easier'' Could you go into a little more detail? Is this entirely because of ManagedCode, or is there something else involved? ''In all cases customers began using it because they get stuff done faster, and the stuff they get done, works better.'' InAllMyYearsIveNever seen anyone ''begin'' using something for those reasons. People begin using a new tool because they ''suspect'' this tool might help them do stuff faster/better. I'll probably begin using DotNet next week. I might use it for a few weeks and then decide I get no benefit from it, and toss it. Or I might decide it's kinda nice and keep it. There's really no way for me to tell right now. That's why I'm doing the experiment. I *am* pretty sure, ahead of time, that it won't let me develop an order-of-magnitude faster, because the NoSilverBullet essay by FredBrooks has pretty much convinced me that's not possible. It would be nice, if I knew what sort of more subtle 5% and 10% improvements to look for in this experiment. What tasks am I'm doing right now that this Dot Net lets me skip over, so I can focus on more important stuff? ---- I started using .NET back in 2004, when it could have been described as an "emerging" platform. I dove in the deep end, and rewrote our main product - a high-end 3D game engine and tools - in C#, and was pleasantly surprised. I'd never even consider writing complex game code in C++ again. .NET 2.0 made things even better, and now .NET 3.5 with C#3 is incredible. I think the biggest wins here are: * If you simply cannot write through a stray pointer (because there are none!), all those *really nasty* memory bugs go away. You don't need the debugger nearly as much. * The library is (for the most part) decent. Sure, there have been the occasional BrainFart contributions from Uncle Bill (Managed DirectX and its successor, XNA, are definitely two of them)... but the basic stuff - strings, collections, networking - are very usable. The newest stuff ("MicrosoftLinq") is also interesting... we've found we like all the new library support it adds, but shun the SQL-like syntax. * If you need to do interop with legacy stuff - COM, native DLLs, etc - it's generally painless. For the really tricky cases, (COM without a useful typelib, a la DirectX) C++/CLI is great. * The performance is great. Its good enough to build cutting-edge 3D games in - I know, because we've done it. Maybe 5% hit, but the productivity benefits are worth so much more than that. All in all, for anything but the most constrained embedded development, I'd recommend it. Well done to Uncle Bill on this one. ---- I haven't written a high-end 3D game engine, but I think XNA is pretty good, certainly good enough for a hobbyist game programmer. --------- '''Configuration Hell''' I'm trying to switch to dot-net, and am having tons of headaches trying to get even basic Hello World programs to run the same on test and production server. (That's why I've been so quiet of late.) I've googled all over for tips and add funny bureaucratic tags, remove funny bureaucratic tags, etc. and still the sucker won't run right on both. I've never had this kind of crap using ColdFusion for almost a decade. Version 6 CF apps usually ran just fine on version 9 on both test and production without a single fricken change to the source code, and the few that did need changes were obvious to track down. It makes DLL-hell look good in comparison. Changes in dot-net source fix one thing and break another in a diff environment. Dot-net appears to be a potpourri of disparate and different-schedule-of-change components forced together under the polluted glue known as "dot net". Arrrgggg. -t ''You mean you're trying to switch to ASP.NET? *.NET is a much, much bigger world than just the webby stuff. It's kinda like how the Java world is much bigger than just JSP. In fact, it's exactly like that.'' * EditHint: feel free to move it to a more appropriate topic. ''I solved all my ASP.NET problems by using PHP. Almost simultaneously, my office-mate solved all his PHP problems by using ASP.NET. I'm not sure what to make of that, except to note that there seem to be UNIX people who can get things done with PHP whilst Microsoft things break, and there seem to be Windows people who get things done with ASP.NET whilst UNIX things break. Maybe you're a UNIX person?'' Unfortunately, I didn't have a choice of language/tool. It's what the shop uses. I'd much rather use PHP if given a choice. (I've used PHP before, but I still prefer CF's less type-tag oriented typing system to PHP's). And ASP.NET does remind me of Java in many ways. When MS clones something out of fear, they really do clone it. Part of the problem is that I need "conditional controls". If your controls are static, then ASP.NET makes things fairly easy via click and drag. However, key parts of this app are not static. Their display order changes and are mixed object "types" such that a "repeater" control won't work. MS in general makes things easy if you do it THEIR way, but convoluted if you wander off the beaten path. And, why the hell does it take 5 classes to issue an SQL query and loop through the results? Should only be 2 classes for common queries and 3 under special circumstances. ColdFusionLanguage was easy to learn to use and remember data-wise because most queries were done via something similar to following construct: SELECT * FROM foo WHERE bar = #integerSqlParam(myID)# ... It wouldn't matter if the data came from MS-Access, MySql, Oracle, etc., the construct remains pretty much the same. The vendor- or configuration-specific differences were all in the "configurationClausesPlaceHolder..." attributes, not in the general data handling interface and root classes. I don't see anything similar in the Dot.Net framework unless one writes it themselves using the gajillion different ways to do it for each vendor or RAM configuration. It's a similar issue to that near the bottom of JavaIoClassesAreImpossibleToUnderstand which revolves around whether configuration details should be "parent" over a more general interface. (The above does have a few downsides I will admit, but only for blue-moon needs. Also, much of the DB setup is done in the DB configuration console, not in code in newer versions, but this is a concept illustration, not a CF version critique.) -t ---------- Does anybody have any suggestions for make apps be '''DB-vendor neutral''' so it's possible to switch in one place rather than hard-wire the code to a particular DB brand? The built-in data-source controls don't seem to support such that I can find that works well with other data-centric controls. I've only found very round-about bloaty ways. Is this a trick to lock people into their DB brands? -t Here's an article about using the Sql-data-connector with ODBC pre-configurations, but in my case I'm using OLE and can't change to ODBC. One of these days I'll try to see if it can be rigged for OLE. http://msdn.microsoft.com/en-us/library/35c54x95%28v=vs.80%29.aspx ----- '''Opaque Widgets''' Does anyone know how to "escape into HTML mode" in a method in the App_Code folder? Using bunches of Print statements is not a friendly way to emit HTML. It's as if functions/methods are 2nd-class citizens. This kind of thing was a no-brainer in "scriptish" web languages. ''You'll need to be more specific about what you are trying to do. If it's what I think it is, then you can't as there is no "HTML mode". However, there should be objects that you can use that take care of all the print stuff for you.'' For example, in PHP you can do this: function drawRow(row) { ?> Thing Thing #myRow.first_name# #myRow.last_name# #myRow.IQ# It can make code a lot easier to read than "print" statements if a lot of HTML is being used. It is true one can create function/method wrappers such as "drawCell", but sometimes for intricate output it's very helpful to have the fine control of direct HTML. It's more WYSIWYG. (This example doesn't really illustrate the value of simplification. I'll see if I can present a better one later.) -t ''No need for another example. As far as I can tell, my original response was correct. You simply can't do that. But, I still don't see why you need "print" statements or "drawCell" wrappers. You could be using the objects already provided by .NET (e.g. TableRow, TableCell) and let ASP take care of the rendering (the "print" and "drawCell" stuff.)'' I haven't figured out yet how to "intercept" and adjust those. They are too blunt out of the box. I need conditionals etc. to fine-tune and tweak values and attributes dynamically. Just dumping cell values from the table into auto-row-objects as-is often produces ugly and/or misleading output. It usually needs a tweaking stage. Sure, they "take care of the rendering" for you, but in their own wrong or unexpected way, like a new maid who's never seen your house before. Also, they seem limited. For example, the built-in drop-down list has no equivalent to OPTGROUP (the last time I checked). I keep running into walls where they get me 80% there but I thrash around trying to get the other 20% (EightyTwentyRule). Similarly, their image button widget works fine if you hard-wire in each picture, but I needed to do it dynamically from a folder listing and couldn't figure out how to do that in a timely manner. Their ID's had to be known to the compiler up front. The framework designers were all too happy to expect everyone is okay to hard-wire in everything. There's a big learning and/or re-coding DiscontinuitySpike going from the drag-and-drop widget's built-in behavior to fine control via code. It's been easier just to create my own damned web objects/library. And when I web around to find the work-around's when they exist, they are often very clunky and counter-intuitive. Maybe I am going about it all wrong, but not sure where. It's too much like Java's libraries: deep, obscure, round-about, and bureaucratic when you want to do something outside of the base-line usage or defaults. I just want a baloney sandwich, not go to butcher school. Others have said that's how MS locks into their world: you spend so much effort trying to get their stuff to work like you or the customer wants that you don't want to leave MS and "waste" that investment in MS tool fiddling experience. I can tweak my own web objects in ten minutes when it takes 4+ hours of googling and/or trial-and-error to force MS's built-in's to do it right. Plus, my own web libraries and techniques can usually work in just about any language because I'm leveraging the HtmlStack, which most every language has to use anyhow for web stuff. If I change to another language, that knowledge still applies. Using MS's libraries only applies to MS's stacks. If you are born and die with MS, that might be okay. It's certainly what MS wants to happen. Maybe I'm just a better programmer than I am a configuration googler (relative speaking); and export configurators find the opposite? Or do they just live with MS's ugly defaults and limits such that users just live with half-baked sluge, doing their own form of trial-and-error dance? I'm not a perfectionist, but I do want to avoid phone-calls and help-tickets from confused and angry users. My own web objects are rarely longer than two pages of code and are well-commented. Even the most complex rarely takes more than 45 minutes to grok and change (or copy and customize). An MS object issue takes roundly an average of 2 hours work around or fix. Maybe if I did asp.net for 5 years the time would become comparable. But then some other newfangled language or fad will probably displace it. And what would all the google-configurator's do if the product came from a smaller software company such that the web workarounds were few and far-between? I guess market-share gives you more freedom to suck. As described in HelpersInsteadOfWrappers, it's usually best to date your objects/abstractions/frameworks, ''not'' marry them. MS forces you to marry them, and Bill Gates is not very good in bed. (See also "Click-able Thumbnail Anecdote" in that topic.) -------- Another thing I miss from ColdFusion is the CFdump command for troubleshooting. One can use it to display (dump) an array/query/structure. PHP has similar automatic textual serialization of arrays. I haven't found the equiv in dot.net yet. (Or does each structure have to re-invent it to supply it?) ------- Re: 'As far as I can tell, my original response was correct. '''You simply can't do that'''. But, I still don't see why you need "print" statements or "drawCell" wrappers...' [emph. added] Regardless of the outcome of the "need" debate; to me it's pretty stupid and pre-limiting to only allow the HTML-friendly mode in the outer layer of abstraction or call tree. '''Why hard-wire such a limit into a language stack?''' It's just plain stupid -- an arbitrary wall. I'm calling MS on that one. DotNet was supposed to fix dumb limits and arbitrary shit over VB-classic. They blew their opportunity. It's either a glaring mistake, or a way to obtain VendorLock. If you want people to take your language seriously and trust you with years of blood, sweat, and tears creating and maintaining source-code, you cannot jack it up like that. Thank You for letting me rant on this. --top ''What makes you think that only HTML friendly mode is required in the outer layer of abstraction? I've done plenty of things in .NET that don't involve HTML at all. It's only ASP.NET that really requires it, but that's not surprising since that's its purpose.'' I'm not understanding that statement. I want HTML-friendly mode as an ''option'' for inner calls, regardless of whether it's used or not for a particular function/method. I never said it should always be used. ''I see I made a mistake about what you wanted. I thought you were claiming that .NET requires HTML at the outer layer, not that you want HTML in the inner layer. That said, is there some reason StringBuilder won't do what you want?'' For one, you lose WYSIWYG ability in the IDE. Second, if you use the built-in widgets, then it's not easy to "escape into strings" in the lower levels. They don't seem to have hooks for that. In for a penny, in for a pound. At least colleagues and I haven't figure out an easy way to do such. It makes for some really ugly work-arounds. ----------- '''Database Config''' On a similar vain to the above, it appears MS '''hard-wires''' database control also for most of its widgets. For example, I haven't found a way to select/determine the database source at run-time based on a connection string (which looks something like "database=mybase,driver=sqlserver,username=foo,etc") except in self-rolled widgets. It is possible to give a connection string a reference name in the "web.config" file and use that name in MS's widgets, but not change the reference name nor the connection string dynamically at run-time. (The reference name is not a "normal" variable that I can tell.) Maybe '''dynamic languages have spoiled me''' or ruined my thinking somehow, or I'm missing some special knowledge or skill to deal with Java-style-clones. These things are no-brainers in most dynamic languages, so why are they a pain to find or solve in ASP DotNet? Is it a ''necessary'' sacrifice to obtain Intellisense (IDE assistance pop-ups)? -top ''Is there some reason the ConnectionString property doesn't work for you?'' I couldn't get it to work with built-in widgets. Sure, it's probably doable somehow, but not intuitive the way it is in dynamic languages. In general, the "static" way to do things in DotNet seems to vary much from the dynamic way to do the same thing such that one has to '''dig and fuss and recode to change from static to dynamic'''. There is no switch-over hump in good dynamic languages because there's no static version to begin with. -t ------------- An example of rolling your own web component is as follows: you have a form where a name/value pair takes up either an entire row, or half a row for smaller fields. I often roll app-specific calls that may resemble: @ // first sample row fullField("Title", titleVar); ' // 2nd sample row leftField("First", firstName); rightField("Last", lastName, required=true); ' // 3rd sample row fullField("Street Addr.", street); ' // 4th sample row leftField("City", city); rightField("Zip", zipCode); ' Etc... @
(Tick-marks are a work-around for a wiki render bug.) The functions take care of all the cell formatting for me, hiding it away. It's compact and easy to follow; an example of WorkBackwardFromPseudoCode. DotNet makes this kind of thing more difficult. True, it may reduce pre-run validation ability, such as miss-matched pairs, but I'll take that as a trade-off. I place code-readability over machine checking. Note that one is not obligated to use the short-cut functions for formatting. If a specific row needs special treatment, then make custom code for that one. Also note that it may be better to make the layout type be an attribute rather than part of the function name, such as "layout=[left|right|full]". Generally one tunes the interface to their environment anyhow. ------ CategoryDotNet