none
Problem with ICE30 if 64-bit GAC assembly has same name as 32-bit GAC assembly RRS feed

  • Question

  • Hi,

     

    I have question related to ICE30. My installation package currently fails on this test with the following error:

    ICE30 ERROR Installation of a conditionalized component would cause the target file 'assembly.dll' to be installed in '[TARGETDIR]\' by two different components on an LFN system: 'assembly.dll' and 'assembly47'. This would break component reference counting.

     

    I do think however that my setup is correct. Here's how it's configured:

    Our application depends on some third party components (which I called assembly.dll) which has two versions: one for 32-bit and one for 64-bit. Both third-party assemblies have the same name and both files are installed only in the GAC by our installation package.

     

    So strictly speaking, the ICE30 test is accurate because the Directory column in the Component table for both components contain GAC, but in reality the test is inaccurate because during installation the 32-bit assembly will be installed in the 32-bit GAC and the 64-bit assembly will be installed in the 64-bit GAC which are two different directories and should therefore not break reference counting.

     

    I was wondering if I really have to fix this test, and if so, how I can do it, because I would tend to believe that my current approach is accurate.

     

    Regards,

    Michael

     

    Wednesday, November 14, 2007 10:55 AM

Answers

  • Hi Michael,

     

    Thanks for this detail and due apology for the delay in update. Actually it was being discussed off line.

     

    But now seeing the details, it seems you need not to worry here. This is because, the particular error on ICE 30 (FAIL API Function Error: StringCchCat) can be ignored because this is because of an error in ORCA. Also, we are concerned with ICE errors only, you can ignore the warnings.

     

    Hope it helps.

     

    Thanks.

    Monday, November 26, 2007 5:23 PM

All replies

  • Hello Michael,

     

    As you might have seen that, ICE30 goes to every component in the Component table and then determines the component's target directory from the Directory table. It then checks to see which of these components install to the same target directory. Finally, it uses the File table to verify that none of the files in these components have the same name.

     

    However, you need to set the attribute in the Component Table to mark installation packages that include both 32-bit and 64-bit components:

    msidbComponentAttributes64bit

    256

    0x0100

    Set this bit to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component.

    If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the ComponentId column.

    See the Component Table MSDN page: http://msdn2.microsoft.com/en-us/library/aa368007.aspx

     

    Hope this helps. However, there might be other solution/way-around applicable in your situation like storing the components in other folders if feasible.

     

    Thanks.

     

    Friday, November 16, 2007 9:51 AM
  •  

    Hi,

     

    Thank you very much for your feedback. I can confirm that this attribute is set to for all 64-bit components, but nonetheless ICE30 is still complaining that they will be installed in the same directory. Could it be that this test ignores this attribute and simply takes the Directory into consideration?

     

    Concerning the alternative you suggested. Storing the components in other folders is not really an option because they really need to be in the GAC.

     

    FWIW. Here are two rows from my Components table of an assembly that fails the ICE30 test. One row is for the 32-bit assembly, the other is for the 64-bit assembly.

     

    "Assembly.dll","{1DFC6549-58B0-410C-9C7F-1FF8A08AEC9B}","GAC","256","(VersionNT64)","Assembly.dll","Global Assembly Cache"
    "Assembly.dll14","{81AEEA95-3A6B-428A-B10E-A5CAD4A49744}","GAC","0","","Assembly.dll14","Global Assembly Cache"

    Any other ideas would be appreciated,

    Michael

     

    Sunday, November 18, 2007 5:43 PM
  •  

    Hi,

     

    Wondering if anybody can help here, because I'm still stuck with this issue. I have tried circumventing the problem by defining mutually exclusive conditions on both components, but to little avail. The errors have turned in the warnings, which (I assume) would be sufficient for the ICE30 test if the test itself wouldn't have failed with an API Function Error.

     

    I now get:

    ICE30 WARNING The target file 'Assembly.dll|Assembly.dll' might be installed in '[TARGETDIR]\' by two different conditionalized components on an LFN system: 'Assembly.dll' and 'Assembly.dll29'. If the conditions are not mutually exclusive, this will break the component reference counting system.
    ICE30 WARNING The target file 'Assembly.dll|Assembly.dll' might be installed in '[TARGETDIR]\' by two different conditionalized components on an LFN system: 'Assembly.dll' and 'Assembly.dll29'. If the conditions are not mutually exclusive, this will break the component reference counting system.
    ICE30 FAIL API Function Error: StringCchCat. Error Code: -2147024774

     

    The ICE30 FAIL-line is now giving me some problems. Anybody have an idea?

     

    Thanks,

    Michael

    Monday, November 26, 2007 2:19 PM
  • Hi Michael,

     

    Thanks for this detail and due apology for the delay in update. Actually it was being discussed off line.

     

    But now seeing the details, it seems you need not to worry here. This is because, the particular error on ICE 30 (FAIL API Function Error: StringCchCat) can be ignored because this is because of an error in ORCA. Also, we are concerned with ICE errors only, you can ignore the warnings.

     

    Hope it helps.

     

    Thanks.

    Monday, November 26, 2007 5:23 PM
  •  

    This is great news, thanks. It helps me further for sure.

     

    I do have to say though that I consider definining the mutually exclusive conditions on the components to be a workaround because we really want to install the 32-bit and 64-bit assemblies in the GAC on a 64-bit server.

     

    This is because part of our application is a class library and we want people to be able to use our class libraries from within a 64-bit process as well as from within a 32-bit WOW process. So the situation is that I really need the 32-bit assembly to be installed in the 32-bit GAC and I really need a same-named 64-bit assembly to be installed in the 64-bit GAC. This is still my prefered setup and I was hoping that ICE30 wouldn't fail over this. Can you comment on that as well please?

     

    Michael

    Tuesday, November 27, 2007 7:51 AM
  • You can definitely keep these as documentation for the ICE warning to provide later if required.

     

    Thanks.

    Wednesday, November 28, 2007 1:00 PM