2008 SP1 Merge Modules

[Former Member]

The latest Crystal 2008 merge modules on the download page are not the SP1 version. The CRRuntime_12_0.msm gives file versions 12.0.0.840, whereas the SP1 designer (including the files we use to develop / compile our application) has file versions 12.1.0.882.

Where can I find the merge modules for Crystal 2008 SP1? I've spotted another forum posting providing an MSI package for VS for SP1, but it's the MSM I'm after.

[Former Member · Accepted solution]

Hi,

Any idea when the SP1 merge modules will be available to download?

Thanks.

[former_member11696 · Accepted solution]

Hi Peter,

They are available from this [link|https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/bobj_download/main.htm] now:

Thanks again

Don

[Former Member · Accepted solution]

Thanks for these Don.

I've downloaded and used these to build an install package, which has deployed fine on one of our test machines. However the module CRRuntime_12_1.7C0C7D58_142B_4283_B9AE_A953E850EC7E has 10 dependencies listed, which give build errors when attempting to retrieve the dependencies (using InstallShield). The dependencies relate to various Microsoft .dll's (although only the GUIDs are listed):

ATL.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E

ATL.Policy.66332652_9C28_58B1_FF1F_C8B3B9A1E18E

CRT.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E

CRT.Policy.63E949F6_03BC_5C40_FF1F_C8B3B9A1E18E

MFC.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E

MFC.Policy.68B7C6D9_1DF2_54C1_FF1F_C8B3B9A1E18E

MFCLOC.74FD3CE6_2A8D_0E9C_FF1F_C8B3B9A1E18E

MFCLOC.Policy.D2730D3F_3C41_5884_FF1F_C8B3B9A1E18E

OpenMP.1E507087_0819_45E0_FF1F_C8B3B9A1E18E

OpenMP.Policy.04B9F3B6_9645_7658_FF1F_C8B3B9A1E18E

These were not specified in the merge module for Crystal 2008 SP0, therefore do you know if these are specific to distributing the SP1 runtime, or were they just ommited from the SP0 package? Also do you know if any one Microsoft technology deployment will provide all these on target machines (e.g. .net1.1 framework etc), as these dependencies appear to make it more complex to distribute the SP1 runtime and guarantee successfull implementation.

Thanks,

Peter.

[Former Member · Accepted solution]

To update this thread, we have had an issue deploying the SP1 runtime on customer site on Windows Server 2003 where the install failed with error 1904 failing to register CEReportSource.dll. I can see this .dll has dependencies on ATL.dll, MSVCP80.dll and MSVCR80.dll amongst others. We have resolved the problem by providing the following technologies in the setup package:

Visual C++ 8.0 ATL (x86)

Visual C++ 8.0 ATL.Policy (x86)

Visual C++ 8.0 CRT (x86)

Visual C++ 8.0 CRT.Policy (x86)

Visual C++ 8.0 MFC (x86)

Visual C++ 8.0 MFC.Policy (x86)

Visual C++ 8.0 MFCLOC (x86)

Visual C++ 8.0 MFCLOC.Policy (x86)

Visual C++ 8.0 OpenMP (x86)

Visual C++ 8.0 OpenMP.Policy (x86)

Therefore I'll assume these technologies are specific to distributing the SP1 runtime, and were not just ommited from the SP0 runtime package.

However I have a further question on this, with regard 64-bit machines both x64 and ia64. Different versions of these .dll's are available for these 2 different 64-bit systems, but does anybody know if these are required in any circumstances for the Crystal SP1 runtime? On one of our x64 machines the Crystal SP1 runtime seems to have deployed as a 32-bit application, is this always the case or will the x64 and ia64 technologies above ever be needed for the Crystal runtime to be installed on 64-bit machines?

[former_member183750 · Accepted solution]

The only two versions of Crystal Reports that have 64 bit runtime are 10.2 (bundles with .NET 2005) and 10.5 (bundles with .NET 2008). No stand alone version of CR has 64 bit runtime, that includes CR 9.2, 10.0, 11.0 11.5 and 12.0.

See this wiki for more details:

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/bobj/crystalReports2008

Ludek

[former_member11696 · Accepted solution]

Also, you can run 32 CR applications on 64 bit OS's but all connectivity and WEB servers must also be in 32 modes.

1904 is a Microsoft Installer error and usually indicates it's having problems registering COM components. This is a permission or dependency and sometimes the version of MS installer needs to be updated.

The quick fix is to copy all the file names that will not register and manually register them using regsvr32.exe

Thank you

[former_member208657 · Accepted solution]

