Click here to monitor SSC
  • Av rating:
  • Total votes: 229
  • Total comments: 49
Phil Wilson

Updates to setup projects

18 July 2005

Third in a series on Visual Studio setup

This article explains how to install a new version of your setup project using the Windows Installer update mechanism.

Introduction

When you need to build a new version of your setup project or ship fixes to it, it’s tempting to rebuild the project and try to install the MSI file. Doing so, however, typically launches a message box indicating that another version of the product is already installed and directing you to the control panel to uninstall it.

The primary reason for this is that the ProductCode Guid identifies the product to Windows (see the setup project properties in Figure 1). Since you have already installed the product identified by that Guid, you must use a Windows Installer update mechanism to install a new version of your product.

Figure 1

How to update your product

Visual Studio supports the RemovePreviousVersions project property mechanism in its IDE. Figure 1 shows that the value is false. When you’re ready to build a new version of your product to replace an older one, follow these steps:

  • Increment the version property (see Figure 1). Visual Studio displays a message box that prompts you to change the ProductCode and PackageCode. Select yes.
  • Set the RemovePreviousVersions property to true.

Setting the RemovePreviousVersions property to true removes previous versions of the product from the system as you install the new version. Since products are identified by the ProductCode Guid, changing the ProductCode creates a new product. That is, the old product is uninstalled as you install a new one. Note that the version property, which becomes the Windows Installer ProductVersion property, is a key piece of data that relates to updating your product. It is not simply a descriptive string.

Figure 1 also shows a DetectNewerInstalledVersion property that checks, at install time, to see that you’re not trying to upgrade an existing installed version with an older version.

Before describing how RemovePreviousVersions works, I’ll explain how PackageCode and ProductCode interact.

PackageCode, ProductCode and repair

The PackageCode is a Guid that uniquely identifies the MSI file from which a product was installed. When you install an MSI file, the PackageCode and ProductCode are recorded on the system. When you attempt to install another MSI file, the PackageCode and ProductCode interact in two ways:

  • If the new MSI file has the same ProductCode and PackageCode as a product that’s already installed, Windows indicates that you must repair or remove the product (see Figure 2) Remove uninstalls the product, but repair can be more confusing.

    Repair does not use your new MSI file to repair the product, nor does it update what you previously installed. Instead, it repairs the existing installed product. That is, it behaves as if you went to the original MSI file used to install the existing product, selected the context menu, and chose repair. (Note: Repair can also be initiated from Add/Remove programs.)
  • If the new MSI file has the same ProductCode as an installed product but a different PackageCode, you’ll receive a message indicating that another version of the product is already installed.

You cannot set the PackageCode property (Figure 1). Instead, Visual Studio generates a new one when required.

Figure 2

When a product is installed, Windows caches a copy of the MSI file in the Windows\installer folder and records the location from which the MSI was originally installed. The cached MSI file contains the data from the original MSI file but does not contain the actual files, so it can be used to check that the product is installed properly. If there are any missing files, Windows will go to the recorded install location to retrieve the installation MSI file. If a repair is triggered, Windows may ask for the original CD or network location.

The product upgrade

Another Guid, the UpgradeCode, recognizes that a previous version is installed (see Figure 1). When RemovePreviousVersions is set to true, Visual Studio builds an MSI file that checks for other installed products with the same UpgradeCode and uninstalls them. This is known as a Windows Installer major upgrade.

The upgrade uninstalls the older product and then installs the new one, so everything that was installed in the older version will be uninstalled. It does not update files with newer versions. If data files were installed that the user may have updated, they will be uninstalled.

You may need to take this behavior into account when you build the first version of your installation package. It may be better to have your application produce data files at run time, for example, rather than adding them to the setup. This ensures that RemovePreviousVersions will not uninstall them, and they will carry over into the next version of the product.

Everyone or just me?

At install time, the dialog box in which you choose the installation folder is also where you set the "Everyone" or "Just me" radio-button choices (see Figure 3). In Windows Installer terms, it’s a choice between a per-machine install (for all users of the system) or a per-user install (for the installing user). An Everyone install does not upgrade a Just me install, and vice versa.

