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.
Related
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 windows form application which is being installed on client pc by using msi file trough active directories, application is a 32bit app which is being deployed to a 32 bit and 64 bit windows systems and as we know application folder names are different between 32 and 64 bit systems, Program Files and Program Files(x86), also during installation application shortcut is placed in startup folder so app will be started when PC us powered up.
Question: Is there a chance to build msi by Windows Installer provided by Visual Studion in such a way that it will check what operating system its being installed at and place the shortcut in to start up folder with correct URI, to Program Files\Applicaiton\ or Program Files(x86)\Applicaiton?
Thank you!
Windows Installer packages are platform aware (x86, x64 ). Windows Installer doesn't support 64bit packages running on 32bit platforms or 32bit packages writing to 64bit ProgramFiles.
You can compile your EXE as AnyCPU and even though it's installed as 32bit it'll execute as 64bit. Although the Visual Studio team has moved away from that and compile as x86 by default in recent versions of Visual Studio.
Upon initialization, the Windows Installer gathers information about the operating system and automatically sets properties that can be used in optional conditional statements used by the setup application, such as VersionNT64 and "System Folder Properties"
In cases where it is necessary for the setup to know this information, it is preferred practice to allow the Windows Installer service to determine folder locations rather than try to hard-code this information into the package.
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 was browsing the web and found out that my application would
probably not work on (win)64bit machines. And that this is due to the fact
that MSVC uses my default 32bit runtime and sets the application to work only
on 32bit machines.
How can i set my simple application to run on x86 machines? thus making 64bit machines
use WoW64 when executing my app?
I'm using MS visual studio 2010 express (kinda short at the moment).
32-bit applications will work on Win64 OS's.
There are some special things you might need to do if your application needs to access the 'true' system32 directory or certain registry keys. However, the vast majority of 32-bit applications don't need to deal with that (some that might include file managers or registry editors). In fact, the redirection was specifically put in place by Microsoft so that the redirections would help the application compatibility.
However, if your application requires a special device driver - that would have to be built for a 64-bit platform (again, this is pretty rare).
You should test your application on a 64-bit platform, but the expectation is that in general it should just work.
I have an application that allows me to scan images on my development PC which works successfully. It uses the Microsoft Windows Image Acquisition COM ActiveX dll. I am running VS2008 on Windows 7 64 bit.
I am having problems trying to deploy the Interop dll using ClickOnce. This component is referenced through the VS project in the normal way (and copy local = true). When I install the application on a Windows XP machine, I get an error saying that the library is missing (i.e. it wasn't installed / registered correctly). Having looked in the System32 directory, the dll is not there, so it has to be deployed via my app.
After looking on the web and trying various solutions, I then tried Microsoft's 'Registration-Free COM' method here: http://msdn.microsoft.com/en-us/library/ms165432%28VS.80%29.aspx
However, changing the Isolated property to True then caused 2 compilation errors due to duplicate entries in the registry. Having sorted out these entries out manually, I then deployed my app again with the supposedly isolated COM component, but when I try to scan a document I now get this message:
'The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll'
I feel like I'm going round in circles with this one. Can someone please enlighten me on how to deploy the WIA interop via ClickOnce for all versions of Windows from XP onwards?
Your help will be greatly appreciated.
Thanks
Don't copy system DLLs from your Win7 machine to the XP machine, that can't work. It would have been easier if you named the file, I would guess at wiaaut.dll, the WIA Automation provider. It probably just isn't installed on the XP machine.
Ask the client to install this download on the machine. You don't need reg-free COM, these are system components.