I'd like to add some info to this post. When adding the Microsoft VC80 merge modules to your setup package you'll need to make sure you have Service Pack 1 installed for Visual Studio 2003 or 2005. The VC80 merge modules were updated since the original release of Visual Studio and only the newest ones will work.

This is not well documented and I'm talking with the product managers to improve the documentation included with the merge modules for Crystal Reports 2008 SP1.

[Former Member · Accepted solution]

Hi,

Thanks for everybody's contribution with this.

With regard the VC80 merge modules and SP1 for Visual Studio, do you know the exact version of the merge modules that should be used? We use InstallShield to build the setup packages and not Visual Studio, I'm using v8.0.50727.762 of the merge modules. Do you know if this is the correct version (this version has resolved the issue on-site)?

Peter.

[former_member208657 · Accepted solution]

Peter,

Version 8.0.50727.762 is correct for ATL, MFCLOC, MFC, and OpenMP. But, CRT should be 8.0.50727.1433. Unfortunately I don't think there is a way to check this before you use the merge modules. The unique identifier doesn't seem to update in the merge module properties from original release to SP1.

- Microsoft_VC80_ATL_x86.msm; version 8.0.50727.762

- Microsoft_VC80_CRT_x86.msm version 8.0.50727.1433

- Microsoft_VC80_MFCLOC_x86.msm; version 8.0.50727.762

- Microsoft_VC80_MFC_x86.msm; version 8.0.50727.762

- Microsoft_VC80_OpenMP_x86.msm; version 8.0.50727.762

[Former Member · Accepted solution]

Thanks for everybody's help with this, seems to be working fine on-site now.

Noted that a few machines have required display drivers to be updated (blank reports / reports hanging), but once this is done the reports are working OK.

[former_member208657 · Accepted solution]

Just a little more information on this issue.

You can download the Visual C++ 2005 SP1 Redistributable Package from Microsoft's site below. You'll need this regardless of what version of Visual Studio you are using (2003, 2005, or 2008). Some installer programs can probably integrate this package into your own setup.

We are still working on improving the documentation for this issue.

http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displa...

[Former Member · Accepted solution]

Has anyone found a solution to this problem?

I have added the Crystal 2008 and the Visual C++ Merge Modules. The install completes without error but when you try

to print a report you get "Error Failed to Load Database".

The only way around this that I have found is

to remove the Visual C++ Merge Modules and install

vsredist_x86.exe as a prerequisite. (I am using

Wise Install Studio.)

Any other solutions?

[former_member208657 · Accepted solution]

Installing the vsredist_x86.exe is the best solution for most people because we can't guarantee that all users will have access to the C++ merge modules from Visual Studio .NET 2005 SP1.

[Former Member · Accepted solution]

I have installed CR 2008 SP1 and added the CR merge module to InstallShield 2009. I added the VS 2008 C++ merge modules. But the installer build still fails with the following errors. All the dependency identifiers match so I am at a loss why the build fails. I tried to run the setup anyway but the CR modules failed to register.

I would greatly appreciate any help.

David Torgerson

Luminex Corporation

ISDEV : error -4072: Error retrieving dependency ATL.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency ATL.Policy.66332652_9C28_58B1_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency CRT.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency CRT.Policy.63E949F6_03BC_5C40_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency MFC.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency MFC.Policy.68B7C6D9_1DF2_54C1_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency MFCLOC.74FD3CE6_2A8D_0E9C_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency MFCLOC.Policy.D2730D3F_3C41_5884_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency OpenMP.1E507087_0819_45E0_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

ISDEV : error -4072: Error retrieving dependency OpenMP.Policy.04B9F3B6_9645_7658_FF1F_C8B3B9A1E18E:1033 of c:\program files\common files\merge modules\CRRuntime_12_1.msm

[former_member208657 · Accepted solution]

The Visual Studio 2008 C++ merge modules won't work in this case. It absolutely must be the ones from Visual Studio 2005 SP1. If you don't have access to the merge modules you'll need to use the vc_redist package mentioned earlier in this post.

[Former Member · Accepted solution]

There is a bug in InstallShield that can cause this error, see the following link:

http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q108917&s...

Although this documents the error up to InstallShield 11, I get the error using InstallShield 2008, might be the same in InstallShield 2009, would be worth chasing Acresso about this one.

Also there is a good document here that details when to use the Merge Modules, and when / when not to use the VCRedist_ installation:

http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your...

Peter.

[Former Member · Accepted solution]

I do have the VS 2005 SP1 VC++ Redistribution modules. All the GUIDS for the required merge modules match but the build still generates the error. I tried to install the vcredist_x86.exe as a prerequisite and ignore the errors, but the CR objects failed to register.

[former_member208657 · Accepted solution]

What if you simply install the vcredist_x86.exe manually before you install your package? Does that work?