Figure 3

There is no way to preset the Everyone/Just me setting in Visual Studio 2003’s IDE. Figure 4 shows the properties of a setup project in the Beta 1 version of Visual Studio 2005. Note that there is an InstallAllUsers property to set the default behavior.

Figure 4

Be mindful of the issues

The internal logic that uses UpgradeCode to search for other versions of the product allows a range of version values to be used. A tool called Orca in the Windows Installer section of the Platform SDK can be used to view and edit MSI files. More on this later.

Figure 5shows the values in the Upgrade table in the MSI file. The VersionMin and VersionMax values show the range of values for which to search, but Visual Studio does not allow you to specify this version range, which starts at 1.0.0. If you are partial to versions before 1.0—0.5, for example—your RemovePreviousVersions will fail.

Figure 5

Recall that a Just me install will not upgrade an Everyone install. In Visual Studio .NET, the internal search for a matching UpgradeCode occurs before the per-machine/per-user value is resolved. In Visual Studio setups the default install is per user, so a RemovePreviousVersions upgrade will not upgrade an Everyone per-machine install because it is still in the default per-user mode when it searches for the previously installed versions. Visual Studio 2003 does not have this issue.

Custom actions in RemovePreviousVersions upgrades may also give unexpected results. In a Windows Installer major upgrade, custom actions are called in the same process space.

Let’s walk through the scenario with a DLL, including .NET assemblies. The first custom action called will be the uninstall custom action from the older, already installed version. Windows loads the associated DLL and calls the custom action. Later, the install custom action from the new product is called. If this DLL has the same name as the DLL in the older product, Windows assumes that the DLL is loaded and it will not load the version of the DLL from your new setup.

This has some interesting effects. The install method from your old custom-action DLL is called instead of the one from the DLL in the new setup. Similar problems have been reported with COM DLLs. So although it might be awkward, I recommend that you change the name of your DLL in these cases. See http://support.microsoft.com/default.aspx?scid=kb;en-us;555184 for additional information.

Other types of updates

Products can be updated using Windows Installer patches, or MSP files. The main advantage of such patches is that they are small. The patches function as a delta between one version of an MSI file and another—the difference between the MSI tables—and new versions of the updated files. In the optimizations that produce the smallest patches, the patches contain binary patches to individual files. In cases that are less optimized for size, patches contain the entire file that has changed.

Patches can be built using PCP files, described in the Windows Installer SDK documentation. I don’t recommend that you build patches based on setups that were generated by Visual Studio setups, however, because you don’t have enough control over the way Visual Studio generates MSI files. In particular, the generation of patches is sensitive to the name of the internal CAB file and associated streams embedded in the MSI file. A mismatch between old and new versions will give you error 2356 when you apply the patch.

Expert mode

