What is the COM interface that need to be implemented in order to deploy COM dll in a vista/win7 machine. I heard that there is something to deal with UAC accounts with COM,
but I could not find MSDN page for this, Please help.
Thank you
All you have to do to register a COM object is write the appropriate keys to the registry. There is no special interface to implement on Vista; however you need to make sure your installer has Administrative rights so it can actually write to the registry. By default programs will run as medium integrity level applications, which can't write to HKLM and HKCR (in general). If you install using MSI (look into the WiX toolkit; it makes registering COM objects easy) then the OS will automatically prompt the user for elevation at install time.
If you are deploying a COM control, it is probably as part of an application install.
In which case it is possible to use an application manifest to achieve Registration free COM. (The linked article is in the .NET section not the Windows section of MSDN, but applies to Win32 development and deployment).
There is no special COM interface, but you have to have elevated rights in order to run regsvr32.exe to register your COM dll. If you use an MSI to install, then Vista should automatically prompt for UAC elevation when your installer tries to register your COM dll.
There's some more information here about the UAC issue on Vista
http://blogs.msdn.com/vcblog/archive/2006/09/06/742187.aspx
Related
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.
I see that v2.0: 75% there post mentions Autocad and there is an AutoCADApp.cs file, but I can't seem to find a reference for using Rubberduck outside of Office, under some random host application. There is this Adding a new Host Application to Rubberduck but that is already done for Autocad.
Using Rubberduck under Autocad requires building from source?
Or is there a procedure to use the already installed release package?
Disclaimer: I'm heavily involved with the Rubberduck project.
Likely you're simply missing the registry keys for AutoCAD's VBE to notice your ducky.
Rubberduck's installer searches for the bitness of your Microsoft Office install, and then registers itself using that bitness.
So if you have 32-bit Office and 32-bit CAD, you're all set. Ditto with 64-bit Office and 64-bit CAD. In your case you probably have 32-bit Office but 64-bit CAD, and so there's no registry key to tell a 64-bit VBE to load an add-in called Rubberduck.
You can run the PowerShell script you found in the project's wiki (it creates both 32 and 64 bit addin keys), or create the missing HKCU registry key manually, but then the add-in will be seen, but still won't load, because the COM interop stuff was registered under 32-bit nodes, and CAD will expect RD to be registered under 64-bit nodes. To register for 64-bit, you'll have to run (as administrator) a 64-bit regasm.exe command, as described in the "troubleshooting 'add-in could not be loaded'" section of the installer wiki:
Note: the bitness of your OS is irrelevant.
Bring up an administrative command prompt (cmd.exe), and execute one of the following commands:
32-bit host:
c:\windows\microsoft.net\framework\v4.0.30319\regasm.exe "(path to install folder)\rubberduck.dll" /codebase /tlb
64-bit host:
c:\windows\microsoft.net\framework64\v4.0.30319\regasm.exe "(path to install folder)\rubberduck.dll" /codebase /tlb
Note that these registration steps are required even if you build the addin yourself from the source code.
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
New microsoft's IDEs like Visual Studio 2008 or 2010 creates exe files with manifest resource by default. But i still have some projects in Visual Studio 6 and i need to compile them to be maximum compatible with Win Vista and Win 7.
So i have many questions about manifest resources:
1. Is manifest resource required to create well-formed application for Win7 or WinVista?
2. What information is required in minimal manifest by WinVista and Win7?
3. Can wrong manifest resource trigger Program Compatibility Assistant under Windiws 7?
4. Is manifest resource required for DLL?
5. Where can i get information about using manifests?
1. Is manifest resource required to create well-formed application for Win7 or WinVista?
Without a manifest (with a requestedExecutionLevel element) Windows Vista and Windows 7 use heuristics to try and guess if the application is a setup application - which means that a normal application might for no discernable reason start triggering UAC elevation propmpts.
requestedExecutionLevel also tells the system to NOT virtualize access to protected resources.
2. What information is required in minimal manifest by WinVista and Win7?
At least the requestedExecutionLevel so UAC knows canonically that you do - or do not - require elevation, and to not virtualize access to Program Files or HKLM.
3. Can wrong manifest resource trigger Program Compatibility Assistant under Windiws 7?
with a manifest, Windows vista and 7 will think you are a "modern" application that is merely broken. The Program compatibility Assistant logic is reserved for legacy applications - i.e. applications without a manifest or with with a manifest with XP only entries (i.e. lacking requestedExecutionLevel ).
4. Is manifest resource required for DLL?
As of windows 7 Only if the Dll uses it for binding to side-by-side assemblies. MSDev Studio creates manifests in Dlls with requestedExecutionLevel elements but this actually produces an invalid Dll that cannot be loaded successfully in some situations.
5. Where can i get information about using manifests?
On MSDN: Isolated Applications and Side By Side Assemblies is the only official reference I know of that even attempts to describe the manifest schema and how they can be used.
To summarize: If you are developing - and thus have presumably tested your apps behaviour - on Vista or Windows 7, it would be best if you included a manifest to avoid your application being treated as a legacy application.
A couple of reasons you could need a manifest. First and foremost, you need one to tell Windows that your program is aware of UAC policies. That requires a manifest that contains the <requestedExecutionLevel> element. If that is missing, Windows will treat your program as a legacy program and redirect unsafe access to the registry and the file system. Writes to privileged registry keys are redirected to HKCU. File writes to privileged directories are redirected to isolated storage.
You'll need a manifest if your program is using DLLs that are stored in the Windows side-by-side cache. That is pretty unlikely to be the case if you still use VS6. WinSxS is used for the MFC and CRT libraries by VS2005 and VS2008 programs. But not VS2010, by popular demand from MSFT customers.
You'll need a manifest if you want to enable visual themes for your application. Required to load the modern version of the common controls from comctl32.dll version 6.0, stored in the side-by-side cache rather than the legacy version stored in system32.
And you need a manifest if you use registry-free COM, the manifest entries replace what is normally written to the registry, allowing for local deployment of in-process COM servers.
Most of this is automated in the modern versions of Visual Studio.