I am finalizing an application that will soon be submitted for Windows Logo Program validation. One of the requirements is x64 compatibility. Specifically, Crystal Reports 2008 must work under x64.
My problem is that Crystal Reports basic 2008 (the one packaged with Visual Studio 2008) has no merge modules and must be installed using the provided .msi installers. They offer separate installers for x86 and x64.
So how would I detect x86 and x64 during install and then run the appropriate Crystal msi? Is this even possible without merge modules?
EDIT:
This:
IF PROCESSOR_ARCHITECTURE == x86 AND
PROCESSOR_ARCHITEW6432 NOT DEFINED THEN
// OS is 32bit
ELSE
// OS is 64bit
END IF
seems to tell me how to detect it (thanks MicSim). But how do I perform this in an MSI? Is it a custom action? And then how do I trigger different required msi's for the x32 and x64 crystal reports?
And why doesn't the x86 crystal installer work under WOW64? You have to install x64 Crystal to work with your WOW64 x86 app. Frustrating...
EDIT 2:
Okay, so detecting x86/x64 seems to be covered here. Now how about manually triggering an msi of your choosing?
The easiest way I have found to detect a 64-bit operating system is to use the VersionNT64 property. This property can be used in conditions for components or custom actions (eg. the condition Not VersionNT64 will only be true for 32-bit operating systems).
As for installing other MSI packages during your installation, that is a little trickier. Windows Installer will only allow one MSI to be running the Execute Sequence at a time. This means that you must either install your Crystal Reports MSI during the UI Sequence using a custom action (be careful if you do this, the UI Sequence is skipped if the MSI is run in silent mode), or create some kind of bootstrapper program that will run both the Crystal Reports MSI and your own in sequence.
I have never created my own bootstrapper, but InstallShield has a bootstrapper program built into their setup.exe; they call packages installed this way prerequisites.
Just googled it: If you have an MSI project you could check the properties like described here.
For further information about detecting process and OS architecture you might want to read this MSDN blog about "HOWTO: Detect Process Bitness".
You can trigger the Crystal Reports MSI with a custom action that executes [SystemFolder]msiexec. Just specify "/i [YourFolderWithCRMSI]msiname.msi" as the arguments.
According to this forum, Crystal Reports now includes a merge module for visual studio 2008.
HREF=https://smpdl.sap-ag.de/~sapidp/012002523100005986132008E/cr10_net_mm.zip
Edit (from the author): It turns out that this doesn't work for the Crystal Reports that comes bundled with Visual Studio 2008.
Related
I need to check if Crystal reports runtime environment(32/64 bit) is installed in my system using inno setup. How can I do it?
you can check any thing installed or not with inno setup by using different ways
you can find Crystal reports runtime environment(32/64 bit) is installed or not,
By querying registry or By checking for existence of directories or By checking for existence of files of that particular installer.
Check this answer will help you to find the way. Here I was explained how to check MySQL is installed or not, Apply same for Crystal reports runtime environment(32/64 bit).
We are using Crystal Reports XI R2 (11.5.3300.0) in existing (32 bits) applications. We are in the process of upgrading to Windows7 64 bits.
During our compatibility tests, we bump into an issue indicating the crystal reports runtime is not available. I'm leaving out the exception detail here, as it is in Dutch, but basically it is saying that the runtime is not installed correctly, and that I should install the distributable CRRedist*.msi.
The problem I'm having is that I can't seem to find that distributable. When I check on the support site, https://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=56787567, it refers to a bootstrapper in the Program Files folder. However, the indicated subfolder does not exist.
Anyone who has bumped into the same type of problems for this version of Crystal Reports (I'm aware of the fact that several versions have been released after this one)? Where can I find the redistributable?
Mind that our applications are compiled for x86, so I think that the x86 runtime should do the trick.
Thanks.
just a quick caveat to any answer for you, if performance is important you should know that the x86 dlls will be significantly slower under emulation in an x64 o/s
I know this is an old question, but it was something I ran into as well so I wanted to update it with my experience.
I was not able to locate a redistributable for 64 bit. Instead, I had to change the project I was compiling to target x86. By default the C# and VB projects have the property settings on the project set to AnyCPU. Change it to x86 and this problem goes away.
For VB.NET, right click on project and select properties, go to the compile tab. On VS 2012, you will find it on the Target CPU combo box on that screen. On VS 2008, you need to select "Advanced Compile Options..." and then you will find the Target CPU combo box.
For C#, right click on project and select properties, go to the Build tab and you will find it as "Platform target:" combo box.
I'm trying to access the TargetPlatform property value (which you can set in a Deployment project) from the condition within a "Launch Condition".
Basically I'm trying to tell the application not to install itself as a 32bit app if a 64bit version of Office is installed on that computer. Therefore I need to somehow get the application's bitness and put it in a launch condition.
I can get the bitness of Office from the registry, but I don't know how to access the TargetPlatform from the installer.
Thanks!
Here are two link:
Deploy1
Deploy2
From the above link you can deduce that you can't target both platforms from a MSI installer. You will need to have two installers. Depending on how the installer is built, x86 or x64, will depend the way the installer interprets some constants that tell where to isntall the files - Program Files, or Program Files (x86).
You can't change the TargetPlatform of the installer at runtime.
What you can do maybe is to have two installers packed into a third one and based on the Office version installed that you say you can obtain run either sub-installer x86 or sub-installer x64, that will actually install the application files.
If MSI installer is not the outmost requirement I would go for NSIS. If not at least package the to MSI installers into an NSIS one. It is incredibly easy. NSIS is way cooler than MSI, talking from experience.
I've read this question a few times now and I'm not 100% certain I understand what you are trying to do. Do you have a 32bit application and you only want to install if they have 32bit Office (2010 I assume) installed? Do you also have a 64bit version that you want to install if 64bit office is installed?
I'm not sure why you need to care about the TargetPlatform property because if you know that 64bit Office is installed you must by definition be a 64bit OS. If 32bit Office is installed you could possibly be a 64bit OS but does it really matter? You said you cared about the bitness of Office not Windows.
I would think, from what I've read, that if you have an AppSearch that pulls the bitness into a property that you could just use a LaunchCondition that uses that property along with "or Installed" ( to handle being able to uninstall your application if Office was uninstalled first ) and be just fine.
Add a custom action before the installation starts to perform the check. Use an Installer class to perform the custom action. You could use the OnBeforeInstall event to read the registry key and check the bitness as appropriate. Throwing an exception will cause the installation to abort, but there may be a cleaner way to do this.
Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).
Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)
Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.
Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?
Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.
Does the code use any Office 2007+ methods or classes? If not, are you sure you cannot use the 2003 PIAs in all cases? The later apps should be backward-compatible (supporting the same API) so the only reason you'd need an updated PIA is if you needed to access some feature added by 2007 or later, I think.
You may want to take a look at Add-in Express, which promises a one-for-all-versions installer, and is pretty easy to use.
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility
You cannot. You must create custom installer packager (setup bootstrapper).
Many years ago I used dotNetInstaller with HTML GUI builder, today WiX toolset would be better solution, I think.
Check how PIA .msi installers are constructed with Orca or .msi and .exe installers flow checking windows installer logs.
Based on registry checks, file checks, installed product checks, windows versions, office versions you can create conditions whether component should be installed or not.
Oh and I advise making plugin installers without prerequisites and installing them conditionally with your custom installer bootstrapper.
I believe the conventional way to deploy Crystal Report with a .NET program is to set it as a prerequisite in the publish settings and then a .msi will be packaged with the ClickOnce files on the web/network/CD/wtv. When the user runs setup.exe, it will check whether Crystal Report is on the client computer. If not, it runs the Crystal Report .msi. But that will always require admin rights.
My question is, is it possible to package Crystal Report's dlls along with other application's output assemblies so that no explicit install is required? My application makes use of many many components and including a dll with the install is sufficient for most of them. Could I do the same with Crystal Report?
I hate to be the bearer of bad news, but Crystal Reports for Visual Studio .NET is not designed for click-once deployment. Crystal Reports is a native application, and the assemblies you use to deal with the report depend on many non-.NET libraries.
Lots of COM objects that require registration, support DLL's that have to be installed... Licensing information that must be placed somewhere (Crystal Reports has always been big on licensing).
In theory, if your application is running full-trust you could monitor the installation of the Crystal Reports for .NET runtime, and duplicate it in c#, but that is a lot of work, and will be unreliable at best.
Sadly, the final answer is you can't.
You might check out Active Reports, or some of the other pure .NET reporting solutions.
If you are dead-set on doing it yourself, you can monitor the installation of the Crystal Reports runtime to see what files/registry entries/settings it creates/modifies. Alternatively, you can decompile the msi or download and decompile the mst transform file from Crystal Reports. Once you know what it is doing, write something to do it yourself.
I am almost sure that there is a redistributable package of libraries that ships with the final version of Crystal Reports when you buy it (not sure if this package ships with the Visual Studio version).
I'd provide a separate link to the Crystal Redistributable on the installation site and build a check in the ClickOnce app for the presence of the Crystal files.
You can add CR runtime merge module to your click-one MSI package, MSI will take care of merge module installation, It merges crystal report runtime installation files\process to your application click-one package.
https://origin.softwaredownloads.sap.com/public/site/index.html