I am (still) using Visual Studio Professional 2013. I've been using InstallShield LE to create the Setup.exe for a Windows 7 desktop app with no issues. However, when installing the app on Windows 10 machines, the app does not run correctly (can't read my ini files for examples). Changing the exe to "run as Administrator" resolves this.
However, I have to go into every Windows 10 install and change this manually. Not practical.
Is InstallShield LE on 2013 NOT Win-10 compatible (e.g. need to upgrade to VS 2016??) or is there a setting in LE that can be changed for compatibility with Windows 10?
It is possible to modify the ACL on the settings files (during installation) to make them writeable for standard users. This is commonly used, though very undesirable. See issue 14 here in a list of common design problems in MSI files: How do I avoid common design flaws in my WiX / MSI deployment solution?
I doubt Installshield LE has any features for this ACL modification. WiX does, as does the commercial edition of Installshield and Advanced Installer. There are other tools as well that may support it.
Another "solution" that I don't recommend, but that is still used by many: How do I force my .NET application to run as administrator? I suppose this is effectively what you are doing? See this answer as well for an important note (it is a different answer from the same "thread").
The real solution is to re-design your application to not store settings files in the application installation directory, but rather store your settings in HKCU in the registry, or in a settings file stored in the user profile. Regular users can obviously write to these locations.
Not 100% the same, but very related. An answer with a list of options to allow an application to write to HKLM in the registry: Per Machine App Registration. Recommended read / skim.
Related
I use a machine where I don't have administrator rights. I've been able to run programs without admin rights by extracting the program's .zip file to a directory I have created on my desktop. However, I can't find such a .zip file for Visual Studio.
Is there a way to install Visual Studio Community Edition without administrator rights?
Practically no. Visual Studio (Express and above, excluding VS Code) consists of multiple components that must be installed as admin, and will be required for the app you're debugging to be available as system-wide component. It might be possible to use ThinApp or its equivalent, but ThinApp can't even work with VS 2010 and it was by far the best of its class.
A (resource intensive) alternative to get VS on any PC will be packaging a VM with VS installed, either creating one yourself or get a ready-made ones. VirtuaBox is available as portable fork if you can't even get Hyper-V tools installed. But this still require kernel drivers installation, which means at least one-time admin access. Depending on your internet connection & budget, it might be more practical to setup a VPS with VS installed, then remote there.
Basically, youre going to need to download an iso of windows, then download QEMU, and run it as invoker by doing that batch file thing (https://techcult.com/how-to-install-software-without-admin-rights/). Set it to anywhere, and then figure out how to boot it to QEMU cause I have absolutely no idea how (ive only done it with Kali Linux). and just install VC on there. Sorry about being so vague.
There is no way to install or use Visual Studio on Windows without admin rights. You can either use a different program to write your code in and then compile using a different compiler. Or use qemu (since it does not require admin rights) to run a windows virtual machine.
2 files required for the MS DHTML control to work properly were removed from windows vista (and win7, 8 presumably) for security reasons.
These are the DHTMLED.ocx and TRIEdit.dll.
Microsoft now supply a downloadable msi file, dhtmled.msi, which will install and register the 2 components into the following directory:
%windir%\Program Files\Common Files\Microsoft Shared\dhtmled\
I would like to build this into an inno script.
Should I run the installer on my machine first to get hold of the ocx and dll files and have separate lines for each in the inno script or should I incorporate the msi file into the script?
Also what flags should I use to prevent installation on win xp or earlier and when the files are already present?
Thanks
See Replacing the DHTML Editing Control in Windows Vista and Beyond
For new applications, you can ship the installer as part of your product (with appropriate licensing) and chain to it from your own installer. The installer can be run silently and without adding an item to the installed-programs list in Windows. (For details, see the documentation for MsiExec.exe.)
However, we recommend that the installer allow the DHTML Editing Control to be added to the installed-programs list. In addition, when your application is uninstalled, do not uninstall the control; instead, allow customers to uninstall it separately if they want.
Note that this method of installation does not provide logo-compliant installation.
The method that is compliant would be to list this as a prerequisite that the user manually installs before running your installer.
I haven't seen anything the permits redistribution of the naked libraries under any circumstances.
I have a vb6 application installed on a server. It works perfectly.
I am trying to relocate it to a different server, however I get an error: "Component: TABCTL32.OSX or one of its dependencies is not registered". TABCTL32.OSX does not exist on this server.
On another Windows 2003 server I get a different error saying another component is not registered. I read somewhere that VB6 is not installed by default on Windows Server 2003 and I read somewhere else that it is. Is there a way to see if it is installed? I am unsure what to look for in Add/Remove Programs. Do I need to install this: http://support.microsoft.com/kb/192461?
As suggested by the topic Windows Server 2003 includes a new version of Msvbvm60.dll this OS certainly does include the VB6 core runtimes. However it is not guaranteed to have the base subset of auxiliary VB6 libraries Microsoft began calling the "Runtime Extended files" in Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, and Windows 8.
In any case tabctl32.ocx must always be deployed anyway since it isn't included there.
The package described in VBRun60.exe installs Visual Basic 6.0 run-time file that you provided a raw link to is a sort of kludge and in any case is only meant for older versions of Windows (NT 4.0, Win9x) in the rare cases where you'd use it.
The VBRun60.exe file is not intended to replace the Package and
Deployment Wizard (PDW) for distributing Visual Basic applications.
For that matter it doesn't contain or have anything to do with tabctl32.ocx anyway.
Essentially what you are asking is not a development question and isn't appropriate for StackOverflow. It is an administrative issue more appropriate to somewhere like ServerFault instead.
If you aren't deploying this application using a proper installation package then that may loosely be considered a development issue, though it still really isn't.
Redistribute and register tabctl32.ocx in your setup.
If you do not have a setup, copy that file - preferably into (32 bit) windows\system32 folder or into the application's folder and issue the command regsvr32 tabctl32.ocx from within a command prompt with administrative privileges.
I'm using a very old version of InstallShield Express 4 to package my VB6 application. Installing it on XP, it works great. But when I install it on a Windows 7 box, not using the "run as administrator", everything seems to be read-only. I can't edit an INI file because access is denied. The application just doesn't function properly. It's almost like it can't even access the folder. And it's installed in the default "program files" folder. I uninstall the application, reinstall using the "run as administrator" option, set compatibility of the short cut to "run as administrator", and everything works fine.
My question is this something inherited in VB6 where the application has to run as administrator or is it an InstallShield issue? And if it is an InstallShield Express issue, would the latest version of InstallSheild Express 2012 fix this? I would prefer the user not have to worry about installing or running the application as an administrator.
Nothing is specifically wrong with your VB6 application. I would say it's the older version of InstallSheild which might be the problem in this case.
The feature is called User Access Control (UAC) that has been introduced in Windows Vista and the following Microsoft operating systems to prevent arbitrarily write access into %ProgramFiles% by applications. You can still perform it manually (by copying and pasting files into %ProgramFiles%) but UAC will prompt for your permission.
To make sure your application behaves expectedly, save application settings in %APPDATA% or in registry, NOT in %ProgramFiles% directory. During installation or uninstallation of your program which requires write access into %ProgramFiles%, you'll have to run it as administrator (unless of course you have UAC disabled which is a massive security risk and strongly recommended against).
Yes, there is something specifically wrong with your VB6 app. It is storing its data in the wrong place. Your application cannot access the program files folder, unless it is running as administrator. This is due to User Account Control, as explained in gsabil's answer.
Here are some solutions (the best one last)
Always run the VB6 app as administrator.
Turn User Account Control off. This opens some security holes and is not recommended
Make your install program change the permissions on your installation directory, granting write access for all users. This is rather a hack, but it could be a fast way to get your program working
Change your application (not your install program) so that it stores its data in %AppData% rather than in the installation directory. This is preferable. Here is some detailed advice on how to do this in VB6
When trying to install a web setup project (MSI) created in Visual Studio 2010 on Windows Vista, Windows 7 or Windows 2008 Server the setup will fail, with some generic error.
According to http://devio.wordpress.com/2011/04/26/pitfalls-installing-web-setup-msi-on-iis-7/ this is because of a compatibility problem between the setup project en IIS7.
To resolve this I've to enable/install IIS6 metabase compatibility in my windows configuration. This workaround did fix the problem, but raises 2 questions:
Does this have any (negative) impact on functionality of IIS 7?
How can I notify a user running the installation of this problem so he or she can take proper action and install the metabase compatibility component? Is it possible to pop-up the windows component configuration dialog from this install, to make life easier for the user?
I don't think this will have any impact on the application itself, as long as it's implemented the way to talk to IIS7 via its native API. Otherwise, if it doesn't support IIS7 you'd have to enable IIS6 compatibility anyway.
The standard approach to search for anything on a target machine is searching registry and file system. I don't know how it is possible in VS setup project, but e.g. WiX has special elements for this (RegistrySearch, DirectorySearch, FileSearch). Basically, this post to WiX Tips and Tricks thread shows how to check for IIS6 compatibility in WiX and block the installation if it's not enables/installed. It's rather straight-forward even if you don't know WiX, but know the concepts of Windows Installer, and it can help you translate the code into the similar thing in VS setup project.
We seem to be having one negative impact on our servers.
Everytime we roll out a .NET 4.0 application with a msi made in Visual Studio, We get a recycle of ALL our application pools, even the ones not affected by the install.
Apparently the root cause of this is the IIS 6 compatibility. ( This was reported to us by a developer of microsoft in response to our support question about this.
At the moment we have no solution. It's impossible to convert all our installers to Wix.