The great thing about Visual Studio setup projects is that they isolate you from the complexities of Windows Installer: You don’t need to worry about what’s going on internally. There are other tools that enable you to control more of the internals of MSI setups and give you the proverbial rope with which to hang yourself (see http://installsite.org/pages/en/msi/authoring.htm for a good summary).

The reason that setup programs require extra care in design and implementation is best illustrated by comparing them with other programs. A typical application program processes input data and produces some result for consumption by humans or other programs. If it breaks, you replace it on the system by putting a new copy out there.

An installation program isn’t like that. It makes changes to the system, many of which are in sensitive areas such as the Windows registry. Once those changes have occurred, it’s too late to replace the setup program with a new one because the changes, and the damage they may have done, are already on the system.

Perhaps the closest analogy to a setup program is an application program that updates a critical database. If the program breaks, the database is corrupted and you need to restore a previous version of the database or find a way to undo the damage.

If you want to learn more about what goes on inside MSI files, take a look at a tool called Orca from the Windows Installer section of the Platform SDK. If you install from Orca.msi in the \bin folder, you will see the tables and their contents in the MSI file.

I use the word tables because the MSI file is a database, and the tables and their uses are documented in the Platform SDK. MSI files are transparent—you can see everything except for the content of binary files used in the custom actions that Visual Studio generates. To see what happens, take a look at the InstallExecuteSequence table of an MSI file in conjunction with a log from installing that MSI file with this type of command line:

Msiexec /I <path to your MSI file> /l*v nameoflogfile.log

Conclusion

Visual Studio setup projects offer a limited but capable introduction to Windows Installer-based setups. They give you the basic functionality of a Windows Installer setup with MSI files, but to do so they hide some of the more complex functionality of Windows Installer. Hopefully, this series of articles will help you use setup projects successfully.

Phil Wilson

Author profile:

Phil Wilson is a software engineer at Unisys Corporation in California, a Microsoft MVP (Most Valued Professional) and author of The Definitive Guide to Windows Installer, Apress, 2004.

Search for other articles by Phil Wilson

Rate this article:   Avg rating: from a total of 229 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.


Subject: Handy
Posted by: Anonymous (not signed in)
Posted on: Thursday, June 29, 2006 at 1:22 PM
Message: Some images don't seem to work though.

Subject: Useful
Posted by: Anonymous (not signed in)
Posted on: Thursday, September 07, 2006 at 12:50 AM
Message: Actully i have no idea about this. this is a great article. - prasant

Subject: not able see deployment page
Posted by: Anonymous (not signed in)
Posted on: Monday, September 18, 2006 at 10:08 AM
Message: not able see deployment property page

Subject: Great article but not able get solution on upgrading failure
Posted by: Anonymous (not signed in)
Posted on: Monday, October 30, 2006 at 6:43 AM
Message: I am not getting the answer for the issue "Everyone install does not upgrade a Just me install, and vice versa."

This will be great article and very much useful information for the setup creators.

This will be more handy if there is a solution for the above issue using VS2003.

Subject: Helpful
Posted by: Anonymous (not signed in)
Posted on: Tuesday, October 31, 2006 at 4:28 AM
Message: The article clarified a lot of concepts.

Further details on how to handle upgrade of the same version, without changing the product code, and without using patches would be highly appreciated.

Subject: Very Useful
Posted by: Anonymous (not signed in)
Posted on: Wednesday, November 01, 2006 at 3:58 AM
Message: It is very useful article for me.
Was able to solve my problem.

Milan

Subject: Must Read
Posted by: Anonymous (not signed in)
Posted on: Friday, November 03, 2006 at 10:56 AM
Message: Thanks for your hard work.

Subject: Setup Project Properties Screen
Posted by: furjaw (view profile)
Posted on: Wednesday, November 15, 2006 at 12:02 AM
Message: My project uses Visual Basic in Visual Studio 2005 Professional. My Setup Project properties screen looks entirely different from your Figure 1. My properties screen shows VERY LITTLE info!

ron@humbird.org

Subject: Handy
Posted by: Anonymous (not signed in)
Posted on: Monday, December 18, 2006 at 4:19 PM
Message: Hi , Nice one, can you give me a solution for my problem if you know. The some of the directories are not deleted which is contains the DLLs files while doing "Remove" (UnInstall).

How to write the script or is there any other option to remove entier stuff.

Could you please send me the mail to

an_gobi@hotmail.com

Thanks in advance

Subject: Good Article
Posted by: Anonymous (not signed in)
Posted on: Tuesday, January 16, 2007 at 2:07 AM
Message: Article removes the unclear facts about Windows Setup and deployment projects, but could not act as a problem reliever for the hanged up issues.

ORCA has been mentioned but a detailed explanation about its usage should be figured in the article with proper images.

I would like to have the help on ORCA. Please mail me at taurianashish@gmail.com

Subject: great artical
Posted by: Anonymous (not signed in)
Posted on: Thursday, January 18, 2007 at 12:43 PM
Message: finally find this one that clear up the confusion. Thanks a lot for sharing the information.

Subject: Very Useful. I visit this site quite often
Posted by: Anonymous (not signed in)
Posted on: Wednesday, January 24, 2007 at 4:22 AM
Message: I'd like to get the solution on the following issues:

1. How to implement the restriction that the Newer version (Updater) will be installed only if it finds the older one. i.e If the machine doesn't have the older version it'll refuse the newer version to get installed.

2. If the above condition satisfies, serial key checking should not be there in the updater. Should I just delete the custom action and related entries which were introduced to implement serial key cecking?

sobhan_patra@yahoo.com

Subject: Exactly the info I need and could not find from Microsoft web sites!
Posted by: Anonymous (not signed in)
Posted on: Sunday, February 04, 2007 at 12:21 AM
Message: Thanks

Subject: Great Article(s) on installers, any words on WiX ?
Posted by: learnerplates (view profile)
Posted on: Friday, April 06, 2007 at 8:24 AM
Message: Hi Phil,
I find your articles on installer very informative, accurate and easy to read, thanks for the hard work.
I've just been playing with this new installer writer WiX, it appears to be getting popular but my first interaction with it was difficult. Have you played with it? if so what's your take? is it worth the investment instead of the Setup projects?


Subject: Thank you
Posted by: Anonymous (not signed in)
Posted on: Tuesday, May 08, 2007 at 6:30 PM
Message: THANK YOU SO MUCH!!! this saved me hours of work.

Subject: Great article and very helpful
Posted by: Anonymous (not signed in)
Posted on: Thursday, May 10, 2007 at 9:57 AM
Message: Thank you very much for sharing this!

Subject: Default Install
Posted by: Anonymous (not signed in)
Posted on: Saturday, August 18, 2007 at 5:02 AM
Message: Great article....

My problem is, I have a server and vendors have already installed a bunch of .net webapps, but changed the default InetPub/wwwroot to be in their forlders - let's call that 'VendorAapps'. I come and install a webservice on that server called 'MyWebService'. I can't choose the default path, so iis/win installs the 'MyWebService' webservice under the vendor's folders, way down under 'VendorAapps'. Now my webapp which uses the webservice seems to go to the right server, but seems to get confused with the vendor's apps and then returns a failure saying it couldn't find the assembly 'VendorAapps' or part of it. My code and apps worked before so I can rule out defective code, it must be how the webservice is installed yea? I hope anyone can shed some light on this.

Subject: Default Install
Posted by: Anonymous (not signed in)
Posted on: Saturday, August 18, 2007 at 5:07 AM
Message: Just about the above, my apps and the vendor apps have nothing to do with each other, apart from sharing the server - nothing more, but when calling my webservice, the vendorapp fails and thinks I called it. Could this also be related to folders in IIS ?

Subject: T H A N K Y O U ! ! !
Posted by: Anonymous (not signed in)
Posted on: Monday, September 17, 2007 at 1:10 PM
Message: Fantastic article! Exactly what I needed to know.

Subject: Problem
Posted by: tvphuc (view profile)
Posted on: Sunday, September 30, 2007 at 10:05 PM
Message: I create a MSI file and set RemovePreviousVersions property is true then I rebuild another MSI file and set PackageCode and ProductCode with the same previous PackageCode and ProductCode but It still message "Another version of this product is already installed ...".

Subject: Pls help...
Posted by: Arun (not signed in)
Posted on: Monday, December 03, 2007 at 8:04 PM
Message: As 'Tvphuc' said , I got the same issue in my msi package,How I will get the Repair or Remove option for msi package with the PackageCode and ProductCode as same as previous one, after rebuilding the msi.

Subject: Thanks
Posted by: Anonymous (not signed in)
Posted on: Wednesday, December 05, 2007 at 11:54 AM
Message: I've been trying to find this info everywhere. Thanks!

Subject: Too late...
Posted by: Anonymous (not signed in)
Posted on: Wednesday, January 02, 2008 at 2:07 PM
Message: Thank you very much for your article. I'm really sorry that i haven't saw it before because i have the problem you said about databases. My database is on the project and now if i update it reinstalls databases too and users loose their information. How can i pass trought this now? Please help...

Subject: How to change the Product Name property
Posted by: haterclay (view profile)
Posted on: Sunday, February 03, 2008 at 4:45 AM
Message: Hi ...

Thank you very much for your article. I am getting the problem with setup since I am not used to be with setup project. Your article taught me a lot. But there is still one problem, that, how can I change the Product Name in Deployment Project Properties at install time. I think it is possible in File Installation Properties >> Default Location. I do the same at Product Name. But it doesn't work at all. Please share me something about it .... Thank you very much for your sharing ....

Subject: Assigning Write Permissions
Posted by: Pawan Bansal (not signed in)
Posted on: Monday, February 04, 2008 at 2:03 AM
Message: Hello! This is a fantastic article though I would like further your help/guidance on one of the issue. I need to assign the write permissions and security rights to a specific folder to [Network service] user. This folder is meanmt to store my data in terms of XML files.

Please help..

I am in high tide waters with this problem.

Subject: Thank you!
Posted by: Ronen Meyuhas (not signed in)
Posted on: Thursday, April 10, 2008 at 8:28 AM
Message: Couldn't find this valuable information anywhere else.

Subject: Running custom actions for new version (major upgrade)
Posted by: Ronen Meyuhas (not signed in)
Posted on: Thursday, April 24, 2008 at 5:46 AM
Message: To avoid calling your old custom-action dll, Microsoft recommends strong-signing the dll:
http://support.microsoft.com/kb/906766/en-us

Subject: Must read
Posted by: Anonymous (not signed in)
Posted on: Tuesday, April 29, 2008 at 3:59 AM
Message: The article has clarified a lot of concepts.I was facing problem regaridng same version.Now i know, what is the right way to handle this thing.

Subject: How do you get to the deployment property page?
Posted by: Anonymous (not signed in)
Posted on: Wednesday, April 30, 2008 at 10:25 AM
Message: It does not seem to exist in visual studio 2005. I cannot seem to get to it no matter what I do. Please give some idea how to get to it. I just want to change the product name and GUID.

Subject: Must Read!
Posted by: Anonymous (not signed in)
Posted on: Thursday, May 01, 2008 at 9:51 AM
Message: MUST READ - I solved my installer issue after reading this article. THANK YOU!

Subject: Excellent !!
Posted by: Sundar (view profile)
Posted on: Thursday, May 15, 2008 at 2:07 AM
Message: Very simple and straight forward. Thanks.

Subject: Greate quick-start guide for creating MSI files in Visual Studio
Posted by: Erik W. (not signed in)
Posted on: Thursday, May 22, 2008 at 3:44 PM
Message: Phil - you rock!!

Many thanks to you for taking the time to write this 3-part series. I sucessfully created an MSI file for the initial release of my application and for subsequent upgrades. Removal of previous version works flawlessly.

Following your advice I keep user customizations in a file created at run-time (not installed). This has worked great to preserve the user's customizations when installing a newer version.

Also used Orca to hide the "Everyone" or "Just me" radio buttons and text (after setting the default to Everyone) and hide the Disk Cost button.

Many thanks!

Erik


Subject: sending out patches
Posted by: Anonymous (not signed in)
Posted on: Monday, May 26, 2008 at 2:55 AM
Message: Hi Phil,

This tutorial is really a good help. But I have a specific question. We are using VS 2005 for creating our windows installer using the setup and deployment project.

Now once I have rleased the installer and the end user has installed the application, I need to send out patches, say some dll's or exe's functionality has changed, what would be the best way to do that.

I acn use your above methodology to send out patches.

Pls do let me know if that would help or is there any specific way to develop pacthes for windows installer using the VS 2005 setup and deployment project/wizard.

Subject: installer patches
Posted by: rajeshpr (view profile)
Posted on: Monday, May 26, 2008 at 2:57 AM
Message: Hi Phil,

This tutorial is really a good help. But I have a specific question. We are using VS 2005 for creating our windows installer using the setup and deployment project.

Now once I have rleased the installer and the end user has installed the application, I need to send out patches, say some dll's or exe's functionality has changed, what would be the best way to do that.

I acn use your above methodology to send out patches.

Pls do let me know if that would help or is there any specific way to develop pacthes for windows installer using the VS 2005 setup and deployment project/wizard.

Subject: Upgrade does not override the assemblies.
Posted by: nara (not signed in)
Posted on: Tuesday, June 17, 2008 at 9:38 AM
Message: Hi Phil,
thank you for this article. i am working on packaging an upgrade for my app. i set RemovePreviousVersions = true, changed Version and ProductCode. When i install, it works fine. But it does not replace assemblies. I see the datetime stamp does not change for the assemblies.
Can you please tell me how to force the files to be installed. thank you.

Subject: Can I modify Setup UI?
Posted by: Matthew (view profile)
Posted on: Wednesday, June 25, 2008 at 2:59 AM
Message: Can I modify Button "Finish" to Button "Next" in the "Figure 2" ?

Subject: regarding upgrade
Posted by: Anonymous (not signed in)
Posted on: Tuesday, July 22, 2008 at 4:29 AM
Message: This article is nice .can I perfrom major upgrade without changing package code

Subject: "Everyone or just me" upgrade issue
Posted by: tushkan (view profile)
Posted on: Sunday, August 31, 2008 at 3:18 AM
Message: This article is nice but "Everyone or just me" upgrade issue remains unsolved-forcing the user to choose the same option during the upgade doesn't make sence. Is there any workaround found?
I'll be gratful for any useful answer.
Best regards,
Michael , tushkan(change to "@" only)gmail.com

Subject: Error with InstallAllUsers
Posted by: luisfco (view profile)
Posted on: Wednesday, November 05, 2008 at 5:09 PM
Message: I have an error when setting InstallAllUsers = TRUE.

If the PC where the MSI runs has more than one user, the setup runs OK.

But, if the PC has only one user the setup fails, trying to copy a file (to <common files>\myapp\), because the file already exists. If I look at the folder all the files were already copied, so I think it is trying to copy again the same files, just for a different user, but there is just one user in the PC.

anyone have had this problem?

Subject: InstallAllUser not working in VS 2008 Deployment Project
Posted by: ggianop (view profile)
Posted on: Friday, November 07, 2008 at 12:50 PM
Message: I'm trying to set the default InstallAllUsers to False. I'd then like to hide the UI option by setting InstallAllUsersVisible also to False.

However, when I take the first step the default selection in the UI is not changed. The UI still defaults to InstallAllUsers=True. If I hide the UI it's still installing for All Users.

Has anyone else ever seen this and have any idea how to fix it. I can't find any info on the web anywhere about this failure, but it seems pretty basic.

Subject: Changing Development Machines
Posted by: creejohnson (view profile)
Posted on: Sunday, December 28, 2008 at 8:49 PM
Message: Great article! Just curious if there is anything special I have to do to my setup project if I am changing development machines? I have copied both my main solution and the setup project to the new machine but am not sure if there is anything else I have to do?

Thanks!

Subject: Changing Development Machines
Posted by: creejohnson (view profile)
Posted on: Sunday, December 28, 2008 at 10:06 PM
Message: Great article! Just curious if there is anything special I have to do to my setup project if I am changing development machines? I have copied both my main solution and the setup project to the new machine but am not sure if there is anything else I have to do?

Thanks!

Subject: hey phil
Posted by: dineshbonn (view profile)
Posted on: Monday, February 16, 2009 at 6:34 AM
Message: Very nice article. very helpful thank you phil.. Actually i have one more doubt.
1) If i add the primary output in the user program menu and when i run the setup why the .dll also getting installed with the .exe.
2) Iam using access database in my application and iam using the connection string as application.startuppath. since iam using the application folder where my database is there so iam getting a error when i use the application because ( its looking for the path in start menu)..So how can use the connection string and the database ?..

