I have created a project within VB.net, which downloads an .exe from my DropBox. When I manually download, the .exe it runs perfectly, however when I download it through my VB project, it comes up with the error:
EDIT:
"Unsupported 16-bit Application:"
"The program or feature cannot start or run due to incompatibility
with 64-bit versions of Windows"
This is the code I use to automatically download the .exe:
My.Computer.Network.DownloadFile("[FILE LINK]", "[FILE DIRECTORY]")
The .exe downloaded through the VB.net project is only 155 bytes, whereas the actual .exe should be around 120 KB.
Why does the file become incompatible when downloaded through my VB.net project?
Related
I have created a VB.Net application that I plan to distribute using the .exe file in the Release folder. Upon sending this to a user, I was informed that it would not run on their system. The exe runs fine on my system no matter the location of the file so it's not a folder dependency. I don't have easy access to another computer, so is there an easy way to test my file as if visual basic were not installed on my system?
Edit: By "does not run" I mean nothing occurs when the exe is clicked
I have a VCL application built in C++Builder 10.0 Seattle. It uses Axis Media Control on the Form to display video, therefore it loads the AxisMediaControl.dll file when it runs.
In the past, I have had this deployed on a 32bit target machine, where the application lived in the C:\Program Files\AppName directory, and the AxisMediaControl.dll was installed to this same location. Everything worked as expected.
This application is a 32 bit application, so when deploying to a 64 bit target machine, it is installed in the C:\Program File (x86)\AppName directory. Once again, the AxisMediaControl.dll file is deployed in the application directory.
The app fails to launch with the error "The specified module could not be found". Using Process Monitor, I found the program is looking for the Axis DLL in the older Program Files directory instead of the x86 dir. What would cause the application to look for the DLL in that location?
Running the same binary on my dev machine, the application loads the DLL from my SysWOW64 directory. If the DLL is placed there on the target machine, it still fails to look in that location. It is ONLY looking in the older Program Files application path, which I cannot understand.
I'm hoping someone can shed some light.
I have a native DLL (x64) built with VC++ 2008 that I'm trying to use in an azure project. The code runs fine in a standalone executable, but when I try to run it in the Compute Emulator, I receive a DLL not found exception.
For several days I've been assuming the issue is with the VC++ redistributables not being present, but that shouldn't be an issue with dll's built using VS 2008.
Using ProcMon, I discovered something odd -- the DLL is not being found anywhere on the path. Further poking around showed that the DLL is not being copied to the approot folder, despite the fact that it is set to Build Action = none + Copy Always.
I manually copied the DLL to the Compute Emulator's path in the SDK and now it runs. But why does VS not copy the DLL along with my project files into the approot when I press F5?
How to serialize a class in MFC for win7 ?
My computer is win7 operation system, and install vs2008. if the code, which include serialize a class and create a backup file, program the code as a execution File and run it in my computer is OK, it can open the serialized file and load data. but if the other win7 computer which not install vs2008, the execution File can not open the serialized file and load data is not success, but run in xp system is success.
I want to make my program can run win7 and xp,how to do it? thanks very much for everyone.
If you are placing your file in "non-appdata" folder, perhaps you are having problems with UAC. You can check for a possible solution here
Are you trying to use the DEBUG version of your program?
When you create a MFC program under Visual Studio, it creates a project that is 32-bit and uses the DEBUG version of MFC and the Runtime library. When you get ready to distribute your program, make sure you build the RELEASE version which uses the non-DEBUG versions of MFC and the runtime library. In all likelihood, the VS2008 runtime libraries will already be on your target Windows 7 computer. If not, the user will have to download and install the Visual C++ 2008 runtime files from Microsoft.
So I created a cab file in Visual Studio and it all was fine and dandy. i am using HP thin client with WinCE 4.0
One thing though, there is a folder called Program Files on My Device and there is a folder called Program Files on Hard Disk.
Now, My Device memory resets itself each time the machine is rebooted.
Unfortunately, VS 2008 won't let me change the path for where the cab installs the program.
Any ideas on how to change the path?
I have figured it out: any time you wish to install an application in a different path, use Custom folder, not Programs or Program Files.
Looks like InstallDir can not be modified w/o hacks. I used Custom folder while in the Cab project and specified the path I wish to install this app; it worked.