Fog Creek Software
Discussion Board

.Net linker redux

A comment in Jason Zander's WebLog got me thinking about another solution to this problem.  What about a piece-meal runtime installation of .NET?  Joel says that he thinks he could link his application with the .NET framework and the total installer size would only be 5-6MB.  This is because he's not using the entire 22MB of framework in his application.

Wouldn't it be nice then if he could bundle a 5-6MB version of the .NET runtime with this application.  If the runtime is already installed then nothing special is done.  If the a partial runtime is installed (say by another application in this scheme) then the installer fills in the blanks.

.NET has the ability to force and application to a specific assembly version and to have multiple versions of the same assemby installed.  If you have an application that absolutely needs to tied to a version 1.0 assembly then you'd need that entire version of the framework installed even if you have 1.1.  In this scheme, you could just distribute the version 1.0 assembly with your application.

It's probably much too late in the game for anything like this to happen -- I imagine this capability would have to built into .NET from the ground up.


Almost Anonymous
Friday, February 20, 2004

And where would you draw the line?

I guarantee it's nowhere as easy as you think it easy, even if you think it's really really hard.

Brad Wilson (
Friday, February 20, 2004

Friday, February 20, 2004

I can imagine lots of cases where it would probably be possible to use the remotesoft linker.

It seems like the linker would make it difficult to use features like runtime class reflection and dynamic classloading in your own projects.

More to the point, it would make it impossible to use 3rd-party libraries which used those features. And it seems doubtful that the linker would be able to catch all of those tricky instances, so you'd be left to find them at runtime.

Very tricky business.

Benji Smith
Friday, February 20, 2004

Now you *do* have the .Net compact framework, designed for PocketPC:

But if you tried to go a la carte, then you're right back in dll hell. We all know for a fact there are software developers that would intentionally write against various versions of the packages ("Well, I prefer the implementation of GDI 1.7 to 2.3, but I think the 2.1 DataSet is a bit faster than the 1.6...")

The .Net runtime is, quite simply, a mixed blessing. It completely and absolutely solves the dependency problem - your user either has it or they don't; it also solves a lot of security and maintenance issues. Now it's a delivery problem.

Didn't Joel write an article about tradeoffs? [grin]


Friday, February 20, 2004

"But if you tried to go a la carte, then you're right back in dll hell. We all know for a fact there are software developers that would intentionally write against various versions of the packages ("Well, I prefer the implementation of GDI 1.7 to 2.3, but I think the 2.1 DataSet is a bit faster than the 1.6...")"

But can't you already do that with manifests in .NET?  Can't I link to a particular version/build of an assembly as it stands now? 

As such, the problem you describe already exists and my suggestion certainly doesn't make it any worse.

Almost Anonymous
Friday, February 20, 2004

Well, here's my little pet peeve.... IIRC the Framework is listed only as an "recommended" update on the Windows Page, which means that a typical user has to choose to download it and then wait while his modem grind away.

Distribution would be much easier if Microsoft instead distributed the Framework through the Windows XP automatic update feature.  Since the downloading happens in the background, using only a portion of the user's available bandwidth, this would be a particularly convenient mechanism for distributing the Framework to users with 56K modems. 

Of course, this wouldn't be a perfect solution -- it won't work for computers running earlier versions of Windows, or for computers with automatic updates disabled.  However, this simple step would definitely increase the CLR installed base, probably to "critical mass" status.

Robert Jacobson
Friday, February 20, 2004

I don't have a professional opinion on this matter. I honestly don't fully understand the ramifications of linking, and I've never developed in Anything.NET.  I do understand that a 20mb download is a lot for some people, and that there could be versioning issues between 1.0, 1.1, and the future .NET 2009 Ultra Longhorn XP version.

For the last two weeks though, I've been in unspeakable DLL Hell, and I would kill to have a common runtime environment.

Either that, or have all Win98 users upgrade tonight ;-)

Friday, February 20, 2004