Thank you.

Subject: Loading dll from msi
Posted by: pariksheet (view profile)
Posted on: Friday, February 27, 2009 at 1:24 AM
Message: Hi phil,
Its a very good article.
I have a doubt.
I have created one setup project and using orca I have modified the msi.
Now, I want to load the dll, read file, execute file, which is in msi itself while performing custom action. If you have any idea about it, then please let me know. You can contact me on pariksheet_gholap@yahoo.co.in

Subject: Setup.msi Run
Posted by: jey (view profile)
Posted on: Tuesday, February 23, 2010 at 5:56 AM
Message: It's Very usefull for me. I have some clarification when i click setup.msi
without ask any confirmation for user
If you have any idea about it, then please let me know. You can contact me on
jey208@gmail.com

Subject: Using previous install path
Posted by: Wigman (view profile)
Posted on: Wednesday, November 03, 2010 at 7:02 AM
Message: As other said: very helpful article.

I missed something in this article: when originally installing to the default path, updating works fine, but when the installpath was changed by the user during original install, the new installer doesn't know where this location is and points to the DefaultFolder value found in File System properties.
There are numerous articles of how to save the installpath to registry, but none explain how to use the DefaultFolder value for new installs, and use the registry key while updating to target the custom folder using the same msi.
After some testing I found a way:
Add a Registry Search to the LaunchCondition of the setup project, searching for your registry and set the Property value to: TARGETDIR (capitals)

