[RESOLVED] VB 2010 Express: Run .exe file on computer without .NET framework

I am having a few dramas with running my completed project on another computer. I created my project using Visual Studio 2010 (Microsoft Visual Basic 2010 Express).

The error messages I get say that the program is unable to access the .NET framework. This is because the .NET framework is not loaded onto the other computer and loading it is not an option.

I’ve done some searching on the internet and I found instructions for going from a dynamic library to a static library and building, rather than publishing the finished product for C++ 2010. So, I assume that I need to do something similar but I haven’t been able to apply this to VB 2010 Express.

The finished product needs to be self-contained, so that the .exe file has all the libraries and compilation instructions it needs.

So, is someone able to tell me how to link up the files I need and re-package my project so that it works on any computer that runs Windows.

Thank you.

You install the framework...

Seriously.

Or re-write it in something that doesn't require the framework. VB6.0 (most computers have the runtime libraries needed), C++, Java (although, this arguably also requires a framework, just a different one, and again this is something most computers have these days), Delphi all come to mind.

Trying to run a .NET app w/o the framework is like trying to drive a car on the highway w/o an engine... just not gonna happen.

-tg

UNGG! Largely due to my ignorance, (combined with issues of the network on which the program needs to run) I might have to fall back on VBA & putting the project in a Word or an excel file. As this is not a commercial project, it doesn't matter if it looks a little klunky - I'm not actually paid to program!

It may not be a complete loss... are you *SURE* there is NO framework installed? FW2.0 should be largely everywhere by now... you can target FW2.0, recompile the app and see if it will then install/run.

-tg

Dear tg

I'll try that. (I'll search for the FW2 before attempting to recompile!) There are apps that live in the various drives, so someone must have found a way of getting them to work. [If you're wondering, the app is intended for use at work, where the IT services people only get upgrades when suppliers refuse to support the existing software any longer, there are security issues and the security people work hand-in-glove with the fun police. My app is actually work-related.]

Remotesoft has software they claim can compile a .Net application as a stand alone exe by using static linking. Only problem, its not free.

yeah... that is an option... but they work by compiling it down into native code... and while there's nothing really wrong with that, it can have an impact since it only "compile[s ...] into x86 machine code" which means there's some features you may lose out on.


wow... that's pretty pricey... :eek:

-tg

I'm not certain you'd lose out on anything. Here is a review written about RemoteSoft's products including the linker. This guy had no complaints about it. He seemed blown away by it in fact. Also, I believe compiling to native code is an option. The linker is described to work by creating a mini-framework and linking to that.

I'd really like to give this product a try someday.

by being x86-based, you're inherently missing out on 64-bit operations... seems minor in the grand scheme of things, but with 64-bit becoming more and more proliferated, it could be a problem - admittedly I'm thinking specifically of things like PLINQ that could be left out in cases like this - ... now that's not to say that the people at Remotesoft won't update the linker... which does bring up an interesting opportunity .... creating a linker that can product x86, 64-bit native and ARM run-times.... that might be too good to pass up....

-tg

Oh, I see what you mean. I think this software has been around for about 10 years now. I'm not certain they update it any more so that may be a problem indeed.

EDIT:-

The changelog on their site indicates it was last updated in 2007. So its about 5 years behind current trends.

Even still.... I'll have to remember this tread so I can point Esposito to it the next time he rails against the whole .NET framework issue...

-tg

Framework 2.0 was pushed to XP as an essential OS update. Framework 3.5 was pushed to XP as an optional update, and was included in Windows 7 (and possibly Vista). So it is perhaps a bit more likely that at least one of those is available.

Even so, I don't know why MS in all their wisdom didn't include an option to compile to native code and statically link only the necessary components into the EXE or external DLLs. This would have been so great as many people(including me ;)) find it a hassle to go an hunt down and download other components over the internet just to get an app working.

Give developers a choice. I would have jumped to VB.Net from VB6 much much sooner than I did if MS included such a feature. Having to install the runtime was my biggest barrier to switching over second only to the fact that .Net MSIL code can be decompiled with very high fidelity to the original source code very easily.

