Distributing Your VB.NET App CSE3030: GUI Technology Lecture 10 Dan Eaves

Parts of Your “Solution” One or more “projects” in one or more.NET languages. Various optional native components. –(The parts of the development environment toolkit actually used) Various add-ins, usually with their own.DLLs Database(s) Help system(s) Images (pictures, icons), some in the forms’ resources files --.resx

Remember.DLL Hell.DLL Hell was based on the idea of: –One master, up-to-date copy of each.DLL. –Developers guaranteed upwards compatibility. –Control enforced via the Registry, with.DLL use registered on installation and counter controlled uninstallation. –Sounds sensible, but was a disaster. The approach was called COM (for Component Object Model) with variations: DCOM (D = Dynamic), DCOM2, COM2.NET is a explicit response to the problems with the COM model, among other things.

Managed versus Unmanaged Code

Source code Managed code Assembly IL code VB C# C++ Unmanaged component Common Language Runtime JIT compiler Operating system services Native code CompilerCompilerCompilerCompilerCompilerCompiler Unmanaged = “Bad”

.NET Deals with.DLL Hell by Accepting duplication as necessary –Each app has its own unique collection of.dlls and other objects. All are typically installed within the app’s directory structure. All are registered in the Registry, but as quite independent objects. –There may be many, many copies of the same.dlls on a hard disk. This is one example (XML’s hierarchical data structures are another) where a counter-intuitive, previously illegal solution, is taken to solve a set of unexpected real world problems.

What is Windows? We have to distinguish between: –Windows as computer (operating) system, versus –Windows as Microsoft Product Is Internet Explorer part of Windows? –Logically, maybe no, but –Microsoft has argued that both logically and physically it is This was one of the major issues in the Microsoft anti-trust case. The judge ruled that it wasn’t, and that it should be pulled out of Windows –But Microsoft had been trying to integrate the two for some time

(Why Are We Interested in This?) Your app needs to be able to run on many different machines with many different editions of Windows: –Traditional Windows: 98, 98 2 nd edition, ME. –“New Technology” Windows: NT, 2000, XP Whatever the version, it may not have been upgraded with service packs. –May have older releases of tools like: IE, Media Player, Outlook –May not have tool updates like the.NET Framework 1.1 And, with the exception of 2000 (upgraded) and XP will not believe in.NET!

Traditionally… Building distribution versions of software has been a real hastle Developers have used non-Microsoft products –InstallShield (market leader) –Wise (2 nd place, but better programming facilities?) –(see for details of both) Testing required DriveCopy with many different operating system configurations loaded, tested and deleted To say nothing of different hardware configurations…

Why Hardware? So the installation and performance can be checked against the minimum hardware configuration! You have to determine where: –The system won’t install –The system will install but not run –The system will install and run, but be too slow You can’t guess here, so you have to experiment. –(Otherwise, people can sue you!)

Missing Systems Level Software You can try to include everything your system needs You can configure the install so it tries to download from Microsoft any missing components You can use InstallShield or Wise, which give you programmatic ability to check for and install missing components from the app’s CD. Traditionally, the last has always been industry practice!