I want compile some GUI into a Windows standalone application (*.exe). The main idea is run my applications in different computers WITHOUT the necessity of privileges to run it.
While doing these steps, I noticed that when I want to run vcredist_x86.exe on a different computer administrator privileges are required. I asked in the official forum and they confirmed that is not possible.
There was also other interesting alternative with an older version here:
How can I install the Matlab Component Runtime without Administrator rights when using MATLAB Compiler 4.6 (R2007a)
Despite the fact that now there is no supported way, until which Matlab version was it possible run standalone apps without privileges?
My version is 2010b but I can use the most recent version which support the possibility to run MCR without privileges. I have Matlab compiler but not Matlab code generator (to automatic translate into another language).
Matlab user executables require Microsoft DLLs to run. No Matlab version is going to be able to run user executables without the required Microsoft DLLs. One cannot install DLLs to Windows owned directories without admin privileges. This is a configuration issue not a Matlab runtime issue. Solution is to install the required DLLs to the local folder that has the user application in it. Ignore all the stuff in the docs about "network redributables" and "registering" DLLs.
I don't know if it is possible to run vcredist_x86.exe without privileges. It may be a matter of setting the install path to your local directory instead of "Program_Files...". Either way it doesn't matter as vcredist_x86.exe should not be necessary.
I don't know if what you trying to do is possible or if Matlab has blocked it somehow but I think you have gotten confused on how to get there and have compounded your problems by trying to install to non-user directories.
Related
Visual Studio code offers User and System Installer but I have not found any description about the differences between these two options.
Could someone please shed a light on this for me?
User setup for Windows
Announced last release, the user setup package for Windows is now available on stable. Installing the user setup does not require Administrator privileges as the location will be under your user Local AppData (LOCALAPPDATA) folder. User setup also provides a smoother background update experience.
Download User Setup
If you are a current user of the system-wide Windows setup, you will be prompted to install user setup, which we recommend using from now on. Don't worry, all your settings and extensions will be kept during the transition. During installation, you will also be prompted to uninstall the system-wide setup.
Reference: https://code.visualstudio.com/updates/v1_26#_user-setup-for-windows
I installed the user version side-by-side with the system version with no problems. The basic differences between the two is that the system version installs on the file system like every other app. The user install is basically a click-once (or web installer) version that installs in the User folder of the machine.
The settings made to VS Code in the system version save for Everybody on the computer and the user version the settings are only for the user. I find that the behavior of the user version is a bit annoying for me because I have reasons to want to open multiple copies of VS Code at the same time and the user version only allows one instance. Otherwise, there's not really anything different between the two as far as I can tell.
Many companies (like mine) dont allow Admin privileges, I think that's the main point so you can still install VSC with the user installer
After user version of Visual Studio Code is downloaded, make cmd in the download folder and run a command below, replacing the correct version in the VS ode installation file name:
runas /trustlevel:0x20000 ./VSCodeUserSetup-x64-1.74.3.exe
start the command below in order to check which trust levels are supported:
runas /showtrustlevels
I have installed DB2 10.1 in AIX 7.1 at /opt/IBM/db2/V10.1. But there is a script which is expecting DB2 at /opt/db2_10_1.
I am not sure if it is possible to change the directory of an installed software and if I do it, what are the points I have to keep in my mind before performing this step.
FYI- I am not an AIX or DB2 expert. I am just performing this task as instructed.
Did your instructions specify a non-default path for the Db2-installation?
(The path /opt/IBM/db2/V10.1 is a typical default for AIX )
Do not manually hack to change the installation directory of Db2, just because a script is badly written! Responsible admins would never allow such mistakes on production environments.
It is an error for a script to hard-code a Db2-installation path. That script should be coded correctly to determine the Db2-installation path, or to have that information provided via configuration or arguments.
A possible option is to create a symbolic link so that /opt/db2_10_1 points to the real path at /opt/IBM/db2/V10.1 , but this is not guaranteed to work for all situations, it depends on how badly written is the script - so other different errors may appear later from that script (although Db2 itself will function normally).
A separate matter is that it is unwise to install a Db2 version that is already out of support (end of life). Does the business understand the consequences of installing an out-of-support version? (unless the business has purchased an extended support contract from IBM).
You have to make new install
stop instance
rename sqllib directory
recreate instance using db2icrt in new binaries in install directory
import catalogued database with db2cfimp previously exported using db2cfexp
I will try this again. I can only get my .exe to run on the computer which created it and select other ones. Even once a application has been built into an .exe is it necessary that the computer it is run on still has powershell studio? Right now the executable will only run on computers with powershell studio, I am not sure if it is because these other computers are lacking a library or something along those lines or if every computer that I want to run it needs powershell studio. This as I have asked around is actually an issue with other executables which have been made from powershell studio so the problem is not exclusive to my code, which if necessary I can show some of. However I think it is more of an issue with the settings in the .exe builder which is something I am very new to and do not fully understand what or if I need to get it to work properly.I currently have left all the settings in the builder as the default settings so I am sure it is something in there that needs to be looked at I am just at a loss as for what.
Not a problem, just recompile it targeting the lowest common denominator. If you are on Powershell v3, but have some clients on v2, you'll need to recompile targeting v2.
To recompile, go into Sapien Studio and look for the drop down box on the ribbon, it probably says v3 - 64bit, change that to v2 -64bit and recompile. Good luck.
Alternatively you could install powershell v3 on those other machines and not need to recompile. That would also be the answer if you have to use a v3 cmdlet that simply does not exist in v2.
Noted: Future readers may also run into issues with x86/x64 bitness and system32 folder, if you are getting redirected into syswow64 sandbox, recompile 2 versions, one for 32bit, one for 64.
So I have a MATLAB program that I made and compiled in Matlab R2011b. Now I want to distribute the compiled version. I understand the user will have to install MCR on their computers to run my program. My question is: will it make a difference if this user already has some other version of MATLAB installed on his system. I checked MATLAB help and this was written
"Windows. To run deployed components against the MCR install, mcr_root\ver\runtime\win32|win64 must appear on your system path before matlabroot\runtime\win32|win64.
To run deployed components against the MCR install, mcr_root\ver\runtime\win32|win64 must appear on your system path before matlabroot\runtime\win32|win64.
If mcr_root\ver\runtime\arch appears first on the compiled application path, the application uses the files in the MCR install area.
If matlabroot\runtime\arch appears first on the compiled application path, the application uses the files in the MATLAB Compiler installation area."
So does each user has to change his system paths as instructed or will my program work even without this change?
Yes, if the target machine has a version of Matlab installed things will likely not work as expected. I say likely as if you have the the same version of Matlab installed on the target machine some things might work ok.
To avoid all of this you must ensure the MCR appears first on the path.
To run the application on the MCR on your local development machine you should make sure the MCR path appears before Matlab's path.
I can talk just from the viewpoint of my own experience:
Part 1, matlab + MCR of the same version
I think, this is just a recommendation... I never cared about it, and I never had problems with it...
It would work, and you, most probably, won't notice any difference.
I've just changed those records in PATH upside-down, and my compiled app is still working.
Part 2, several MCRs of different version
Multiple MCRs, say, R2010b and R2012b won't interfere. Tested 100+ times. So, unexperienced end user, who don't have Matlab, won't have to edit PATH.
I seem to have wiped out my path environment variable a while back. I've been slowly restoring things. I have both MATLAB and the MATLAB compiler installed. DLL's I've created from the MATLAB compiler won't run because they can't find the MATLAB compiler runtime dlls. While I did find the particular files that are my immediate problem. I'm wondering if there is a MATLAB *.bat file or command I can type that will restore my path variable to what it was after MATLAB and the Compiler were installed. I'm hoping to forestall future problems.
In case it's version specific I'm running MATLAB R2010b, I'm running a 32 bit version on a 64 bit machine.
[Edit]
I thought I would add that the path I need for running the compiled version was:
C:\Program Files (x86)\MATLAB\MATLAB Compiler Runtime\v714\runtime\win32
With luck, that one along with the two suggested in the answer will get me back to the original state.
restoredefaultpath might recover your MATLAB installation. Consider the use of startup.m, in order to easily undo changes to your environment.
You want to have these two directories on the PATH (I think the order is important):
C:\Program Files\MATLAB\R2010b\runtime\win32
C:\Program Files\MATLAB\R2010b\bin
Obviously you need to adjust the path to match your setup and architecture (those are on a WinXP 32-bit)
If you have a current software maintenance contract for your MATLAB, it may well be that the easy thing to do is just upgrade to the next version of MATLAB since R2011a is out now (unless there is some compelling reason why you must develop on R2010b. Running the software installer should recreate the default environment for MATLAB. I am, of course, assuming that you have Administrator access on your PC and have permission to install software.