Wow, guys! Thank you for all the info & discussion. As I'm sure you've deduced, I am very much a beginner in the world of .NET. I would agree with Niya's last comment.

You have had to have a runtime for pretty nearly the entire history of VB. The reason nobody thought anything of it with VB5 and VB6 was that the runtime was already installed as part of the OS, so it was just there. Had it not been there, you wouldn't have been able to run one of those programs anymore than you can run a .NET program without the framework. I remember packaging the VB5 runtime in with distribution disks. VB had a Package and Deployment Wizard that would package the runtime, along with the program and any resources, into a compressed set of files spread across multiple disks (3.5" floppies, at the time). Because of that runtime, you could never make a program so small that it only required one disk.

You kids these days....you're all spoiled. Now get off my lawn....and help me find my teeth.

In any case, the goal behind .NET was to cut into Java. The intention was to write once, end up with MSIL, and have virtual machines in different operating systems that could take that MSIL and run it for the particular machine. Write Once Run Anywhere was the goal. It may not have quite been entirely successful.

I'd like to see MS release a compiler that produced native exe's too, but mostly just out of curiosity. Specifically, I'd be curious about what Esposito would have to say about it.

Well its not so much me that's spoiled but other people that may want to use software I write. I remember when I first released an app over the internet, the number one issue people was griping about was the need to have to install my program. It was a piece of editing software for the ZDOOM map making. Very few people were willing install this software and they only came around when it seemed quite useful and worth having to install. I envied all the C++ guys who wrote other editors that could simply be downloaded and executed without the need to package a runtime. My own was unique and did things the others didn't which is why I eventually got away with it. I even had a few people requesting updates to it and such.

I remember thinking that if people gave so much trouble just because they had to install the application, it would be madness to ask them to download a 300 something MB runtime and install it just to run my application. The .Net framework wasn't as ubiquitous as it is today so this presented a huge barrier. It soured me and made embracing .Net a problem for me for many years. Static linking would have made a big difference for me had they thought of that.

Ah, those where the days. I wrote programs for about 10 years in a language called Clipper (which as an enhanced version of DBaseIII that created an executable). Just copy the exe and database files and you were off and running. But, back then PCs only had a 1meg of ram and memory was precious so it seemed like an art to make the program do what you want and still keep the file sizes small enough. Now, memory is a very small worry.

Then came the GUI. Now memory isn't a problem but installing the application is now an art. I've been doing this for 25years and it seems like every time I stop to catch my breath, I fall behind.

Ya, this business of computers evolves too quickly :D

As the red queen said: Sometimes you have to run as fast as you can just to stay in one place.

Quote:

---

Originally Posted by Niya

I envied all the C++ guys who wrote other editors that could simply be downloaded and executed without the need to package a runtime.

---

Still MSVC++ also has a runtime (msvcrt.dll) . It ships with Windows so nobody notices the fact.

As for the original question - is there a point in using a framework (any framework) and then link a substantial part of it into an executable? After all, if people just read the documentation they'd known that the framework must be installed on a target computer.

Problem is people don't want to read anything, much less hunt the internet for runtime downloads. If your app is much needed then they'd do just about anything to get it working. This can cause competing apps to win out. Many people including myself, when downloading or installing apps and we had a choice of different apps that do the same thing, will have always choosen the one with the least hassle to get up and running. Only instance where this isn't true is when the heavy one is far superior to the thinner ones.

Back in VB5 or VB6 times I simply re-distributed MSVBVMx0.dll with the package.

For the record, I checked on the .NET framework and discovered it was ... FW1!

I didn't think that was even possible. Are they not doing Windows Updates?

That's what I thought. They do selective Windows updates. I might try my search again, in case I searched wrongly. Along with the selective Windows updates, they also do selective deletions, e.g. text-to-speech has vanished from the accessories > accessibility and I don't think they've replaced it with the narrator.