Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Visual Studio
  4. Installer woes

Installer woes

Scheduled Pinned Locked Moved Visual Studio
csharpvisual-studiosysadminwindows-admintools
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Arun Bhalla
    wrote on last edited by
    #1

    I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1. My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems. 1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch,

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups