Is VB.Net Practical for Shareware Apps?

[Captain Dave]

After browsing this board I was dismayed to learn that applications written in vb.net require an enormous runtime file of over 20 meg. An additional file is required for applications which access data. :eek:

 

Nobody using dial-up is going to download these files so they can try out your shareware app. It shouldn't be a problem for broadband users but I wonder what percentage of shareware users have broadband.

 

Does anybody have an opinion on the merits of writing new shareware applications in vb.net rather then vb6?

[Volte]

For the time being, I would say that VB.NET is not practical for shareware

apps; not many people have the framework yet. However, in the

future, Windows is going to come shipped with the framework, so

all you will need is the EXE and required files to run it.

 

Right now, though, you're right. Not many dial-up users will want to

download 20MB DLLs to run a shareware program.

[TechnoTone]

I never thought VB was good for shareware in the past anyway. Who want's to download at least 5MB's just to try a simple little program that may be less than 100KB???

 

However, with .NET you'll only have to download the .NET framework once, and then you can run any .NET program - which should be quite a small download and simple to install.

 

I think it's an improvement, even for dial-up users.

[Volte]

It's the same with VB6... XP even ships with the VB runtimes, so you

don't need to include them if you want to run on XP only.

[divil]

I think all currently supported Windows versions ship with the VB5 runtimes, and VB6 since Windows 98 SE (I think). Future Microsoft products will ship with the .NET framework as they shift their own development towards the new platform.

[Captain Dave]

I have to wonder how many versions of .net runtimes there will be. Are there going to be vs.net upgrades every couple of years - each requiring a new runtime?

 

I thought compiling to native code eliminated the need for runtimes.

[Nerseus]

If your question was "will a user have to re-download 20meg every year or so to get an updated runtime", the answer is unknown. I would guess there would be smaller service packs, hotfixes, etc. to cover the majority of "necessary" upgrades. When it comes to updating a system, there are generally two categories of users: those that upgrade everything and those that never upgrade. For those that never upgrade you only have to worry if you develop on the *newest* version that isn't compatible with an older version. For those that upgrade constantly, you only have to worry if the new framework breaks your code - a very unlikely scenario. I've never had an issue with the MS runtime causing problems because of an upgrade. The worst thing I've seen is a bunch of controls getting a white background instead of grey one because of an outdated DLL - still not the runtime. Now 3rd party DLLs on the other hand - well, don't get me started :)

 

You might think of it this way - if there were issues with programs breaking because the runtime wasn't backwards compatible, there wouldn't be many people developing with it. That's good enough for me, especially since I don't want to write a compiler (I'll let MS do their job on that one). :)

 

I'm not sure what you mean about native code...

.NET doesn't compile to native code normally - it compiles to an intermediate language that the runtime compiles "just in time" as the program is loaded. As a developer you have the option of compiling the code into native code for better startup performance using the tool ngen.exe but you run the risk of decreasing performance later. The "compiler" optimizes for the machine it's run on and can't be recompiled later. This means future compilers, which might optimize better, can't be used later on. Also, if you "compile" on a machine different than the end-user's machine, your app may be optimized incorrectly. This could be especially true a few years from now as 64bit processors come out - not to mention a new OS.

 

To help out with preventing "DLL Hell", MS has changed its strategy on deployment. You should check out the help file at:

Visual Studio .NET -> .NET Framework -> Deploying Applications

It contains a ton of information on what you need to worry about when deploying your app, including upgrades and how the framework finds the right DLL at runtime. They've put a lot of effort into helping us developers get the program running on every machine. It does still mean we have to know a *lot* about what's going on at runtime to figure out how to get our installations to work right *every* time.

 

For the record, what kind of shareware program are you writing or thinking about writing? :)

 

-Nerseus

[Robby]

If you're offering your app for download, you can have the exe seperate from the Framework. The user can determine if they need it or not.

[Banjo]

That depends on how savvy your users are. If you're aiming for the techy types like us then that's not a problem, but say you were writing an IM system (a common affliction amoungst novice programmers) you will often find that your users are too dumb to work out whether they need the framework or not.

[Volte]

You could somehow cause your program to explain to them that they

need the framework, and where to get it, instead of just having

that 'MSCORE.DLL not found' error or whatever it is.

[Robby]

Banjo, I agree with you on that, it's the same way that most novice folk can't figure out if they need Acrobat Reader or not.

But as Volte said, you could explain it to them either with your app or on the download page.

[Nerseus]

Or use the built in installer which could offer to download the framework direct from MS if it's not already installed... :)

 

-nerseus

[Banjo]

Yeah but that generally requires either an expensive installer program or detailed knowledge of MSI databases (not nice ;)).