locked
how to fix msi files errors RRS feed

  • Question

  • Hi,

    I have an installer project in VS2010 that creates my msi file. I also create a dll and use functions from that dll as custom actions. In that dll function, I call MsiGetTargetPath. For some reason, that function always return me an invalid handle error (the same handle works in other msi functions). That really is my problem. I'd rather fix it here, but if not possible, I figured using orca that function has a type 3089, which I don't know what it means. But looking on the web, I noticed the type for a dll function should be 17. And magically, when I set it to 17, it starts to work.

    But here is the thing. Because of that bug, I learned how to use Orca, I learned to make transform files. But I can't find a way to automatically apply my transform when I build the msi file. I was thinking of applying the transform file as a post build step, but I can't find, if possible, how to apply an mst file to a msi file using a command line. And I definitely don't want a manual step in the way everytime I modify my installer. 

    How can I fix this, anywhere along the path of issues?

    Thanks,

    Vincent

    Wednesday, October 26, 2011 1:18 AM

Answers

  • But looking on the web, I noticed the type for a dll function should be 17.

    Not really. DLL custom actions support two types: 1 when stored in Binary table and 17 when installed by the package. So setting it to 17 is not the solution.

    When you set the type to 17 you basically removed the msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate flags: http://msdn.microsoft.com/en-us/library/windows/desktop/aa368069(v=vs.85).aspx

    This works because MsiGetTargetPath cannot be used from within deferred custom actions. A correct solution would be to set the type to 1 instead of 17.

    But I can't find a way to automatically apply my transform when I build the msi file. 

    Transforms are applied dynamically during install. Applying them at build time is redundant. Why not include the transform changes directly into the MSI? If you are trying to do something not supported by Visual Studio a better solution is to use a different setup authoring tool which supports what you need.


    Cosmin Pirvu
    My blog | Contact me
    Please remember to mark the replies as answers if they help.
    • Marked as answer by Neddy Ren Wednesday, November 2, 2011 2:31 AM
    Wednesday, October 26, 2011 6:45 AM
  • It's not clear to me what you're doing. In general, transforms get applied at install time. If you just want to change your MSI file with a post-build step, well that doesn't need a transform, that just needs a post-build action that uses something like WiRunSql.vbs (in Windows SDK) with a SQL that changes the MSI file. Also, that has nothing to do with MsiGetTargetPath, so why look at that?

    Just changing the custom action type to 1 msy not help. All Visual Studio custom actions are deferred and that means they are typically based on the fact that the Dll is installed. If you mark it as Exclude, then it will be in the Binary table in the MSI file, and that will be ok as long as the Dll doesn't have any dependencies that haven't yet been installed.


    Phil Wilson
    • Proposed as answer by Neddy Ren Monday, October 31, 2011 5:32 AM
    • Marked as answer by Neddy Ren Wednesday, November 2, 2011 2:31 AM
    Wednesday, October 26, 2011 8:07 PM

All replies

  • But looking on the web, I noticed the type for a dll function should be 17.

    Not really. DLL custom actions support two types: 1 when stored in Binary table and 17 when installed by the package. So setting it to 17 is not the solution.

    When you set the type to 17 you basically removed the msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate flags: http://msdn.microsoft.com/en-us/library/windows/desktop/aa368069(v=vs.85).aspx

    This works because MsiGetTargetPath cannot be used from within deferred custom actions. A correct solution would be to set the type to 1 instead of 17.

    But I can't find a way to automatically apply my transform when I build the msi file. 

    Transforms are applied dynamically during install. Applying them at build time is redundant. Why not include the transform changes directly into the MSI? If you are trying to do something not supported by Visual Studio a better solution is to use a different setup authoring tool which supports what you need.


    Cosmin Pirvu
    My blog | Contact me
    Please remember to mark the replies as answers if they help.
    • Marked as answer by Neddy Ren Wednesday, November 2, 2011 2:31 AM
    Wednesday, October 26, 2011 6:45 AM
  • It's nice to have knowledgeable people around :) Type 1 it is then.

    I definitely agree I want to change the type in Visual Studio instead of doing anything funky. But can I? I've been looking all around to no help. I thought all parameters where in the properties, but I don't see anything to change there.

    Thanks.

    Wednesday, October 26, 2011 4:13 PM
  • It's not clear to me what you're doing. In general, transforms get applied at install time. If you just want to change your MSI file with a post-build step, well that doesn't need a transform, that just needs a post-build action that uses something like WiRunSql.vbs (in Windows SDK) with a SQL that changes the MSI file. Also, that has nothing to do with MsiGetTargetPath, so why look at that?

    Just changing the custom action type to 1 msy not help. All Visual Studio custom actions are deferred and that means they are typically based on the fact that the Dll is installed. If you mark it as Exclude, then it will be in the Binary table in the MSI file, and that will be ok as long as the Dll doesn't have any dependencies that haven't yet been installed.


    Phil Wilson
    • Proposed as answer by Neddy Ren Monday, October 31, 2011 5:32 AM
    • Marked as answer by Neddy Ren Wednesday, November 2, 2011 2:31 AM
    Wednesday, October 26, 2011 8:07 PM