none
What is the best way to determine how to install

    General discussion

  • I have a small product with a very simple installation, but it has a 32 bit version and a 64 bit version and the product may or may not already be installed, so I also need to handle updates. MSI gets complicated very quickly when you get into updates.

    What is the best way to detect the installation environment and make decisions what and how to install? Can this be done entirely within a Visual Studio Setup and Deployment project?

    More specifically...

    I can create an Setup and Deployment project in Visual Studio with proper Upgrade Code, Product Code and Package Code that will create an MSI file that will work for new or update installs. I can setup separate projects for 32 and 64 bit product versions to make separate MSI files for each version. I can put both install trees on the same CD each in their own folder. I can then create my own setup.exe project that makes various checks and creates and execs an MSIEXEC command with the right options for that system including REINSTALL and other preferred options to tell it to perform an update and that calls the correct MSI file path for that system configuration.

    Is that the best way to accomplish this?

    How do I detect my installed product to exactly match what the MSI will check? I can look for my registry settings or files, but I want to avoid the possibility of the MSI checking somewhere else in odd situations, so I want to check the same way in my setup.exe.

    Edit: I'm currently using Visual Studio 2005.

    Thanks

    Phil

    • Edited by cadcamphil Wednesday, December 15, 2010 7:10 PM Add info
    • Changed type Aspen VJ Wednesday, December 22, 2010 1:02 AM
    Wednesday, December 15, 2010 7:09 PM

All replies

  • That's all possible with Visual Studiop setup projects except that:

    1. You don't use a setup.exe because the setup will create one.

    2. Visual Studio supports RemovePreviousVersions as an update, not msiexec with REINSTALL commands, so you don't need anything special.


    Phil Wilson
    Wednesday, December 15, 2010 10:37 PM
  • Thanks Phil (Good name :-)

    The only reason I propose writing my own setup.exe is to control the MSI commands when the setup.exe produced by Visual Studio does not handle all that I want it to. If it can handle it all within the project, I'll be thrilled.

    But I have Visual Studio 2005 and I have not seen any features to handle upgrades. Is it as simple as updating the Product Code and Package Code (keeping the same Upgrade Code) and building the new installer?

    Are there any major differences in support for upgrades in VS 2008 (or later) versus 2005?

    Is there a good how to guide somewhere for creating an installer using Visual Studio that can handle upgrades and new installs?

    One of my biggest complaints about Visual Studio is that I can't find any help for Visual Studio itself, whereas there is lots of help for the underlying technologies like raw MSI.

    Phil

    Thursday, December 16, 2010 11:14 PM
  • Setup & Deployment packages do not support automatic updates. ClickOnce deployment does. Here is some info about that:

    ClickOnce Overview

    http://msdn.microsoft.com/en-us/library/142dbbz4(VS.90).aspx

     

    HowTo publish a clickonce app   

    http://msdn2.microsoft.com/en-us/library/31kztyey(VS.80).aspx   

    http://msdn.microsoft.com/en-us/library/31kztyey.aspx  (vs2010)

    I don't understand your complaint that you can't find any help for Visual Studio? I just bing'ed Visual Studio 2010 and found this:

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

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    Friday, December 17, 2010 8:23 AM
  • Hi Robin,

    Thanks for the links and info, but I still haven't quite found what I want.

    Reading about Click Once, I like the update handling, but our application is a standalone application that we prefer not to install from the web or from a network share.

    Reading about 32 vs 64 bit, it appears they are best handled as separate MSI installer projects.

    This leads me right back to my first post:

    Phil Wilson said: "2. Visual Studio supports RemovePreviousVersions as an update, not msiexec with REINSTALL commands, so you don't need anything special."

    Then Robin said: "Setup & Deployment packages do not support automatic updates."

    How do these responses align?

    It still looks like if I want a single installler CD/DVD that can install a 32 or 64 bit product as a new or update install, then I have to write my own executable to detect the environment and exec MSIEXEC referring to the right MSI file with the options I want.

     

     

    So my questions still remain:

    Is there a better solution than this (considering I'm not using Click Once)?

    How do I detect an installed product exactly as the MSI will detect it to prevent awkward error conditions?

     

    Regarding my complaint about help on Visual Studio, you made me think about my specific difficulties to clarify them. My primary frustration is that Visual Studio (2005) Help does not have an easy way to adequately focus my search to a specific technology or user interface. If I'm programming in C++ and want to determine code to accomplish something, it will give me topics ranging from SQL Server to Visual Basic to Office to the kitchen sink even if I tell it to filter on C++. Similarly, if I go to help for a deployment project, it finds many help pages for MSI tables and other technologies, but it is difficult to find any help how to edit particular settings or work with the Visual Studio user interface.

    Your link is a good start and I had not found it before, probably because I searched for more specific topics and found too many other hits. I'll have to look at it more carefully and I like the large number of How To topics. But even following these links I was not able to find what I wanted reasonably quickly. It looks good, but it appears to be more like training materials than help with a specific task or user interface within Visual Studio, so it's easy to get lost or overwhelmed trying to find a specific solution. Which is why I sought out this forum.

    Thanks

    Phil

    Friday, December 17, 2010 7:44 PM
  • Hi cadcampjil,

    >Phil Wilson said: "2. Visual Studio supports RemovePreviousVersions as an update, not msiexec with REINSTALL commands, so you don't need anything special."

    >Then Robin said: "Setup & Deployment packages do not support automatic updates."

    >How do these responses align?

    Base on my understanding, I think the both saying is correct. The Phil's reply mean that when you install the app whick has existed in your computer, it will remove the provious version and install the new version when you set the RemovePreviousVersion to true.

    In c#, there are only two deployment strategies, clickonce and setup project. None of them is perfect but each has advantages.

    Here is a link which declare the two deployments in general. You can refer to it and choose the one you feel good for you.

    http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/407b0fad-dbbd-428f-ac0c-b6bc581b8620#x_FAQAnswer11 

    Have a good time.

    Sincerely,

    Vin Jin


    Vin Jin [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, December 21, 2010 3:29 AM
  • Thanks for all the responses. I think at this point, I have to do my due diligence and do several experiments.

    I need to install from CD, not over the network or similar administrative install, so I'm ruling out Click Once.

    I see how RemovePreviousVersions works at a high level, but I need to work out the details regarding what files are uninstalled to make sure I don't lose user customizations. As long as I can control all the options for over-writing files, etc, I see that I should be able to handle the new install vs upgrade within the Visual Studio project.

    I don't at this point see a simple way to check if a system is 64 bit or 32 bit in order to select the files to install (or any similar pre-install decision) within Visual Studio.

    So my decision is still between:

    A. A custom EXE that checks pre-conditions and forms an MSIEXEC call with the options I want including setting any MSI property, with separate installs and MSI files for any specific configuration (e.g. 32 bit vs 64 bit).

    B. An all-in-one deployment project that can handle all the pre-decisions. For example, I could write an EXE that I can run as a custom action, use it to set an MSI property and put a file condition on each 64 bit or 32 bit specific file and that may be enough to accomplish what I want.

    C. Some other solution that I'm not aware of at the moment.

     

    Right now I'm still leaning toward (A) for the following reasons:

    1. I can keep the 32 bit and 64 bit builds and MSI projects separate and still distribute on one CD.

    2. I can keep the tree structure on the CD much simpler because I can have separate folders for 32 bit and 64 bit installs each with their own MSI without having to move files.

    3. I can have full control of all MSI properties and the behavior they define if I want to dictate a particular behavior easily from MSIEXEC parameters.

     

    I'll post the results and conclusions from my experiments after the holidays.

    Phil

    Tuesday, December 21, 2010 7:20 PM
  • Hi cadcamphil,

    Thank you for responsing.

    I change this type of thread to the "General Discussing", as I think that more community members can participate in the discussing and help you to find a good solution as you want.

    Thank you for understanding and supporting.

    Sincerely,

    Vin Jin

     


    Vin Jin [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, December 22, 2010 1:05 AM