Maybe the next Trojan/Worm should download and install the .NET runtime on every computer it infects.

Boy would Microsoft be in a PR pickle there.  Just thinking of it makes me grin.

Richard P
Friday, February 20, 2004

FoxPro beat dBase because FoxPro had a linker? 

That doesn't sound right to me, but maybe I don't understand things well enough.

Here's my understanding:

The big triad of desktop databases in late 1980's was dBase, FoxPro, and Clipper. 

dBase was always fully interpreted. 

FoxPro was interpreted, but could "compile" the source to "tokens".  This wasn't compiling to machine language level, just some sort of tokenization of the source so the interpreter could run faster. 

Clipper was always a true compiler.  Could compile the source and link into a native executable.  (Quicksilver was another native compiler that was sort of a weak sibling of the other three.)

FoxPro beat out both dBase and Clipper, but it wasn't because FoxPro was compiled.  It was because FoxPro was blazing fast and was priced right (and also because Clipper lacked any sort of end-user development environment).  The team of 5 people that were responsible for FoxPro also developed the 'Rushmore' technology that's still used to optimize queries in current FoxPro and Jet, I believe.

Herbert Sitz
Friday, February 20, 2004

Whoops, thought this thread was about little piece Joel just posted.  If it's not, then consider my post above to have been placed in that thread, wherever it is.  Sorry. . . .

Herbert Sitz
Friday, February 20, 2004

Nigel >> For the last two weeks though, I've been in unspeakable DLL Hell, and I would kill to have a common runtime environment.

Tell, tell :-)

Friday, February 20, 2004

"Distribution would be much easier if Microsoft instead distributed the Framework through the Windows XP automatic update feature."

As I understand it, the .NET Framework 1.1 is a non-optional part of Windows XP Service Pack 2.

