I have been programming in VB for about 6 years.  One of my constant problems have been compatability with different environments and different versions of DLLs.  It was my understanding that VB.NET had resolved the DLL hell and that the program once compiled would be a container that would hold all the code necessary for the applicationt to run.  So I excidely opened and installed my new VB.NET on my laptop that is running XP-Professional.  Over 2.5gb of files install. OK with that but I now ordered a new 30gb hard drive so I can install the help files.

Now I jumped in and created a project where I have one form, one button, and one line of code that produces a message dialog box that says Hello.  Then I Built a Windows EXE and moved it to a floppy.  Now I placed the floppy in a Windows 98se machine and executed the program.  "A Required DLL 'COREE.DLL' Not Found" message appears.  Whats up with this.  Am I doing something wrong.  How do people write public domain programs and deal with the DLL hell.  Why can I not pull the code from a DLL and include it inside the EXE so that it will run on its own?  I can not develope any applications in my organization that requires a DLL to be placed on the workstation due to compatability issues with our legacy programs.  I guess the rummers that .NET was going to free us from the DLL hell was wrong or I am wrong.  Please help.  

Signed,
Stuck in the Microsoft 7th level of Hell.

The VS.NET (VC, VB, and the like) uses the .NET framework. This framework is freely downloadable from microsoft last I knew.

It needs to be installed on the machines for the program to work (similar to VB6 runtime files needing to be installed). Microsoft's product update site's starting to include the framework as a "recommended" update for their products also I believe.

Once it's installed, all programs created within the VS.NET should work on the computer.

Free or not, this is not an improvement.  I have checked into this and the download and addtional DLLs is about 20mb.  Quite a download if you can convence your clients that this will not impact any legacy applications.  In my case, we have about 25,000 employees and the powers to be will not allow .NET environment to be pushed to the desktop without legacy testing.  This could take years.  

Now for a question.  Any way that the .NET environment files be placed in a folder on the network and set up in your application to call them there when needed?  If so, then there may still be hope for .NET in the Government.  We need a migration path and not a slam dunk.

Thanks.

Doubtful... In order for a program to run, the DLLs need to reside on the PC. I had a similar problem with VB6. Management didn't want to install the VB6 runtime files on PCs because they didn't want to mess them up, took forever to convience them otherwise.

You could try put the program on a .NET ready PC/Server, and placed a shortcut to the program on the individual PCs, it'd still need the DLLs to run (although it may work, but highly unlikely - didn't for VB6).

Although you may be able to manually (or create a VB6/VC6 program) to create the .NET DLL references across the network (it'd have to be done on all PCs). This does work for some types of DLLs -although the .NET is more of a OS upgrade than a program upgrade.

Of course, if the network has a glitch, or the user cann't access the server, they may have all types of error messages popping up when they log on.

Strange situation you have, they have .NET but don't want to use the .NET files that are required for programs to run without testing.

[I installed the .NET files on a Win98 machine a while back, didn't even notice anything different, other than the hard drive space that was taken up, and a new add/remove option.]

Maybe someone else has a solution.

Thanks for the response and thread.  Let me explain further.  I do not think that I am alone in this problem.  My organization is in every state in the US.  In order for me to write and application for our office to use it can not install any files in the Windows or System folder without testing to assure that all our current applications are compatable.  The VA has not imbreased .NET and are still using VB5.  However, a number of our programmers do not wish to be left in the dark ages and want to push forward.  There lies the paradox.  

Someone told me that I should be able to put the DLLs in the same folder as the EXE and the EXE will check there first before looking in the WIndows or SYstem folder.  But that still leaves the registry issue.  Also, the new VB.NET does not show what DLLs it is going to use because Microsoft assumes that everyone would just jump and upgrade to .NET.  

If Bill Gates was writing MS-DOS today he would require that every floppy be manufactured with an incoded Microsoft signature on the disk before MS-DOS would read it.

The reason you need to have the .NET framework on each workstation is because it compiles when the program runs, not when the programmer compiles it.

If you don't want to install the .NET framework on each computer, then you might want to think about creating server based programs that can be run from a web browser. Then all you would need is the .NET framework installed on the server and any computer could run the program.