So i have the misfortune of embedding this proprietary ActiveX control we created into a web page so that it downloads the code from our server and installs as necessary.
Our ActiveX requires a host of other files which need to be installed along with the activex control itself. It should also be noted that the activex and all its dependencies are c++-based COM objects (many use MFC).
So I read this article about it:
http://msdn.microsoft.com/en-us/library/aa751974(VS.85).aspx
But it leaves a lot of things unanswered. For one thing, my ActiveX is actually embedded in a DLL file that contains other COM interfaces. Also, is it possible to have the mentioned cab file include the ActiveX/SDK installer and run that if the GUID isn't present? For example:
[version]
signature="$CHICAGO$"
AdvancedINF=2.0
[Add.Code]
Setup.exe=Setup.exe
[Setup.exe]
file-win32-x86=thiscab
run=%EXTRACT_DIR%\Setup.exe
Security is not an issue here as this is an intranet-based solution (not available publically).
Also, the article mentioned here seems really old. Is there more up to date info available?
You can create a dependency between the installer and a dll that is on the system like this:
[Add.Code]
Your-dll-name
[Your-dll-name]
Version=Your dll version
hook=setup.exe
[Setup.exe]
file-win32-x86=thiscab
run=%EXTRACT_DIR%\Setup.exe
If the system cannot find your dll or the version is lower, then it will run the setup.exe that suppose to install and register the dll.
Related
If I write an application using MFC libraries in C++, in deployment stage do I require to install some sort of frameworks or stuff like that?
My intent is to have a standalone exe without complicated installation scripts.
If you're developping a local application for your own organisation, you could go for static linking, as suggested by Danny.
But static linking is not the method recommended by Microsoft: every time there's an MFC related patch (example here) or z patch for another library, you'll have to recompile your code and redistribute or reinstall it in order to avoid PC's being exposed to security vulnerabilities.
This is why Microsoft recommends to use dynamic libraries: these are easier to update/replace (eventually latest versions are already installed; or automatic windows update; or if necessary manual download of the latest version).
If you go for dynamic approach:
there are a couple of mfc*.dll to distribute with your application, together with other standard libraries, such as Msvcr100.dll. It's all explained in the article. Installing such files in your app's directory has the advantage of a leaner installation process. But you have to take responsibility for their update in case of necessity.
or you choose to use Microsoft's redistribuable packages. These can be downloded directly from Microsoft's and are contained in a selff-installable file: vc_redist*.exe. Here some explanations on how to use them in installation process. It might install more dlls than required, but vc_redist is an installed Microsoft product that is kept up-to-date with Windows Update.
If you link MFC statically, there is no need for external files.
Project Settings / General:
Use of MFC: Use MFC in a Static Library
But, as Christophe mentions, it is not recommended by Microsoft.
On MSDN there is an example in C++ on how to create Dynamic virtual channel plugin.
My problem is that I don't know how to compile it.
Do I need to create an ATL project and in main.cpp copy-and-paste the code found on msdn? What do I call the project? If I create ATL project with name DVCPlugin, than Visual studio 2008 automatically creates DVCPlugin_i.h file, otherwise I don't have that file.
tsvirtualchannels.h is part of Windows 7 SDK so at least with that include I don't have a problem.
One of the errors I am getting is this:
&CLSID_DVCSamplePlugin not recognized identifier
I tried to create ATL project with the name DVCSamplePlugin but I received the same message as above.
Any suggestions I need to do to be able to compile that source code?
It took me a couple of hours, but I got the source for the client plugin to build using VS 2012. Here were my steps.
Start a new ATL Project named DVCPlugin. Select the option for a DLL.
Choose support for COM+ and check the box for the Object Registrar.
Add a file named GUID.cpp to the DVCPlugin project. include stdafx.h in this file.
ATL gave me a class named CompReg, which had its own IDL entries and GUID. I needed to associate that GUID with the CDVCSamplePlugin class.
In DVCPlugin.cpp, add the include for <tsvirtualchannels.h> to the top.
Paste the rest of the sample code after the definition of DllInstall().
Change the line DECLARE_REGISTRY_RESOURCEID(IDR_PLUGIN) to DECLARE_REGISTRY_RESOURCEID(IDR_DVCPLUGIN).
It looks like building the solution silently runs the registry script in the DVCPlugin.rgs file. I had to change the threading model to Free, though.
If mstsc.exe is 64-bit, you need a 64-bit plugin dll for the dynamic discovery to work.
This is just some code for testing Remote desktop connection -
There is an "echo" listener that is implemented by the Remote Desktop Connection (RDC) client, which is always present and listening for incoming connections. When you are writing the server side of a dynamic virtual channel (DVC) module, as a quick test you can open an endpoint named "ECHO". Any write to a channel that is instantiated from this endpoint will result in the receipt of the same data.
From MSDN.
Such projects are usually included in some SDK. And this one seems to be part of Windows 8 SDK
Update: After a critique from Tim (see below), i've decided to add these links with MSDN information -
Remote Desktop Services. TS-Teleport: Sample Instructions and
Remote Desktop Services Blog. Dynamic Virtual Channels
Can a Windows Installer perform logic like a normal application?
For example: I am creating an installer that installs plugin files to a 3rd Party Application's directory on the C drive. But the destination directory will be different if the user has an old version of the 3rd Party Application.
So the installer needs to determine what version of the 3rd Party Application is on the C drive. If its the new version I install the plugin files to C://Program Files//3rdPartyApplication// and if its the old I install to C://3rdPartyApplication//
So can a windows installer perform logic and if not can it run batch files that can do this?
An "installer" is just a regular application designed to unpack its contents onto a persons hard drive, and possibly perform actions like registry modifications.
If you use a installer like install shield for example you will have to look at that installer documentation to see what it can do. Most installer applications have some sort of area to create custom scripts.
You could also build your own, it is really not very hard.
Yes, installer can perform logic just like regular application. From this point of view, an installer is a regular application.
How you program installer logic depends on which installer suite you use. For detecting whether an application exists in C:\Program Files\3rdPartyApplication or in C:\3rdPartyApplication, you can use FileSearch element of WiX Toolset, look through Windows Installer documentation: Searching for Existing Applications, Files, Registry Entries or .ini File Entries.
More sophisticated logic can be implemented by custom actions. [Custom Actions}(http://msdn.microsoft.com/en-us/library/aa368066.aspx) can be written in JScript, VBScript, C/C++ (DLL or EXE; yet the EXE can't communicate to the Windows Installer session).
I'd like to give a different perspective. Windows Installer is a declarative domain specific programming language. It is not a Turing complete general purpose programming language. It is not intended to be just like any other application. It can be extended with custom actions written in general purpose programming languages such as C++/C# but it should stil follow the same declarative approach where you seperate the "how" to do something from the "what" to do.
Now to answer the second part of your question. Windows Installer has built in searching capabilities. Read the MSDN topics on the AppSearch standard action and related tables (AppSearch, Signature, DrLocator, CompLocator, RegLocator ) You can also put conditions on components and you can set directory destinations dynamically so yes, there are ways of doing what you want to do.
It would require much more information to explain exactly how to do it.
Yes, Windows Installer can perform logic like a normal application.
You can use the WiX Toolset, as suggested by Alexey to get the job done.
You can use the FileSearch element ( http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) to check for the existence of files or the RegistrySearch element ( http://wix.sourceforge.net/manual-wix2/wix_xsd_registrysearch.htm) in case you want to check using a registry key.
Alternatively, if the search isn't as simple as checking for a file or a registry, a Custom Action would let you write managed or unmanaged code (according to your preference) to check which version of the 3rd party application is installed.
On the basis of the result of your search, you can, at run-time, change your install directory. A Type 35 Custom Action would let you change the install directory:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368093%28v=vs.85%29.aspx
I've a Windows Application in which we are using Infragistics controls. Now, we are creating its setup project using InstallShield.
This is my first time with InstallShield. It seems we need to provide Infragistics setup in dependencies. I don't want to install setup or it shouldn't be. Can't it be done just provide Infragistics DLLs which we have in our Debug/Release folder?
Please, help!
Thanks.
Infragistics is one of those companies whos runtime consists of a boat load of COM DLL's and they don't provide any sort of runtime redist be it an EXE/MSI or MSM ( Merge Module ).
Are you targetting only Windows XP and greater? If so, I personally would deploy all of the DLL's in your application directly privately and use COM-Free registratition through manifests that way you don't have to write to the registry and take a chance of conflicting with another application. Basically when your EXE is run windows looks at the manifest and virtualizes the COM information allowing your process to make the needed COM calls.
InstallShield 12+ has a wizard to assist in creating this.
http://kb.flexerasoftware.com/doc/Helpnet/installshield12helplib/IWPRegFreeComWiz.htm
If you still have to support Windows 2000 or you have requirements that makes the above not possible, I would go ahead and install the files to System32 as permenant components and extract the COM metadata into your MSI. The component wizard will help you set that up.
We use Click once so this may or may not apply but...
For some reason you have to set each DLL to "Include" not "Include (Auto)" in the publish application files.
We use Infragistics libraries in our WinForms products. Infragistics does not provide a redistributable package, so you will need to handle distributing them manually. Just include all the dlls that your product depends on and install them to the local installation directory. There is no additional setup that needs to be done to use the Infragistics dlls at runtime.
I'm going to create a utility with GUI that will run on Windows operating systems.
It should require minimum (or zero!) amount of additional libraries, files or DLLs to run because it will be executed from an installer. Because of this, i don't want to use .NET for it will require user to install .NET Framework. I know today, most of Windows installed system come with .NET Framework but in my case i cannot be sure.
The utility will...
send some data to a web site and
parse the returning data,
collect some hardware info, like MAC address,
CPU type and make, hard-disk serial
number
I suppose native Win32 API could be used for all of those above, but instead of hassling with Win32, i'd prefer using a more developer friendly API, or SDK.
Thanks in advance.
Win32 API is the only way, and of course there are standard API - for sending data over the internet, you could use WinInet.lib/dll, to obtain information about the MAC, you could use the GetAdaptersInfo by using Iphlpapi.lib/dll,(here's a link on how to use it) for the Hard disk serial number you could use GetVolumeInformation by using kernel32.lib/dll. For the CPU Id, you might look into GetSystemInfomation
Edit: There's a C++ code, but you can easily derive a wrapper from this site Unfortunately, with WinAPI is not easy, no such thing as RAD with WinAPI but what you gain out of it is lightweight code instead of relying on SDK's, frameworks and dragging buggy dll's around with your application.
Hope this helps,
Best regards,
Tom.
You can statically link most C++ GUI libraries - even MFC. Personally, I recommend WTL, wihich is very light and header-only.
If what you want is minimum dependency with external files or DLLs you could statically compile all the required DLLs with the tool exe. Then you could use something like Visual C++ to develop such tool.
WTL is perfect for this sort of application and I am surprised more people aren't recommending it. You can also statically link with the CRT and hey presto - no dependencies and a very small EXE.
Delphi (now by Embarcadero) would do the job, creating a .exe file with no dependencies, and it is much easier to work with than the raw Win32 API.
If you don't like Object Pascal, you could try C++ Builder instead.
For the GUI you can either build your application with MFC (statically linked) or use a HTML based dialog that you can interact with using COM. (It is even possible to interact with javascript present in the page displayed by the dialog).
For the specific requirement that you do have, I feel Win32 API is the only way out.
Use MFC and statically link to it. No runtime dependancies need to be installed.