Brad Wilson (
Friday, February 20, 2004


What do you base that on?

I was using Window XP for quite some time, dutifully doing Automatic Updates and it never installed the .net runtime.

The real Entrepreneur
Friday, February 20, 2004

XP SP2 isn't out yet. Of course it's not on Windows update!

Chris Tavares
Friday, February 20, 2004

The interesting thing to me is that .NET runtime distribution issues are essentially the same issues that Java has always had.  Thus, look at how Java has dealt with it. 

In the 1.1/1.2/MS Java days, you had no excuse but to distribute the runtime with your code because you had no hope at all of the user having the right thing installed.  On Windows, it is still likely that the user doesn't have the runtime, but you're seeing more and more apps that just link to the Sun website to have the user get the installation.

However, the only place it works really well is on the Mac where the Java system is already in place.

Thus, although it sucks, we're pretty much faced with causing users to do the installation of the runtime until such time as XP sp 2 becomes the standard.  Although, "Runtime version hell" is going to continue for the next several years until the runtime settles down enough - just like happened with Java.

Friday, February 20, 2004

Brad, I hope you're right, but one article suggests otherwise:

"The service pack will also deliver the 1.1 version of the .NET Framework as an optional download."

I'm not clear how the service pack could make it an "optional download," since it's already an optional download through Windows Update, but oh well.  This article is from December 2003, so maybe the situation has changed or will change before SP2 is actually released.

Robert Jacobson
Friday, February 20, 2004

Herbert, I think your recollection is generally spot-on.  At the time I worked for the other vendor (the 'easy to use' one, Alpha Software which made Alpha Four and Alpha Five - end-user databases).

Fox kicked butt because of rushmore -- bitmapped query optimization and their new cdx file format, which was also compressed.  it saved a lot of spaces over mdx's, which were dbase's new technology (multiple indexes in one file, but no compression).

I don't recall anything about fox's linker winning the day.  i do remember everyone freaking out about the ability to search millions of records in milliseconds with rushmore - on a 33 MHz PC (is that right?).

dir at badblue dot com
Friday, February 20, 2004

Herbert and Dir are pretty much spot on in regards to FoxPro.

BUT, *Visual* FoxPro has had a runtime since its inception and last I checked it weighed in at 19.3MB, and we have been writing VFP apps since it came out without any trouble in redistribution.

And for this reason we see no problem with the fact we are starting to develop in .Net. We have people downloading our current installer which weighs in at 80MB by the time we included the ChartFX, Crystal Reports and VC++ libraries.

In fact for our CD distribution the CD is 560MB because our app actually requires 2000SP3, XPSP1, IE6 etc. anyway.

My take on it is that the whole "dotnet is too big to download" issue is a storm in a teacup and when people wake up to themselves and realise it doesn't really differ from what they currently do it will blow over.

NB: It should also be noted that since Visual FoxPro came out its market share took a nosedive. Has that got anything to do with the runtime size?

Chris Ormerod
Saturday, February 21, 2004

If this doesn't install the .NET runtime:
then someone at MS needs to be slapped upside the head.

Chris Altmann
Saturday, February 21, 2004

"The interesting thing to me is that .NET runtime distribution issues are essentially the same issues that Java has always had."

Yep. That's why we never considered java.

I was (momentarily) concerned when a very very well funded international company created a competing product.  As it turns out it was Java based. And it sucked.

Had a customer call the other day after trying the competing java product. They asked me stuff like "How long does it take to install?  Will I need to change my screen resolution? ,e tc." I was baffled until they said "oh, the other program took forever to install, made them MANUALLY change screen resolution".

All these gee-whiz technologies are great... i theory.  I work in the real world.

The real Entrepreneur
Saturday, February 21, 2004

I'm not aware that anything about Java requires manually changing the screen resolution. You can write crap programs in any language, you know.

Chris Nahr
Saturday, February 21, 2004

I you'd better believe I do...

Sunday, February 22, 2004

I suspect if Joel's article came out in a few years time we wouldn't even be having this debate.

With broadband, the download for 20MB runtime is comparable to the install time from a CD-ROM. Either way, it just enough time to have a quick coffee, or take a nature break - the choice is yours, give or take a minute.

Ok, the phrase "a few years" may be optimistic for mass take-up of broadband. And the 20MB runtime will probably have doubled by then, but you get my general point (I hope!).

David Times
Sunday, February 22, 2004

Here's a question:  Do you think the tolerance for downloading a 20MB+ install varies based on whether your target customer is a company vs. a consumer?  I'm about a month away from "shipping" a C# app targeted at small companies running SQL Server or MSDE, and this issue is a pretty important one for me!

John Moody
Tuesday, February 24, 2004

Opinions differ wildly.
I personally do not think the extra 20Mb matters one bit (but be pollite and offer separate downloads for those that already have the framework installed). The only place where it might matter is the "impuls" trial market.
"Hey, what's this? I have got 5 minutes to kill so let's have a look."
From the sound of it your application would not fall under that category.

Sizewise the Framework =~ 4 mp3's.

Just me (Sir to you)
Wednesday, February 25, 2004

We are about a month from releasing our .NET application and our biggest concern is the impulse trial.  I want users to be using our product within 5 minutes of deciding to download it.  Administrator Rights, 20 megs,  + a REBOOT is just not an option. 

Additionally, ease of implementation is one of the key selling points of our enterprise application.  What kind of message does this send to our prospects?

Has anyone experiemented with
Is it worth the insane licensing BS? (connection to internet required, but you can pay $500 for a usb license thingamajig so it will work when your ISP goes down).

Monday, March 15, 2004

We've been using thinstall for the last half year.  Had one issue because we generate c# code at runtime and csc.exe to compile it into an assembly and load that.  But we found out Thinstall is able link csc.exe and supporting DLLs with our program without problems - I thought that was pretty cool.  The only downside I've seen is you can't directly debug your program after it's linked with Thinstall (but you can do JIT-debugging if there is a crash).

Jason Chung
Thursday, April 22, 2004

*  Recent Topics

*  Fog Creek Home