[Former Member · Accepted solution]

I have tryed this but it does not help.

Also using IS2009 and i can not compile the setup with the latest CR2008 (12.1) msm module

so switch back to the 12.0 msm is the only way to compile the setup.

..JL

[Former Member · Accepted solution]

Hi, Jorgen;

I got the following information from support for Install Shield. I tested here, and the build works successfully with SP 1 of our Merge Modules:

The following error that occurs is due to your merge module dependencies. It appears that your dependency specifically requires a language ID for the dependency merge module, but the actual merge module is set to language independent. In other words, each merge module in your project needs to have the same language ID set. Please follow these steps to set a language ID:

1. Open the Merge Module CRRuntime_12_1 in InstallShield or Orca, and check General Information > Module Dependencies

2. Take note of one dependency, for example, Vistual C++ ATL (x86), you will see that "English (US)" is listed in the Language column

3. Open the actual dependency merge module (Microsoft_VC80_ATL_x86.msm) in InstallShield or Orca

4. Navigate to General Information > Module Properties. It will say "Language Independent" in the language field

5. You will need to make a change, either make both merge modules "Language independent", or change the ID of the dependency merge module to a specific language like (English (US).

6. Repeat this step for all merge modules in the project and rebuild the project.

Regards,

Jonathan

[Former Member · Accepted solution]

Further to this I've tested this on my system and amending the Module Dependencies in the the Crystal merge module to "Language Independent" still results in the same errors when using this merge module in InstallShield.

However re-adding exactly the same Visual C++ dependencies to the Crystal merge module (delete and then Select), leaving these set as the default "English (US)", did resolve any errors when using the merge module in InstallShield. I didn't try it the other way round (change C++ merge modules to "English (US)") but presumably this will work.

[Former Member · Accepted solution]

Tnx for this !

I did open the cr msm in IS and removed all the dependent msm modules and add them again.

did set them to language independet for all and saved the cr msm.

opened my project and rebuild it, it worked

..JL

[Former Member · Accepted solution]

I had done all that your wrote in the forum but still have one warning

Warning 1 Unable to find module dependency with signature 'CRRuntime_12_0.7C0C7D58_142B_4283_B9AE_A953E850EC7E'

Can you help me, sorry my english.

Kelvin

[Former Member · Accepted solution]

It sounds like one of your merge modules in your project has a dependency on the CRRuntime_12_0 merge module, but this shouldn't be referenced as these issues relate to the CRRuntime_12_1 merge module?

[Former Member · Accepted solution]

Thank you, I solved the problem, it is something strange but I remove the modules and I add again and the problem was solved.

Thanks for your help

[Former Member · Accepted solution]

<p>Thank you David for your knowledge in this thread - it saved a lot of time. I

just wanted to add some of my findings on this as I have managed to get this

working on Windows 2008 with some small tweaks.</p>

<p><strong>My Build<br />

</strong>VS2005 SP1<br />

Crystal 2008 Merge Modules from SP1 Fix Pack 4 were used in a Pre-Configuration

package to deploy the CrystalReportViewers12 requirements<br />

Windows Server 2008<br />

.Net 2.0</p>

<p><strong>Pre-Requisites Installer to deploy the Merge Modules<br />

</strong>I added the following Merge Modules for C++ as David suggested except I

could not find <strong>Microsoft_VC80_CRT_x86.msm </strong><b>version

8.0.50727.1433</b>, only <strong>Microsoft_VC80_CRT_x86.msm </strong><b>version

8.0.50727.762</b></p>

<p>I added:<br />

- Microsoft_VC80_ATL_x86.msm; <b>version 8.0.50727.762</b><br />

- Microsoft_VC80_CRT_x86.msm <b>version 8.0.50727.762</b><br />

- Microsoft_VC80_MFCLOC_x86.msm; <b>version 8.0.50727.762</b><br />

- Microsoft_VC80_MFC_x86.msm; <b>version 8.0.50727.762</b><br />

- Microsoft_VC80_OpenMP_x86.msm; <b>version 8.0.50727.762</b></p>

<p>I then build and used this package to deploy to Windows XP machines, Windows

2003 Servers without any troubles at all</p>

<p>When I tried it on a Windows 2008 Server it would still fail with the same

error <pre>CEReportSource.dll failed to register. HRESULT -2147010895</pre><br>

<span lang="en-au">I figured that like with the Crystal Merge Modules needing

the C++ Merge Modules, there must be something else missing, so installed the

</span><b>

<a target="_blank" href="http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&amp;displaylang=en">

Visual C++ 2005 SP1 Redistributable Package</a><span lang="en-au"> </span></b>

<span lang="en-au">and then my installer package and the package installed

correctly.</span></p>

<p><span lang="en-au">Once this was finished, I just had to follow the solution

I posted

to get around the bobj javascript error and my application now works on

Windows 2003 and Windows 2008.</span></p>

<p><span lang="en-au">I would however like to know what is missing from the list

of Merge Modules I listed above (perhaps the different version of </span>Microsoft_VC80_CRT_x86.msm<span lang="en-au">

is the problem) so I can avoid using the</span><b> Visual C++ 2005 SP1

Redistributable Package</b></p>

<p><span lang="en-au">Thanks</span></p>

<p>Robin</p>

[Former Member · Accepted solution]

Robin - this is why the merge module option of installing the vc80 assemblies on Windows Server 2008 (and presumably, Vista) generates the registration errors on the CR2008 files:

[http://blogs.msdn.com/astebner/archive/2007/01/09/problems-with-custom-actions-that-depend-on-the-visual-c-8-0-runtime-files-on-windows-vista.aspx]

I'm in the same boat as you - I really want to use the merge modules over the redist installer, but as we don't really have any control over the CR2008 merge module actions, the workarounds in the above blog post aren't really workable.

FYI - I was able to confirm the behavior listed in the article for our installer. After ignoring the CR registration errors during install, I issued a repair and they all registered just fine the 2nd time around (after all the SxS vc80 assemblies had been committed). Not really a viable solution for our customers though...

I should also add, this issue could be avoided by SAP if they did NOT use the Self Registration feature of Windows Installer in the CR2008 merge module (which MS highly discourages for a variety of reasons).

Edited by: BrianTreff on Aug 13, 2009 6:21 PM

[Former Member · Accepted solution]

Thanks Man! Ur a life saver...

[Former Member · Accepted solution]

hi,

sorry for my english written.

Now I am creating build for my appln using install shield 2009. i am new to this one.

I included the CRRuntime_12_2.msm file to install shield. it also depend with some other C++ rumtime files. i have included that dependency files also. i got the error when i creaing a build.

Error retrieving dependency files ATL.{97F81AF1-0E47-DC99-FF1F-C8B3B9A1E18E}

so i removed and added again dependency files in CRRuntime_12_2.msm. after that i have created build sucessfully.

During my installation, i have noticed there will be some folder created "C:\Program Files\Business Objects\Common\4.0\managed". but there is no dll files. its only empty folder.

but when i open the install shield and select the CRRuntime_12_2.msm. there will be many dlls included that msm file like.

CrystalDecisions.CrystalReports.Engine.dll

CrystalDecisions.Enterprise.Framework.dll

...........

..............

can you please tell me anything i missed out?

thanks

Vinoth Chandran

[former_member183750 · Accepted solution]

It may be that nothing got missed out. See if those dlls / assemblies are in the GAC (c:\windows

assembly). If they are, the app shold work just fine

Ludek

Follow us on Twitter http://twitter.com/SAPCRNetSup

[Former Member · Accepted solution]

hi,

Thanks for your Quick and valuable response.

i noticed all dll files are under c:\windows\assembly as mentioned by you.

one more problem is here.

i can install my application in my machine and it the report can be previewed in my machine.

but when i install my application in clean(another) machine (i.e. none of the software is installed on that machine). i got the following error during installing CR2008 runtime.

"

Error: 1935 An error occured during installing assembly 'businessObjects.Licensing.KeycodeDecoder,version="12.0.1100.0",publickeyToken="692FBEA5521E1304",File version="12.1.4.1068",culture="neutral", Please refer to help more information HRESULT:0x8002802F.

i am still finding to resolving this issue.

Thanks

Vinoth

Edited by: vinothchandran on Apr 9, 2010 4:34 PM

[former_member183750 · Accepted solution]

See if any of the suggestions at [this|; thread will help.

Ludek

[Former Member · Accepted solution]

Hi,

I have go through the link mentioned by you and do the same changes.

I have created my build with the latest MSM for CR2008 (CRRuntime_12_2.msm) and VC++ files(version:8.0.50727.762 ).

The build successfully created.

During Install my application in clean machine the same error gets displayed

"Error: 1935 An error occured during installing assembly 'businessObjects.Licensing.KeycodeDecoder,version="12.0.1100.0",publickeyToken="692FBEA5521E1304",File version="12.2.6.567",culture="neutral"

I have did some analysis.

Scenario I:

During installation in a clean machine, After getting the error message ,.NET framework 2.0 is installed and install my appln.

After uninstall my application and install again , there is no error message gets displayed and the report works fine.

Scenario II:

But this time uninstall my application and also uninstall .NET 2.0, then install my build in a clean machine, the same error gets displayed. the problem is .NET FrameWork installed after getting the error.

Can you help about this?.

Thanks

Vinoth

[Former Member · Accepted solution]

Hi ludek,

I want know some clarifiaction regarding CRRuntime_12_2.msm file.

is there .NET Framework 2.0 is already included in the above.MSM file.

Here some stpes:

1. I create a build with the above .MSM file

2. Install a build in a clean machine. During installation. i got a below error , after that it will continue to install .NET Framework 2.0, then the installation complete. but no crystal components are installed.

"Error: 1935 An error occured during installing assembly 'businessObjects.Licensing.KeycodeDecoder,version="12.0.1100.0",publickeyToken="692FBEA5521E1304",File version="12.2.6.567",culture="neutral"

3. But In a clean machine, First Install .NET Frameworrk 2.0, then install the build, the build successfully installed and all the crystal components are properly installed.

i just confused why this error occur in a clean machine

Can you give some information related to including MSM file into Install shield.

Thanks

Vinoth

[former_member183750 · Accepted solution]

is there .NET Framework 2.0 is already included in the above.MSM file.

- no there is not. And we do depend on the framework to be there. Else we will not install.

Ludek

[Former Member · Accepted solution]

Hi Ludek,

so, in clean machine, first install .net framework 2.0 after that install my application. is it correct

if it is correct how do i include .net frame work in install shield

please clarify me?

thanks

vinoth

[former_member183750 · Accepted solution]

Unfortunately I can not say. The framework is from Microsoft, so the question is better posed to MS.

Ludek

[Former Member · Accepted solution]

Hi Ludek,

Many thanks for your help and response.

I solved the problem..

Actually .MSM file depend on .NET Frame work as mentioned by you.

I included to install shield and .NET Frame work is installed (if it is not machine) before installing Crystal runtime components.

now i can able to print the report..

Once again thanks for your needful help

Thanks

Vinoth

[former_member183750 · Accepted solution]

Excellent. Really appreciate you letting me know. At least I have a bit of confidence that it will work - admittedly after more effort than it should...

Happy coding,

Ludek

[Former Member · Accepted solution]

Hi Ludek,

I have a problem with CR2008.

In my machine i installed CR2008 SP1 full build.

After that I open Crystalreport2008 - It will open. Then I created build for my application using install shield. I will add merge modules for CR2008_runtime12.2.msm in Install shield. After creating my application build, i installed my application on the same machine. The Installation gets successfully installed and the report gets previewed in my application successfully.

But that time when i open start-programs-Crystalreport2008 - it gives an error message like

"The procedure entry point ?ddv_MinMaxDoubleText@CSLib300@@YAXPAVCDataExchange@@ABNNN@Z could not be located in the dynamic link library cslibu-3-0.dll".

Why after installing my application , the cr2008 gets affected. please help me.

Thanks

Vinoth

[former_member183750 · Accepted solution]

I am not sure that this issue is related to this whole thread. Please create a new thread. Also, since this appears to involve the CR designer, consider creating a thread in the CR design forum:

Ludek

[Former Member]

And oh yea - the need to Orca correct the language

I did that a lot as well - change 1033 to 0

Thanks to this thread for that tip !!!

[Former Member]

I too was having all kinds of similar problems deploying - just when I thought including Micorosft C++ 2005 was the answer I found on a Vista 64 bit machine that already had C++ 2005 the install would fail

My final solution was to NOT use CR merge modules and instead use the Redistributable

To do this, since I was using Install Shield (IS 2010), I had to build a .PRQ (see below)

For test condition I wasn't sure what registry value to check - but for now - since time was running out - I did the ugly check for a known file

[ProgramFilesFolder]\Business Objects\Common\4.0\crystalreportviewers12\allInOne.js

I also made it optional just in case something went wrong I could have the user skip it, install my app, and then try do something like CR click once install.

My perference (and my boss's) would have been to use a merge module - but that was eating up too much time and was getting me nowhere.

<?xml version="1.0" encoding="UTF-8"?>

<SetupPrereq>

<conditions>

<condition Type="4" Comparison="2" Path="[ProgramFilesFolder]\Business Objects\Common\4.0\crystalreportviewers12" FileName="allInOne.js" ReturnValue=""></condition>

</conditions>

<files>

<file LocalFile="[REPLACE THIS WITH ACTUAL LOCATION]\CRRuntime_12_2_mlb.exe" CheckSum="D0F9B532A9126C5EB49DAE5DF8F6382F" FileSize="0,34727631"></file>

<file LocalFile="[REPLACE THIS WITH ACTUAL LOCATION]\CRRuntime_12_2_mlb.msi" CheckSum="EDAA0BCDDF2A99E8F754BC917D4147BD" FileSize="0,58235392"></file>

</files>

<execute file="CRRuntime_12_2_mlb.msi" requiresmsiengine="1"></execute>

<properties Id="{27F2D126-7C38-44C7-95A2-172BB5D74E49}" Description="Crystal Reports 2008 Runtime SP2"></properties>

<behavior Optional="1"></behavior>

</SetupPrereq>

[Former Member]

Why are you including both of

- CRRuntime_12_2_mlb.exe

- CRRuntime_12_2_mlb.msi

yet only executing

CRRuntime_12_2_mlb.msi?

I have tried running these two files manually and separately from each other. It would appear that both of them are performing the same actions(?), except the .exe version displays an InstallAware dialog at the beginning.

The .exe version is clearly created with InstallAware, but I cannot tell if it was created by importing the .msi file or by recording the differences using PackageAware. If the latter is the case, then my guess would be that the machine used for the recording is not as clean as it ought to be, as this would explain the enormous difference between the sizes of the .exe and .msi files(?)

What is the official word on the difference between using one or the other (including an explanation of the file size difference)?

Is there any documentation for CRRuntime_12_2_mlb.exe?

UPDATE: I ran the (56MB) CR 2008 SP2 .msi installer through InstallAware's PackageAware application on a clean XP SP3 virtual machine and built the resulting InstallAware project. The result was a 32.5MB installer, which was only slightly less than the 34.5MB CRRuntime_12_2_mlb.exe file. I take that as confirmation that the .exe installer was created (somewhat) in this manner(?) The question is: Is this really safe to use for a product of such complexity?

Edited by: Joergen Bech on Aug 27, 2009 5:44 PM

[Former Member]

With regards to the dependencies:

Iu2019ve been using InstallShield Express 2008 & 2010, each giving the same errors.

I looked at CRRuntime_12_1.msm via Orca and within ModuleDependency, each module is defined as having a ModuleLanguage & RequiredLanguage of 1033.

I opened one of the modules, Microsoft_VC80_ATL_x86.msm to find its ModuleComponents has a Language of 0.

I changed each ModuleDependency record in CRRuntime_12_1.msm to have a ModuleLanguage & RequiredLanguage of 0 and saved it.

Now when loading a project in InstallShield and selecting Crystal Reports 2008 Runtime, the dependant Merge Modules are automatically selected:

Visual C++ 8.0 ATL (x86) WinSXS MSM

Visual C++ 8.0 ATL.Policy (x86) WinSXS MSM

Visual C++ 8.0 CRT (x86) WinSXS MSM

Visual C++ 8.0 CRT.Policy (x86) WinSXS MSM

Visual C++ 8.0 MFC (x86) WinSXS MSM

Visual C++ 8.0 MFC.Policy (x86) WinSXS MSM

Visual C++ 8.0 MFCCLOC (x86) WinSXS MSM

Visual C++ 8.0 MFCCLOC.Policy (x86) WinSXS MSM

Visual C++ 8.0 OpenMP (x86) WinSXS MSM

Visual C++ 8.0 OpenMP.Policy (x86) WinSXS MSM

The build compiles without errors and installs fine on XP. This seems the most straightforward workaround to avoid these errors.

The solution seems simple: SAP need to provide a merge module that does not whinge about missing dependencies.

[Former Member]

When using CRRuntime_12_1.msm or CRRuntime_12_2.msm, the Visual Studio deployment project seems to want Microsoft merge modules containing dlls with version 8.0.50727.4053 (e.g. ATL80.dll), yet when running the .msi installer, dlls with the version number 8.0.50727.762 are installed instead. Why the discrepancy between what is required by the CR merge module and what is installed by the CR .msi?

Also: Aaron Stebner's article is more than 2.5 years old. I understand that until recently this issue only affected Windows Vista, but can it really be true that the Crystal Reports merge module is practically useless and if so, has this issue been addressed or documented by the CR team?

[former_member183750]

I do not think that is correct. Both the MSI and MSM have a dependency on the same VC++ libraries. Specifically, these libraries are included in Service Pack 1 for Visual Studio 2005. The MSI includes these C++ dependencies as the MSI is constructed by us and we are allowed (as is anyone else) to add these dependencies to the MSI. We can not, nor can anyone else add the dependencies to the MSM files and thus the VC++ libraries must be added to the deployment via MS MSM files.

In my blog [Building a deployment project with Crystal Reports 2008 (12.1.0.892) SP1|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13427] [original link is broken] [original link is broken] [original link is broken]; I specify the following:

To resolve possible issues during build and deployment of your deployment package, the correct versions of the VC80 merge modules must be included in your project. The correct versions are as follows:

u2022 Microsoft_VC80_ATL_x86.msm; version 8.0.50727.762

u2022 Microsoft_VC80_CRT_x86.msm version 8.0.50727.1433

u2022 Microsoft_VC80_MFCLOC_x86.msm; version 8.0.50727.762

u2022 Microsoft_VC80_MFC_x86.msm; version 8.0.50727.762

u2022 Microsoft_VC80_OpenMP_x86.msm; version 8.0.50727.762

For more information, also see [this|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14789] [original link is broken] [original link is broken] [original link is broken]; blog, post from 17-Jul-09. Look for the links to the notes created by David Hilton.

BTW.; the dependencies were built in for those specific VC++ libraries and will not be removed / modified.

Ludek

[Former Member]

I did some more testing today and would like to issue a partial apology:

When installing VS2005 on a clean machine, you get version 8.0.50727.42 of these modules.

If you then apply service pack 1 to VS2005, you get version 8.0.50727.762.

But: When you subsequently use Microsoft Update (not Windows Update, but Microsoft Update), which includes some security updates for VS2005, you suddenly find version 8.0.50727.4053 of these modules in the Merge Modules folder.

As my deployment project was linking to the merge modules at the default location, I was picking up version 8.0.50727.4053 rather than 8.0.50727.762.

However: In your reply as well as your blog post, you specify version 1433 for one of the merge modules:

- Microsoft_VC80_CRT_x86.msm version 8.0.50727.1433

I have not been able to find a module with that version (neither the module, nor dlls). Is the 1433 version a typo?

I also did (again) a PackageAware capture of CRRuntime_12_2_mlb.msi - this time on a clean XP SP3 with just .Net Framework 1.1 to satisfy the installer. I took care to check the WinSxS folder before and after installation and thereby confirmed that the only Microsoft runtime dlls installed in that folder were version 762. No files with version 1433 here either.

Question 1 (presuming the 1433 is a typo and all merge modules should be 762):

Will it make any difference if I use version 762 instead of 4053 in my installer, i.e. will it solve the registration errors on Windows 2008/Vista/7? Your blog post only says that the registration errors are resolved by including the correct merge modules, but does not mention any of the problems we have seen on newer OS's.

The David Hilton article looks promising, except this is a chained setup, which is usually not a pretty sight (have to try it out), so my second question (which is an extension of the first question) is: Is it or is it not possible to create a non-chained installer using all merge modules (CR + Microsoft) in the deployment project?

[Former Member]

In regards to version 8.0.50727.1433 of the Microsoft_VC80_CRT_x86.msm, I'm right there with you Joergen. I actually downloaded Visual Studio 2005 SP1 from MS again, extracted all the files from the msp and nowhere could I find a copy of Microsoft_VC80_CRT_x86.msm with a version of 8.0.50727.1433. The only version I could find was 8.0.50727.762 (which matches the version of all other VC80 merge modules). I'm not disputing that there's a version 8.0.50727.1433 somewhere, but it is definitely not present in Visual Studio 2005 SP1 and I haven't been able to locate one anywhere else.

[former_member183750]

Looks like the version is a typo and I'll fix that ASAP.

Re. chaining the merge modules. If you are using .NET 2005 and have the MS VC++ merge modules from SP1 for .NET 2005, you do not need to do any fancy stuff. Just add the merge modules to the deployment project along with CR merge module, build your deployment project and that is it. The issue comes up when you use .NET 2008 and don't (and never had) .NET 2005. How are you now going to get the correct merge modules from Microsoft? You can not run SP 1 for .NET 2005 to get the merge modules. You can not download them from any site as MS does not want you to use msm files anymore... and thus David's solution is the only way to go.

Ludek

[Former Member]

ok. Well, as is evident from my post about my virtual machine tests today, I do have the VS2005 SP1 merge modules (though others might be out of luck), but the deployment project in which I need them is indeed a VS2008 one.

I will give the VS2008 + correct merge modules a try, but if I still get the registration error (in 2008/Vista/7), I will try the chained installer approach.

Although: If Microsoft - officially - does not want us to use the msm files in VS2008-created installers, perhaps you should specify that in your blog post as well. I googled the topic, but I could not find any official statement saying that the use of merge modules had been deprecated. The most relevant article I could find about merge modules in the context of VS2008 is this one, which does not discourage their use:

http://msdn.microsoft.com/en-us/library/ms235290.aspx

[Former Member]

I'm sorry, but I still find your blog post and replies ambiguous: You say that "you do not need to do any fancy stuff. Just add the merge modules to the deployment project along with CR merge module, build your deployment project and that is it" and that the problem with VS2008 is that you do not have access to the merge modules. It does not say "It does not work with VS2008, even if you have the merge modules."

I created a VS2008 deployment project with just the CR merge module as well as the 10 correct Microsoft merge modules, entered the key for the CR module and built the installer.

I tested this installer on clean virtual machines (i.e. none of the relevant Microsoft dlls in the WinSxS folder initially) running Windows XP SP3, Vista SP2, 2008 SP2, and 7.

It worked fine on Windows XP SP3. I did not try Windows 2003, but I presume it is fine on that system as well.

It did not work on Windows Vista SP2, 2008 SP2, or 7, which is consistent with Aaron Stebner's article:

http://blogs.msdn.com/astebner/archive/2007/01/09/problems-with-custom-actions-that-depend-on-the-vi...

Just as a last test, I followed your instructions and created a VS2005 deployment project (rather than a VS2008 one) with all the right merge modules and tested the installer in a clean Windows 7 VM: Again, it did not work.

Note: By "clean" virtual machines, I mean freshly installed machines with .Net Framework 3.5 SP1 installed, but no Windows updates applied.

[Former Member]

Joergen - the only way I found to get around this problem was to build a prerequisite windows installer package that contained ONLY the VC80 merge modules. I then had our installation wrapper check for VC80 first, and if not present, install them. After a successful VC80 installation, I then launch our main msi package which contains our application merged with the CR 2008 runtimes. It's not as elegant as having everything in one package, but unfortunately, that just won't work on Vista or Server 2008 due to the reasons outlined in Aaron Stebner's blog.

[Former Member]

I added the VC++ package as a requisite to my installer which - of course - means that I now have another setup.exe + a local (external) copy of the vcredist... file in my installation folder.

I tried messing around with the vcredist... package in order to suppress the user interface, but this caused some problems. I suspect that by suppressing the interface, the user is not presented with some of the necessary OS authorization dialogs and the package just quietly fails. When subsequently the main msi (containing the CR merge module) is run, this then fails as well due to the VC++ runtime dlls not being present for the self-registration process.

So right now I am just letting it display all the dialogs it wants - warts and all. I cannot spend any more time on this right now, so this will have to do until I find a viable workaround or the CR people come up with a solution that works on 2008/Vista/7.

[Former Member]

I wouldn't recommend using the vcredist installer because it doesn't reference count the libraries that it installs (while the merge modules do). In my case, I just packed up the actual VC80 merge modules into a bare bones windows installer package and made that my prereq (not the actual vcredist installer that you can get from MS). This method has the added benefit of being able to control the user interface using standard windows installer cmdline options.

[Former Member]

Right. I was using David Hilton's example, which included a bootstrapper package for vcredist (minus the vcredist exe itself, which had to be supplied separately).

Did you create the product.xml and package.xml files by hand after creating the msi package with the MS merge modules?

[Former Member]

Neither - I probably should have mentioned that I'm using Wise Installation Studio to build all of my MSIs and built a custom bootstrapper for my project.

[former_member183750]

Re. Vista and WIN 7.

I would have thought that the merge modules from VS .NET 2005 SP1 would work in any setup project run on any supported version of Windows. Whether it be Windows XP, Vista or 7.

But admittedly, this was before you provided this link:

http://blogs.msdn.com/astebner/archive/2007/01/09/problems-with-custom-actions-that-depend-on-the-vi...

Sounds like we need to do some testing with Vista and Windows 7, but going by the above blog, I think we do have the answer. Unfortunately it's not easy to believe (at least for me anyhow). E.g;

There is a tricky issue with the VC 8.0 runtime files that only affects Windows Vista and later versions of Windows and is does not appear to be well documented yet. Specifically, on Windows Vista and later, the VC 8.0 runtime files are installed to the WinSxS cache as global assemblies, whereas on downlevel platforms such as Windows XP or Windows Server 2003, the VC 8.0 runtime files are installed using standard Windows Installer file table entries.

The problem has always been that clients using Visual Studio .NET 2008 could not get their hands on the merge modules (.msm) files from VS 2005 SP1. Microsoft simply doesn't provide them as a single download.

The VCRedist package for the C++ libraries was the only way VS 2008 customers could get the correct C++ library files. As far as I know this can be installed ahead of time on any OS then you can install the setup package built with the merge modules.

Ludek

[Former Member]

Hi,

What is the latest ETA on these being available to download?

Thanks in advance!

[former_member11696]

Hi Peter,

They are available on our internal share and I am working with the Team responsible for posting them to our support site. I expect it should be there possibly by tomorrow and if not then early next week.

Thank you

Don

[Former Member]

Thanks for the prompt response, can you update this thread so I can download them ASAP - we have a software release due very soon.