This results in: Installing for the first time will have no search result, and the value in the DefaultLocation property in the File System screen will be used, but when a registry is found, the registry value will be used as default install location. However, the user is still prompted for the install location.

It would be better if by default the installer doesn't prompt where the update should be installed, so if someone can tell me this, please contact me.

Subject: any advice
Posted by: wasimoo (view profile)
Posted on: Wednesday, May 18, 2011 at 1:32 AM
Message: hi all, i have VS2010, and i have created the deployment project to generate msi, and everything goes well, but sometimes when i run the msi on any client pc it didn't remove the previous version even i set removepreviouspervios property to true, specifically when i updated the config file on pc manulay,..

any advice,,, thnx in advance


Subject: any advice
Posted by: wasimoo (view profile)
Posted on: Wednesday, May 18, 2011 at 1:59 AM
Message: hi all, i have VS2010, and i have created the deployment project to generate msi, and everything goes well, but sometimes when i run the msi on any client pc it didn't remove the previous version even i set removepreviouspervios property to true, specifically when i updated the config file on pc manulay,..

any advice,,, thnx in advance


Subject: Advice Please
Posted by: raghusrikanth (view profile)
Posted on: Thursday, July 25, 2013 at 12:04 AM
Message: Hi All, i have vs 2005 project and setup project and as part of each build i have to update upgrade code. Is there any solution for to automatically update upgrade code in each build, I am going to use Msbuild.proj files to automate build process.

