Slashdot Mirror

← Back to Stories (view on slashdot.org)

Why Doesn't .NET Include a Linker?

Posted by Cliff on 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?"

3 of 113 comments (clear)

  1. Joel is just another Troll by Gyler+St.+James · · Score: 0, Flamebait

    I guess Joel or his programmers couldn't figure out that you can open the project properties and actually select which run-time you're targeting. It's rather easy and doesn't require you to write your own manifest (although you could). The idea behind the manifest is when you have to dynamically link to other people's DLLs or apps and not the run-time. If the 3rd party happens to upgrade to another version, that's okay. That's why they came up with the idea (or rather re-invented) of side-by-side execution, which allows you to specify with version of the 3rd party DLL you want to use. Joel, get a clue, man! I've been doing .NET development for 2 years now and the first thing that I learned about was the versioning aspects that .NET brings. I will admit that there's nothing new or "brilliant" about .NET, other than it's a vast improvement over Java. But come one guy, do a little reading and research before moaning and grunting at Microsoft. I'll even admit I have no great love for MS either. I do love the comment from an above poster that points out the .NET linker available. If only he'd gone a little googling, he could have saved us all a few more minutes on our tickers by not writing such an asinine rant, er, article.

    --

  2. I know exactly why and it makes perfect sense. by shadowxtc · · Score: 0, Flamebait

    Whoever wrote that article failed to do step #1: RESEARCH.

    I code in .NET, and very little researh yields phrases like "The .NET runtime has side-by-side execution."

    What this means is very simple: You have a .NET-based graphics program, which I'll call "Imagerizer 1.0", which uses the .NET runtime version 1.0 let's say. You also have a .NET-based database program, "Storzit 2.5", which uses the .NET runtime version 1.1.

    You have BOTH of those runtimes installed, if you want to run both of those programs.

    Imagerizer 1.0 will ALWAYS use runtime version 1.0, however it will use the newest version of 1.0 (for example 1.0.3.3 vs. 1.0.2.2). Storzit 2.5 will always use the latest version 1.1 runtime.

    Simple. No more DLL hell - for a tradeoff of extra clutter. But the runtime will manage it all for you, and you can usually mess around with it more. It's actually much more control given to the end user.

  3. Might I add one last thing... by shadowxtc · · Score: 0, Flamebait

    .NET also makes it rather disgustingly easy to have applications which either dynamically generate and execute code, or can take actual .NET code in whichever language and execute it on-the-fly. Though it's not guaranteed in any case that it'll actually compile and run, it's much more likely when there's a well-known set of libraries out there on "every" machine.