I have a VB6 Application that I am deploying using Microsoft Development Environment.
The install package is working for Windows 7/10 32/64 bit.
The problem I am having is if a second user logs into windows and runs the installed app some of the controls are not working.
Forms that contain MSCOMCT2.OCX, TABCTL32.OCX and maybe others fail saying:
"Component ... or one of is dependencies not correctly registered: a file is missing or invalid"
But once again for the user that installed the app all is good.
I see in other installs there is a choice to install for only me or all users. I don't see a way to implement that in "Microsoft Development Environment", is this my problem?
What changes if you install an app for All users?
This may have to do with registry virtualization. The application may be running in some kind of compatibility mode so that the controls are not really being installed system-wide.
I'm not too familiar with those settings but it might be possible to adjust them so that the DLLs/OCX files are genuinely registered for all users and the application runs accordingly. There is a risk that if the compatibility settings were set intentionally, this could break something else.
Hopefully this is a useful starting point.
I will add that IMO installing the application not to require registration whatsoever is a much more robust solution. See How can you force VB6 to use the DLLs and OCXs from the app directory?
I'm working for a client that is getting an OSX app ready for release. They have a stand-alone app that installs browser extensions for the major browsers.
Their new version will be an app store app.
Is it possible to drive the process of installing a browser extension from an OSX app store app? From what I've seen, you have to lead the user to download the extension and then open it from the finder or from the browser's list of downloaded files.
This makes for a rather disjointed, error-prone installation process. The user can fail to download the file, can fail to open the file, or can fail to return to the app to complete the installation process. All of those things are bad, especially since this app is going to be free, with optional paid upgrades. If the user doesn't complete the installation process, my client loses them as a potential upgrade (paid) client.
As of v25 Google Chrome implemented security features which would prevent any extensions installed offline by a 3rd party application from being activated without first being approved by the user via a dialog prompt in the browser.
Mozilla had implemented similar security measures over a year prior with Firefox 8
It's likely been patched by now, but it was reported that you could bypass Firefox security measures and accomplish a silent extension installation by copying the extension directly into the Firefox extension directory and add a record of it to the browsers Sqlite3 database. The database record involves adding a boolean true value to a property which specifies if the add-on has been approved or not.
Later versions of Firefox switched to using JSON rather than the Sqlite database and a similar process was still possible.
If I understand your question correctly.. This is potentially feasible regardless of vendor security but impossible for any public production level application due to such security because it will never be stable.
Vendors have a high priority in locking processes like this done to prevent potentially malicious 3rd party code. Interested in the subject I came across a few possibilities. I can't guarantee whether or not any of these will work but perhaps it will lead you in the right direction..
I would try to do this will Applescript to automate the user actions or potentially guide the user through the process.
You can open the extension with
[[NSWorkspace sharedWorkspace] openFile:#"path/to/myextension.safariextz" withApplication:#"Safari"];
but that only gets you started.
An alternative possibility was mentioned here: https://stackoverflow.com/a/4393062/1922144
And then there was a discussion here that seems worth noting.. https://discussions.apple.com/thread/3067552?tstart=0
safari.msi /i /qn BypassDefaultBrowserCheck=true
I want to ask you if there is an alternative to the project of Mozilla byob (build your own browser, shut down recently).
If someone made it something similar maybe with Firefox or another browser.
There is the CCK Wizard that allows various Firefox customizations. You don't get an actual Firefox build but an extension. One way to deploy that extension on a machine would be adding it to the Windows registry which will automatically install it into all Firefox profiles on the particular machine. One could also modify a Firefox installer to include that extension but that is somewhat more complicated.
I am trying to create an installer for a Internet Plugin on Mac OS X with PackageMaker. I'm not picky about the tool I use, but it needs to be free. It'd be nice if I could do everything I want with PackageMaker because CMake/CPack supports PackageMaker and the project (build with FireBreath) is built with CMake.
The problem I am running into is that I am only installing the plugin for the current user -- in ~/Library/Internet Plugins -- but the installer still insists on asking for the admin password! I have heard that you can turn this off as long as you don't need to target versions of Mac OS previous to 10.5, but I can't find any way to do this.
Am I missing something? Is there a different tool I should use? Any help would be appreciated!
The fact that your installer asks for admin password might be because of some actions you have in your installation process, for example if you have actions to kill web browsers.
When I built my first installers for my (also firebreath) plugin, installing inside the user's directory, it was not asking for admin password. After I added actions to stop Safari and Firebreath, then my installer started asking for admin password.
I just noticed that Chromium was installed in AppData in both Vista and XP. If Google does that and if other applications does this, than is that becuase there is some form of protection? Should we write installers that does the same thing as Google?
Windows still lacks a convention for per-user installation.
When an installer asks whether to install for the current user or all users, it really only refers to shortcut placement (Start Menu; Desktop). The actual application files still go in the system-wide %PROGRAMFILES%.
Microsoft's own ClickOnce works around this by creating a completely non-standard %USERPROFILE%\Local Settings\Apps (%USERPROFILE%\AppData\Roaming on Vista / Server 2008) directory, with both program files and configuration data in there.
(I'm at a loss why Microsoft couldn't add a per-user Program Files directory in Vista. For example, in OS X, you can create a ~/Applications, and the Finder will give it an appropriate icon. Apps like CrossOver and Adobe AIR automatically use that, defaulting to per-user apps. Thus, no permissions issues.)
What you probably should do: if the user is not an admin, install in the user directory; if they do, give them both options.
One advantage nobody mentioned are silent auto-updates. Chrome has an updater process that runs all the time and immediately updates your chrome installation.
I think their use-case is non-standard. They need a way to fix vulnerability issues (since it's a browser) as soon as possible. Waiting for admins approving every single update company-wide, is simply not good enough.
As far as I can tell, the only reason why Chrome installs into the Application Data folder is so that non-admin users can install it.
The Chrome installer currently does not allow the user to pick where the application is to be installed. Don't do that – instead, give the user a choice between a per-user (somewhere like App Data) and computer-wide (Program Files) installation.
Windows 7 and Windows Installer 5.0 provide real per-user installation capabilities now.
http://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx
You can sort of fudge it in Vista and XP by using ~/AppData/Local or the equivalent like Chrome does. Microsoft themselves use this for the ClickOnce installers.
So at least on Windows 7 and beyond the solution is simple.
Frankly, I have yet to see the first installer that really allows both per-user and per-machine installations. Many installers offer this option in their GUI, but the setting only affects where the shortcuts etc. go -- the binaries always fo to %ProgramFiles%.
In fact, it is pretty hard to create Windows Installer packages that allow both kinds of installs, to say the least. With the advent of UAC, I'd say its is impossible: Per user installations must not require elevation, per machine installations have to. But whether an MSI package requires elevation is controlled via a bit in the summary information stream -- there is no way to have user input have impact on that.
Whether per-user or per-machine is the better choice greatly deoends on the application. For small packages, however, I tend to prefer per-user installations. Besides being slightly more user-friendly by not requiring an UAC prompt or runas, they also signalize the user that the setup will not do much harm to the computer (assuming he is a non-admin).
The Chrome installer really ought to allow global installation (with elevation) in addition to per-user. I don't want to have to maintain an installation for every user; I want to be able to centrally manage upgrades and so on. Chrome doesn't allow that.
That said, the option to install per-user is quite nice, as it means no permissions issues.
Just so you people know, Google has created an MSI installer for global system installation and management. It's located here:
https://www.google.com/intl/en/chrome/business/browser/
I do not see anything in %PROGRAMFILES% on Win7. Looks like Chrome must be installed for each user on the machine.
Perhaps the true reason of doing this is faking number of Chrome installations by few times ! Thus making it first browser in the world !