Thanks in advance.

 

Top Rated

Acceptance Testing with FitNesse: Multiplicities and Comparisons
 FitNesse is one of the most popular tools for unit testing since it is designed with a Wiki-style... Read more...

Acceptance Testing with FitNesse: Symbols, Variables and Code-behind Styles
 Although FitNesse can be used as a generic automated testing tool for both applications and databases,... Read more...

Building Performance Metrics into ASP.NET MVC Applications
 When you're instrumenting an ASP.NET MVC or Web API application to monitor its performance while it is... Read more...

Acceptance Testing with FitNesse: Documentation and Infrastructure
 FitNesse is a popular general-purpose wiki-based framework for writing acceptance tests for software... Read more...

TortoiseSVN and Subversion Cookbook Part 11: Subversion and Oracle
 It is only recently that the tools have existed to make source-control easy for database developers.... Read more...

Most Viewed

A Complete URL Rewriting Solution for ASP.NET 2.0
 Ever wondered whether it's possible to create neater URLS, free of bulky Query String parameters?... Read more...

Visual Studio Setup - projects and custom actions
 This article describes the kinds of custom actions that can be used in your Visual Studio setup project. Read more...

.NET Application Architecture: the Data Access Layer
 Find out how to design a robust data access layer for your .NET applications. Read more...

Calling Cross Domain Web Services in AJAX
 The latest craze for mashups involves making cross-domain calls to Web Services from APIs made publicly... Read more...

Web Parts in ASP.NET 2.0
 Most Web Parts implementations allow users to create a single portal page where they can personalize... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.