Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Operating Systems Software Windows IT Technology

Why Doesn't .NET Include a Linker? 113

Posted by Cliff from the down-with-static-executables dept.
CrypticSpawn asks: "I read an article on Joel on Software it talks about Microsoft missing one important thing from the .NET infrastructure, and I wanted to know what Slashdot readers thought were Microsoft's reasons for leaving [a linker] out?"
This discussion has been archived. No new comments can be posted.

Why Doesn't .NET Include a Linker? More

Why Doesn't .NET Include a Linker?

Comments Filter:

  • Do you mean... (Score:3, Funny)

    by Anonymous Coward on Saturday January 31, 2004 @06:29PM (#8146395)
    Something similar to the JAva linkeR ???

    I've used it-- very effective.

  • One possibilty (Score:5, Insightful)

    by sbennett ( 448295 ) <spb.gentoo@org> on Saturday January 31, 2004 @06:31PM (#8146413)
    One possible advantage to always dynamically linking: when some nasty bug in the runtime is found, it should be easier to upgrade the runtime than to relink every application that's been linked statically to it. Of course, people won't actually bother to upgrade, but you can see how the theory goes.

    Yes, I say when a nasty bug is found, and not just because it's a Microsoft product. No matter how good the software is, there's always at least one critical security flaw.

  • silly objection, and- you can get a linker! (Score:5, Interesting)

    by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Saturday January 31, 2004 @06:32PM (#8146419) Homepage
    where is the surprise in this?

    first of all, you can get a linker [remotesoft.com] for .NET if you want. like similar tools for perl and python, it packages everything up that you need into one exe. this took 10 seconds to find via google. Perhaps Joel should try google next time. What is this, ask slashdot? :)

    there is nothing different about the way .NET does this and any other system. Sure, there isn't a way to link it all into one .exe file, but that may come in the future. that is, in perl and python (among others) that was the case at first- you had to download a big runtime and possibly other libraries to get your app working. these days, you can distribute your app in that way- a 20KB download of your .pl files,or a big-ass executable that integrates all the requisite libraries, VM/runtime system, etc etc. however, this often ends up giving you a file that it almost as big, but at least, it is a little simpler on the user.

    again, Java does this too. If i have a .class file or jar, there isn't some way to encapsulate it all into one double-clickable executable file that I can share. I have to have my users download a big package, the other libraries, and then my app. .NET is no different, and there is no reason to expect it to be. joel gripes, saying that microsoft will come out with a new version every few months. just like with new versions of perl, python or java, there is no reason that the user would neccesarily have to have the brand-spankinest newest version. if your app requires it, you make it a requirement. put it on the CD, and say- install this if you don't have it yet. big deal. if you were smart, you'd write your apps against the most common verison- .NET 1.0 or 1.1 for now, just like a lot of Java apps are still written for Java 1.1, not even Java 2! Most folks don't write apps for the newest Java, 1.4.x unless they really need it.

    what the hell is so different about how .NET does it?

    • Re:silly objection, and- you can get a linker! (Score:5, Informative)

      by kzeddy ( 529579 ) on Saturday January 31, 2004 @06:38PM (#8146454)
      this linker shown above does nothing more than merge all the classes used by the application into one big assembly. it does not turn the code into native assembly or link into the assembly and mini hosting environment which is what joel is talking about. YOU STILL NEED .NET

    • Nuisance (Score:5, Insightful)

      by GCP ( 122438 ) on Sunday February 01, 2004 @01:22AM (#8148640)
      where is the surprise in this?

      It's not that it's a surprise. It's just a huge annoyance.

      Microsoft talks about how much easier it is to create Windows apps with .Net than with the old VC++/MFC approach, and that's so completely true that after you see what you can do with C#/.Net, you can't bear the thought of going back to C++/MFC.

      But the fatal flaw for Spolsky and others in his position (including me on occasion) is the delivery of such apps to the enormous installed base if you can't deliver via CD-ROM. Then you're in the same position as people who would rather work in Java or Python or Lisp: your elegant little app has this huge boat anchor of a runtime to drag along with it, and people in the general installed base who get your app via download simply won't put up with it.

      VC++/MFC have a huge boat anchor of a runtime, but it's Win32 itself, so it's invisible. The majority of the installed base out there can be counted on to have a huge library built into Win98 (likewise for Linux), and all you need to statically link is whatever wasn't already included in Win98.

      For a C(++) developer on Win32 or Linux, this doesn't usually add much baggage, so I almost always statically link and save my users from dependency hell.

      But for developers in anything else, the runtime is a major impediment to commercial viability (for certain scenarios).

      At first I wondered why MS didn't just AOL the world with .Net installer CDs in everybody's mailboxes. I gradually came to the conclusion that it's because they were essentially gamma testing it first on those more savvy users who could figure out how to obtain it and install it themselves, especially on the server side.

      It appears as though they plan to give themselves some time to work out the bugs and flaws in .Net and gradually insert it into the new OSes, allowing the upgrade cycle to control the speed of adoption. The least likely to upgrade will be the least sophisticated users that way, and therefore the people least likely to be able to handle the inevitable bugs in .Net will be the last to get it.

      It will take a few years, but .Net is a powerful replacement for the Windows API that will eventually be built in to all Windows machines (and others, if MS gets their way), and then you'll be able to safely deliver a C# app without the runtime.

      Of course it's an open question whether developers like me will be willing to wait. The major attraction of Windows for me is the huge market that the installed base represents. The OS itself is of little interest. But it's hard to take advantage of that installed base opportunity using .Net apps at the moment, and I can't see starting anything new with MFC (Yuck! I'd be stuck doing MFC maintenance for years to come). The best way to take advantage of .Net right now is on your own machine -- some sort of server-based app. Well, if it's a server scenario, then what the installed base is running is irrelevant, and I'd prefer to use something like Python or Java or even Lisp on Linux. (We'll see how C# on Linux turns out with Mono later this year with the release of 1.0.)

      If there were a way to take a 300KB C# app and turn it into a 1.3MB windows *.exe that would run on a plain vanilla Win98 machine, that would change the economics for me as it would for Spolsky. Otherwise, well...we'll see....

      • They want to push .NET in the enterprise (thats where they make money, consumers are a secondary market). Hopefully, .NET will then trickle down to home users, and people will want to upgrade because the apps they use at work require it.

        (As an aside, as a C#/.NET developer myself, app deleveopment with .NET only seems easy because MFC was so friggin bad. Using a good toolkit library makes working with friggin Windows Forms feel like ripping my own testes off. It's better than Java and thats about all I hav

      • It's not that it's a surprise. It's just a huge annoyance.

        It won't be, when everyone upgrades to XP, you won't have to worry about this. They won't be making the choice to upgrade either. When people go out to buy a new PC they will get XP installed on it. Give it another year, and most of the consumer population will have it on their PC's.

        Second, the download is 25 megs - really, it is not that bad.

      • Re:Nuisance (Score:3, Interesting)

        by crazyphilman ( 609923 )
        Well, ok, I see why you might find this annoying, but look at it from another perspective:

        First of all, because you're compiling to CLI and using a runtime, you don't have to recompile your code every time a vulnerability comes out and you decide your users should patch. They patch the runtime and the app keeps working (knock on wood). A related benefit is that as the runtime improves, your users get a performance boost without you having to lift a finger, if, that is, they're keeping up with their patches
    • again, Java does this too. If i have a .class file or jar, there isn't some way to encapsulate it all into one double-clickable executable file that I can share.


      Sure there is. Just distribute the jar file.

      Of course, this doesn't work for the Windows-impaired, because Microsoft are never going to make it easy to run Java executables.
    • "Java does this too. If i have a .class file or jar, there isn't some way to encapsulate it all into one double-clickable executable file that I can share. I have to have my users download a big package, the other libraries, and then my app. "
      Actually Install Anywhere will let you bunder the JVM and your libs into a nice neat if large installer. You do need to have Java 1.1 installed but it will install higher JVMs for you.

  • Does Java have a linker? (Score:4, Informative)

    by EddWo ( 180780 ) <`moc.poptoh' `ta' `owdde'> on Saturday January 31, 2004 @06:34PM (#8146427)
    They don't have a linker because .Net is a virtual machine Jit compiler as well as massive class library.
    It will just become part of the Windows platform, its already included with Tablet PC, Media Center, Server 2003, Windows Mobile 2003 and it will be a major part of Longhorn.
    No one asks for a linker to statically link to user32 or GDI.
    • The point is that you can't deliver an app
      in a reasonble (i.e. minimized) download,
      to run on most of the Windows systems out
      there: Windows 95, 95 OSR2.5, 98, 98SE, ME,
      NT 4.0 sp6a, and 2000 Pro SP4. .NET is only useful for enterprises in which
      all the systems are "upgraded" (more like
      "migrated") to XP. That's a rare environment.
      It probably only happens in small businesses
      or colleges.
      • This is very true. .NET wasn't even available until recently. In other words..

        If your target audience is using Win98, and they don't want to download the .NET framework, then .NET is not right for you. Can't really be mad at Microsoft for requiring a 24+MB framework download that was not even available until the WinXP days.

        If your software company is distrubuting CD's, you can always put the framework on CD and install it with the app. It is a redistributable component per the EULA.
    • Yes, Java has several linkers.

      For example there is jc.exe, and GNU ld.

      > No one asks for a linker to statically link to user32 or GDI.

      That's because these are stable ABIs. .NET is
      not a stable ABI.
      • Actually, .NET does have a stable ABI with each release of the framework. 1.0 and 1.1 can run side-by-side, so they the 1.0 DLLs become essentially static. It's Java that doesn't have a stable ABI. Have you tried running older 1.0 or 1.1 .java files where they depended on interfaces that are broken in 1.2, 1.3 and 1.4? One of the reasons I don't program in Java anymore. It's not dependable across all versions and try running all of the various JVM versions on the same machine, just to maintain ABI. Ugh.
  • So Microsoft, wake up, get us some nice 1950s-era linker technology, and let me make a single EXE that runs on any computer with Win 98 or later and no other external dependencies. Otherwise .NET is fatally flawed for consumer, downloaded software.
    Could it be that Microsoft is using this as a way to force people into updating/upgrading their OS? Something like "Oh, I'm sorry, to run newer .NET applications you will have to upgrade to Service Pack X", and potentially as a way to force upgrades, "Oh, you h

    • How did this post get moderated up? (Score:5, Informative)

      by Inoshiro ( 71693 ) on Saturday January 31, 2004 @07:19PM (#8146667) Homepage
      All you had was wild speculation ending with, "I've never used .NET,"

      Let's pause a second and see how programs work on a modern operating system.

      There are 2 kinds of programs, typically, in an environment such as your PC: statically linked programs, and dynamically linked programs. Statically linked programs have the library calls included in the binary, wherease dynamically linked programs rely on library implementations stored in a system directory (like \windows\system or /usr/lib). The run-time linker resolves all the dependancies and loads the related libraries for every dynamic application you start (run the ldd command on a binary you have to see the libraries).

      But a .NET program (or a Java program, or a batch file, or a shell script, etc, etc) isn't a binary. It's PCode. It requires an interpreter to parse its Pcode. To make the .NET program stand-alone, ala a statically linked binary, you'd need to include the interpreter, a set of all used class libraries, and any other parts of the environment that are required. A typical 1-3mb application would have to be distributed as a 30mb+ file.

      When you want to run a Python program, you install a Pynthon interpreter. When you want to run a Java program, you have to install the Java runtime environment. When you want to run .NET programs, you need a .NET environment. It's not some crazy lock-in scheme, miyako, it's merely a fact of how virtual machines and Pcode work.

      Before you sit down to learn about .NET, I think you should take off your aluminium beany and learn about how computers work.
      • the msil is made to be easily compiled into maschine code, there is no interpreter as its not interpreted
        • Actually, althought IL is close to machine code, it's still not machine code. The CLR still has to load the IL, compile to real native code (machine code) and then run it. So, .NET IL is still interpreted and re-compiled before running, hence it's kind of slow the first time a particular code path is run. But each subsequent call actually calls the native code version, not the IL.
      • When you want to run a Python program, you install a Pynthon interpreter. When you want to run a Java program, you have to install the Java runtime environment. When you want to run .NET programs, you need a .NET environment.
        I noted that I had not used .NET to point out that some of my notions about it could be quite incorrect, but if you would read my post I postulated that microsoft was merely trying to do the same thing as is done with java etc. I would also assume that it was basterdized because, wel
      • A .NET program does not _require_ an interpreter. To make a .NET program stand-alone, you could either include the interpreter and all parts of the class libraries, etc., or you could 'simply' compile the pcode into machine code, link it, and ship that.

        The advantage would be smaller executables and, with the exception of potential run-time dynamic recompilation benefits from the interpreted version, faster execution. The disadvantage would be tying the resulting application to a specific CPU.

        • To make a .NET program stand-alone, you could either include the interpreter and all parts of the class libraries

          The class libraries are copyrighted. Would Microsoft give you a license to redistribute the class libraries? And would newer class libraries work on older Microsoft Windows operating systems?

          • This is a good point. I had been assuming that Microsoft would be writing the tool to compile and link the .NET source code into a stand-alone application. Obviously, any other company doing so would need Microsoft's permission.

            I don't see much problem (maybe I'm missing the point) using newer class libraries as part of a stand-alone, statically linked application on an older Microsoft Windows operating system, however.

            • 10 LET M$ = "Microsoft"

              I don't see much problem (maybe I'm missing the point) using newer class libraries as part of a stand-alone, statically linked application on an older Microsoft Windows operating system

              M$ Internet Explorer 6 doesn't run on Windows 95, and from the information M$ has published, IE 7 probably won't run on Windows 98, Windows ME, or Windows 2000. Likewise, M$ would likely make newer class libraries deliberately incompatible with older Windows operating systems in order to force us

  • You ask why? (Score:3, Informative)

    by dtfinch ( 661405 ) * on Saturday January 31, 2004 @06:45PM (#8146490) Journal
    Java doesn't have a compile-time linker either. VM based languages tend to only link at runtime.

    You improve one library, retaining interface compatibility, and every program that depends on it benefits without having to recompile. Executable code doesn't get duplicated in memory each time a new process sharing the same library starts. Libraries can benefit from globally shared objects without running the risk that a program compiled with an older version will mess stuff up. Etc.

    But you're right about this being imperfect. Upgrading my .NET runtime caused my Visual Studio .NET to become instable. I'll probably have to get the newest Visual Studio before I can get much use out of it again. It makes everything incredibly slow to load as well.

    Visual Studio .NET does infact include a linker, for the C++ compiler.

  • A linker is largely redundant (Score:3, Interesting)

    by ezy ( 60500 ) on Saturday January 31, 2004 @07:12PM (#8146629) Journal
    The only three potential advantages to a real linker are:
    a) You dont have to include code you dont use
    b) You can ship "all-in-one" executables that work in any environment (excluding the basic OS interfaces)
    c) global optimization

    If you have an environment that:
    a) Shares library usage between processes, and only pages in parts of the library that are being used.
    b) Handles versioning of library interfaces in a reasonably sane way.
    c) Uses meta-code which can be globally optimized. (.net may not be doing this yet)

    You don't really need a linker. Joel's main complaint appears to be about cross version compatibility (b) and all the cruft you need to install to get .net executables working (uh... .Net itself :-)) (a). I understand this in the short term, but over the long term I think it's going to be less of an issue.

    • Joel's main complaint appears to be about cross version compatibility (b) and all the cruft you need to install to get .net executables working (uh... .Net itself :-)) (a). I understand this in the short term, but over the long term I think it's going to be less of an issue.

      I think Joel's point, which half the flamers on this thread don't seem to get, was that if you're writing software today, and you're trying to get customers to download it tomorrow, writing for .Net is probably not a smart move.

      I r

    • Handles versioning of library interfaces in a reasonably sane way.

      Microsoft might intentionally make newer libraries incompatible with older operating systems: "In order to run an app that uses System.Foo.Bar, you must pay us $200 per computer to upgrade your operating system to Microsoft Windows Longhorn DRM Edition." Would you consider such a requirement a "reasonably sane way" to "[h]andle[] versioning of library interfaces"?

  • Give me a break (Score:2, Interesting)

    by dedazo ( 737510 )
    Joel's flagship product is (or used to be) written in Visual Basic. When he talks about "my users download a 9MB installer that has no additional dependencies" he's including the VB runtime along with everything else. That's 1.2MB, not including any additional ActiveX stuff he might use.

    Joel doesn't want a "linker", he wants C/C++ or Delphi or some other language that can create self-contained executables. So the .NET runtime is 25MB. Those are the breaks. His employee wrote this little app in 60 seconds,

  • Joel is a schmuck (Score:2, Insightful)

    by Goyuix ( 698012 )
    Having never read him before, I can't be 100% sure of the above title, but I can say that I won't be visiting his ruminitions on society anytime soon. I think he is a loud-mouth moron.

    I can't see a good reason why he would want a linker to link the .net environment and runtime into a single executable. That is just plain nuts. Yeah, I would rather have my users download a 30MB file instead of a 20MB runtime and a couple hundred K app... and his part on ranting of all the updates he needed to do - well, ju

    • Re:Joel is a schmuck (Score:4, Insightful)

      by Jerf ( 17166 ) on Saturday January 31, 2004 @08:21PM (#8146947) Journal
      I can't see a good reason why he would want a linker to link the .net environment and runtime into a single executable. That is just plain nuts. Yeah, I would rather have my users download a 30MB file instead of a 20MB runtime and a couple hundred K app...

      Actually, he had two good reasons, one of which you winged and one that zoomed right past you, likely because you've never had to support software that you wrote and may have multiple versions in the field.

      First, he objects that users may not download the larger file (and I'd add that some users will balk at installing what is effectively an OS upgrade just to try some software out, especially corporate users), and that as a result those users won't give him money. Unlike free software, a lost user is cash out of pocket. This is not trivial when software is your living.

      This isn't quite what you said because you missed the "money" aspect of the objection, which is critical.

      Of course it's easy to mock Joel, because it's his living, not yours.

      Secondly, he objects that without static linking, he's at the whimsy of both the users and Microsoft as to which .Net runtime his software actually gets dynamically linked to, and observes that there is a "solution" to this virtually nobody can use (so it's not really a "solution"). Again, if his software doesn't run, it's money out of pocket. And again, if you've never had to support software you probably wouldn't understand why it's nice to bundle everything up, as much as possible, into one self-contained bundle.

      I won't go so far as to qualify you as an absolute moron, but you are committing one of the key Moron Sins, which is "Assuming everybody in the world has needs identical to yours and projecting from there." So you're at least partially there with your Rant-From-Inexperience.
      • The point is that every environment has its requirements and Joel isn't forced to use .NET. I suspect that users that are still using Win9x at this late date are unlikely to spend a lot of money on new software. He'd be better off focusing his efforts on users that have demonstrated their interest in buying things like Windows 2000 and Windows XP users.
        • He'd be better off focusing his efforts on users that have demonstrated their interest in buying things like Windows 2000 and Windows XP users.

          Neither Windows 2000 or Windows XP come with the .NET runtime installed, which means that for anyone to try out your software they've gotta also install all of .NET.

          Sure, Joel isn't forced to use .NET, but he'd like to use it but is prevented from doing so because it's not feasible. He makes a good point that this will slow the adoption of .NET.
      • he's at the whimsy of both the users and Microsoft as to which .Net runtime his software actually gets dynamically linked to

        Well, that only means that .NET is no worse than Java. I don't think it's a big deal. And .NET is smarter about library versioning than JVMs are, which can only do it by manual monkeying with environment variables.
        • .NET is smarter about library versioning... I worked for a company developing a 3rd party add-on to one of Microsoft's flagship .NET projects (Microsoft CRM). Microsoft CRM was written for the 1.0 Framework. After a few months, the 1.1 Framework came out. After installed the new framework on our server, CRM completely quit working. We contacted CRM Support on this issue, and they commanded us to immediately uninstall the 1.1 framework. This was frustrating because we were in the process of developing
    • Have you ever statically linked against a large library? Are you aware that most linkers will throw out the parts of the library that you don't use? If you have a small 200K application, it is pretty unlikely that you'd be using the whole .NET library. More likely, you'd be shipping a compressed install package that is a few megs in size (say, 2 - 8 megs), not 30 megs. Now, you are at the size that a dial-up user would consider. Many people in the U.S. and Canada, and most people in Europe, are still o

  • wow, what planet is that guy from? (Score:5, Interesting)

    by ajagci ( 737734 ) on Saturday January 31, 2004 @07:20PM (#8146671)
    For some reason, Microsoft's brilliant and cutting-edge .NET

    Actually, .NET is neither "brilliant" nor "cutting-edge"--it's a modest evolution from Java, which is itself 1970's technology.

    The tool in question? A linker. Here's what a linker does. It combines the compiled version of your program with the compiled versions of all the library functions that your program uses. [...] Instead, .NET has this idea of a "runtime" ... a big 22 MB steaming heap of code that is linked dynamically and which everybody has to have on their computers before they can use .NET applications.

    Well, that's roughly like saying that automobiles leave out the horses and the whip. The whole point of .NET and Java is to run inside a runtime, a runtime that provides garbage collection, dynamic typing, and just-in-time compilation.

    Runtimes are a problem, much like DLLs, because you can get into trouble when application version 1 was designed to work with runtime version 1, and then runtime version 2 comes out, and suddenly application version 1 doesn't work right for some unpredictable reason.

    Well, duh. So, I guess operating systems are a problem, too.

    We solve that sort of thing by having standards and sticking to them. Oh, I forget, besides being rather confused about software in general, Spolsky also actually seems to like Microsoft Windows, so the notion of "standards" and "compatibility" must be rather foreign to him. .NET and Java do have serious design problems. Foremost, safe runtimes like that should run all applications on a machine in a single address space. Then, you can get rid of a lot of useless machinery for inter-process communication, and the overhead gets amortized over dozens of programs. Again, old stuff. But Spolsky's criticism is just missing the point completely.
    • Foremost, safe runtimes like that should run all applications on a machine in a single address space.

      Even "safe runtimes" has bugs that might be exploitable.

      • Even "safe runtimes" has bugs that might be exploitable.

        I said "safe runtime", not "secure runtime". It is unnecessary to protect against exploitable bugs between different applications because you don't expect your own applications to try and exploit bugs in the runtime environment to wreak havoc. For example, Gnumeric can already wreck AbiWord files if it wants to, even though they are running in different address spaces; they are running as the same user and can already get at each other's files and

    • Actually, .NET is neither "brilliant" nor "cutting-edge"--it's a modest evolution from Java, which is itself 1970's technology.

      This is analogous to saying about the first teleporter, "Teleporters are neither 'brilliant' or 'cutting-edge' -- it's a modest evolution from telecommunications, which is itself 19th century technology."

      If it's so prosaic, why hasn't it been done (properly) before .NET? Simply because the concept has occured before does not mean that the implementation is uninteresting or uni

    • Actually, .NET is neither "brilliant" nor "cutting-edge"--it's a modest evolution from Java, which is itself 1970's technology

      Some rather respected people in the field of object-oriented programming disagree [eiffel.com] with you.

  • [whine] [whine] [whine]

    Wtf is that rant about? As far as I can tell, the .NET has support for versioning far above any current platform, as it was designed in from the beginning. No, I do not know from practice, but I HAVE read the whitepapers, reviews and interviews. It specifically has provisions for concurrent versions of libraries (even in the same program), and has various compilation and runtime options. This directly obviates the need for static linking in the first place. Java doesn't have a l
    • ROFL! I love your post. Someone mod the humor up on this one! :D
    • News flash - new technology requires new, usually larger, downloads. BFD.

      News flash: users on dial-up (that's most of the world, BTW) don't like big downloads, and will mostly stick to older technology in preference to spending hours downloading something new and unproven. Big downloads loses you large chunks of user base. If you're doing it commercially, that means large chunks of cash, which is a BFD.

  • I'd also like to make a few remarks...

    Tell whoever is mucking around with manifests to just stop. I let Visual Studio compile my projects with near-default settings, and they load the proper runtime fine. I, too, fear manifests.

    As for your bad experience downloding 80MB repeatedly from Windows Update, you could have used a centralized Update Server... being a software company, it'd probably be wise to look into.

    As for the premise of your complaint, it does have merit. It would be ideal to be able t
  • I think it's only to lock you into the .Net Framework. There is a runtime necessary so that you have to follow their rules before running apps that use their 'neat' little apis. Microsoft claims that they can then 'increase security to all .NET apps' by only having to patch your runtime files, instead of all your apps. While that may be true on a very very limited scale (say patching an exploitable hole in the runtime api itself), it won't be helpful if the user (of the api, not the end user of the app)
  • He doesn't want a linker, he wants something to eliminate the need for a VM, some kind of CIL compiler.
  • Joel misses an important fact in his article... that the same scheme for versioning in .NET is used for the framework itself. So that when the next version of the framework is installed, your application will use the same old version if needed. In theory, no fuss, no muss.
  • This guy need to understand that .net complied applications need the .net framework to run because of the nature of the language. You can run a java program without its runtime installed , its the same concept. It will not complile into a single executable which can run on its own like c++ for examample, whcih is complied into native code (binary). .net is extremely similar to java (coincidence, i think not), it is just not ported to linux/mac like java is...yet? The java/.net runtime has its advantages,

  • I got a cool Logitech gizmo for Christmas that I still haven't been able to use, because it requires the .NET runtime which simply won't install on my PC. I just get a generic "Set up failed" message. Microsoft Customer Support doesn't reply. Logitech Support--after six requests for help--finally offered a few things to try, none of which worked.

    Relying on Microsoft to install a new technology on older machines puts Logitech at a real disadvantage. They should have built a traditional app until .NET i

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close