Getting Started With Setup Projects

First in a series on Visual Studio setup and deployment

This article describes the basics of Visual Studio setup and deployment projects. Subsequent articles will cover advanced topics, including more on custom actions, .NET installer classes, and how to build an upgrade for the product.

Introduction

Setup and deployment projects have always been a part of the Visual Studio.NET environment. Setup projects can be used to build various deployment packages, most notably Windows Installer setups packaged as MSI files.

I’ll start with a basic setup that installs a C# Windows forms program and adds a shortcut to it.

First, select Setup Project, grouped under Setup and Deployment in the Other Project Types section. Choosing this will give you an empty project for adding your deployment units. With the project selected in Solution Explorer, the View->Editor choice gives you a selection that includes File System – this is where you add your files and shortcuts.

Application Folder is the recommended place to install your programs and other binaries – I’ll explain why in a moment. You can right-click in the
Namearea and choose Addto browse to your files, or simply drag a file from Windows Explorer. See Figure 1, showing our C# program in the application folder.

Figure1

You can see the application folder’s properties by choosing right-click->Properties(or using F4); these properties are shown in Figure 2. Note that the
DefaultLocation property is a sequence of names in square brackets. These are not specific properties of Visual Studio setup projects; they are standard properties that apply to any Windows Installer setup.

Figure 2

ProgramFilesFolder is the property name for the path to the standard program files folder on the target system—you can’t hard-code something like C:\Program Files because that’s not always the location. The other properties, Manufacturer and ProductName, are also standard Windows Installer properties that you can set as appropriate. (Incidentally, if you’re wondering why there is a backslash after Manufacturer but not after ProgramFilesFolder, it’s because ProgramFilesFolder is a folder property, and these properties already include a trailing backslash.) You set Manufacturer and ProductName in the properties of the project (select the project in Solution Explorer and use F4) as shown in Figure 3. I’ll talk about the other properties there shortly.

Figure 3

Note that Figure 2 shows that the property associated with the application folder is named TARGETDIR. This is another standard Windows Installer property that is most often used for the primary installation folder, as it is used here. The application folder is the usual place to install your binaries because it’s the standard folder location for program files.

You add a shortcut by selecting your executable in the IDE, right-clicking and choosing Create Shortcut. Visual Studio puts the shortcut in the same location in the IDE (the application folder), but you can then select it and cut and paste it to its required location, such as the User’s Desktop folder (see in Figure 1, center pane).

It’s common practice to add a shortcut into the user’s program menu, and that’s shown in Figure 4. You add your folder names to the program menu by using right-click and choosing Add Folder. Interestingly enough, you can’t use [Manufacturer] and [ProductName] here – they don’t resolve to the actual values at install time as they do when used in the application folder properties.

Figure 4

You may have noticed that there is a Project Output choice when you right-click on a folder in the IDE and choose Add to add your files. This lets you select a project, the output of which will be added to the folder when you build the projects. This is convenient when you are switching between debug and release builds because it transparently adds the correct files. I don’t recommend using project output, however, for the simple reason that you don’t actually see what files you’re getting. In addition, it might be obvious that project output means something like an executable or DLL, but if you need to add a data file you have no choice except to add it manually.

In Figure 2 we saw that TARGETDIR is a Windows Installer property constructed from other installer properties that can be used in square brackets to cause their resolution to actual values during the install. You can use Windows Installer properties like this in other parts of the installation. It’s common, for example, to want to know where the application was installed. Figure 5 shows you how to do this using the registry view in the IDE. In the name of the registry field, you can create a string-valued registry item (MyLocation in this example) that has the value [TARGETDIR]. Note also in Figure 5 the use of installer properties in the registry key folders, used in the same general way as with TARGETDIR and DefaultLocation in Figure 2.

Figure 5

Resilience

One of the features of a product installed with a Windows Installer setup is its resilience, meaning that it will self-repair if it is damaged by actions such as removing files.

Repair descriptors are created during the install and are associated with certain installed items, including shortcuts. This means that using a shortcut can initiate a health-check of the associated files and restore them if they are missing (and the same repair mechanism can occur to restore registry entries). You can show this quite easily by installing the sample setup and removing the program that is the target of the shortcut (WinForm.exe in this example). If you then use the shortcut referring to the missing file, you’ll see a Windows Installer progress dialog as it repairs the installation by restoring the missing file.

This behavior sometimes takes developers by surprise when they want to install a product and then remove unwanted files or registry entries, so take resilience into account when designing a setup.

Installing .NET assemblies

You can install .NET assemblies (class libraries) into the application folder in the same way as installing executables such as our Windows Forms program. It’s not so clear how you install assemblies into the global assembly cache (GAC), but if you right-click on File System on Target Machine in the Visual Studio IDE view of the file system, you’ll see an Add Special Folder choice. After you’ve clicked this you’ll be able to select the GAC as a destination for your assemblies.

Installing COM servers

You’re probably familiar with the idea that you install COM servers by running Regsvr32.exe on them, which internally calls the DllRegisterServer function that creates the required registry entries. In Windows Installer, you are encouraged to create the registration entries at build time instead of at install time. You do this by selecting the file in the IDE, going to the properties (F4), and setting the appropriate register value. Your choice will depend on whether the file is a traditional COM DLL or a .NET assembly that exports COM classes and interfaces.

Traditional COM servers

A traditional COM DLL will have the following choices in the register property in the IDE:

vsdrfCOMSelfReg

This is the self-registration option where Windows Installer will call the DLL’s DllRegisterServer entry point at install time. This is the setting that’s not encouraged, as described in the next setting, vsdrfCOM.

vsdrfCOM

When you select this and build the MSI file, the registration entries are extracted at build time and stored in the MSI file. When the MSI file gets installed, the DLL is copied to the system and the required registry entries are created from the data in the MSI file, such as the CLSID, ProgId and type library information. The end result is the same as if the DLL self-registered, except that the DLL code was not actually called at install time. This can be particularly important if your DLL is linked to another DLL that hasn’t yet been installed and therefore would result in the DLL failing to load if it was called during the install.

vsdrfCOMRelativePath

This is the same as vsdrfCOM except that the path to the DLL is relative, not absolute; it’s just the actual name of the DLL. This is used in a variety of COM side-by-side called DLL/COM redirection, where an application executable is installed with a redirection file (just the executable file name with .local appended). This particular side-by-side scheme was introduced in the Windows 2000 timeframe and is superseded by the manifest-based registration described in my earlier article on simple COM registration using a side-by-side method.

.NET assemblies as COM servers

If you have a .NET assembly that exports COM interfaces and you mark it to be installed in your application folder, you’ll see register choices for vsdraCOM and vsdraCOMRelativePath. These create path information in the same way as the vsdrfCOM and vsdrfCOMRelativePath choices above (absolute or relative path), but assemblies aren’t registered with DllRegisterServer, so clearly something else is going on here!

If you were to monitor Visual Studio while it was building your setup, you’d see that it runs Regasm.exe, the assembly registration tool. It’s using Regasm.exe to produce a .REG file and then importing the results into the MSI file. In other words, your setup will now produce the same entries for your assembly as running Regasm.exe with the /regfile command line option. It’s important to realize that this not the same as just running Regasm.exe on your assembly. The one crucial difference is the type library information.

When you install a traditional COM DLL, the type library information is usually in the DLL, so the registration options for traditional COM DLLs will also register type library information. .NET assemblies do not contain COM type library data, so if the COM client/server interfaces in your .NET assembly require type library marshaling, you’ll need to export a type library from your assembly (using Tlbexp.exe) and add it to your setup. You’ll see that this .TLB file has a vsdrfCOM choice in the register property, which will cause the type library to be registered on the system in the traditional way.

Searching the system during the install

One of the other view options in the Visual Studio IDE is called Launch Conditions. If you look in this view you’ll see that there are two categories shown: Search Target Machine and Launch Conditions. If you look in Launch Conditions for a setup that installs something requiring the .NET framework, you’ll see that Visual Studio has already added a launch condition for the .NET framework. If you look in the properties for this you’ll see something like Figure 6.

Figure 6

Two interesting items here are the SupportedRuntimes value and the URL. SupportedRuntimes is the .NET Framework runtime version your application uses; this value can be a semi-colon delimited list of the versions your application can use. The InstallUrl is a link to where the framework can be downloaded.

When you run the setup, one of the first things that happens is that Visual Studio runs some code to check for the presence of the framework on the target system. If it’s not there, Visual Studio will offer a yes/no choice for the client to install it from the named InstallUrl. If you look at the documentation for InstallUrl you’ll see that it doesn’t need to be a URL—there are choices for a UNC path or a relative path location that’s useful when installing from a CD.

The other category, Search Target Machine, offers you three choices with a right-click. These choices have one thing in common: They create a property if the search is successful, and the resulting property value tells you something about what the search found. Since these searches can be extremely useful in your install, I’m covering them in some detail. We’ll review the searches first, then look at the properties and what you can do with them.

Search for a file

This search is what I call the brute force approach. Figure 7 shows a search for notepad.exe in the SystemFolder. Note those square brackets, meaning that it’s a standard installer property referring to the system folder on the target machine. This search creates a property called FILEEXISTS1 if it’s successful. It’s brute force because it scans the designated folder to the depth required to find that file. Note that the search stops when it finds the first occurrence of the file, so use the date and version specifications to help find the right one in case there are multiple copies of the file.

Figure 7

Search for a registry entry

In Figure 8 I’ve created a registry search that returns the version of MDAC (Microsoft Data Access Components) on the target system by reading the registry entry where this value is stored. This time I’ve created a property called MDACVER. There’s a root property where you specify the hive for the search; RegKey names the key and Value names the item you want to retrieve. Leave this value empty if you want the default item from that key.

Figure 8

Search for a Windows Installer component

A Windows Installer component is the basic unit of installation in any MSI install. You can’t tell this as you use Visual Studio because it’s generating these components and giving them a GUID when it builds the MSI file, but not exposing them in the IDE. This GUID should not be confused with the ProductCode or UpgradeCode GUIDs. In Figure 9 I’ve created a search for a component GUID that happens to be the value for the WinWord executable from Microsoft Office 2003. I’ll explain how to find values for these GUIDs in a moment.

Figure 9

It can be difficult to see the property values that result from these searches when you’re debugging. One way to do this is by showing them in the welcome screen of the setup. This works because these searches take place before this dialog is shown. Looking at Figure 10, you can see I’ve deleted the standard text in the CopyrightWarning and WelcomeText properties of the welcome dialog and partially replaced them with those search properties in square brackets. Note that the standard welcome text includes [ProductName] to show the product name (see Figure 3 to see where you set it).

Figure 10

When you run the install, the welcome dialog will show you the property values, as in figure 11. As you can see, the WORDPATH property is the directory where Winword.exe is installed, FILEEXISTS1 is the actual location of Notepad.exe, and MDACVER is the version of the data access components.

Figure 11

One of the ways you can use the result of a search is in the launch conditions. The property will be created if the search succeeds, but not if it fails. This means that you can use these properties as Boolean values in a launch condition. If you go to the launch conditions node in the IDE and add a condition, you’ll see that there’s a condition drop-down that is pre-filled with the properties named in your searches. Figure 12 shows a condition that depends on the FILEEXISTS1 property. You can use these searches to add your own error message and stop the install if certain conditions are not satisfied.

Figure 12

The property value returned by the Windows Installer component search is a path to that component and its installed location on the system. One of the places you can use a path is when you create a custom folder in the file system view. Figure 13 shows a custom folder that has a property value of WORDPATH so that the file (Form1.cs in this case) installs to the same folder where Winword.exe is installed. If that WORDPATH value is not set, the install defaults to the application folder specified by TARGETDIR in that DefaultLocation property in the IDE.

Figure 13

So how do you identify the installer component for a GUID? One of the ways is to run a VBScript like the one below:

This script uses the automation features of Windows Installer to enumerate all the installer components on the system (Installer.Components), the products that are using them (Installer.ComponentClients), and the path to the component, which most often is the path to a file. The output is a text file with this kind of content:

"{1EBDE4BC-9A51-4630-B541-2561FA45CCC5} is used by:Microsoft Office Professional Edition 2003 {91E30409-6000-11D3-8CFE-0150048383C9} at C:\Program Files\Microsoft Office\OFFICE11\WINWORD.EXE

This shows that the named component GUID is used by Microsoft Office 2003. It also shows the ProductCode of Microsoft Office 2003 followed by the path to the component, in this case the path to Winword.exe. These component GUIDs are constant for any particular setup, but you can’t rely on them being constant across all versions of a product (such as several versions of Microsoft Office in this example).

In the registry search, the version of MDAC was recovered as a string value. In this type of search you’re more likely to care about the version value rather than whether it’s in the registry or not. So you might be looking for a way to prevent the installation if (in this example) the version of MDAC is lower than your application requires. You can do this with a launch condition that executes a string comparison on the value of MDACVER.

Figure 14 shows a launch condition requiring an MDAC version greater than 2.81.119.0. That’s higher than the version on my system (2.81.1117.0), so the install will fail, showing the version that is actually present. It works this way because the value retrieved is a string, a REG_SZ. If you get the value of a REG_DWORD from the registry, the value returned into your property will be preceded by a # character, a crosshatch in the USA character set. This lets you know it’s a REG_DWORD, but, more important, if you need to compare it with a value you’ll need to include the # in your comparison string.

Figure 14

A property value retrieved from a search can be used as a condition when you’re installing a file. Figure 15 shows a condition where the file will be installed only if the WORDPATH property has been set.

Figure 15

You can also use standard installer property values in all these places where we’ve used the properties created by the searches. So if you want to install a file only on the Windows NT/2000/XP series, you can condition the file install on the VersionNT property. Similarly, you can use the VersionNT property as a launch condition. For a full list of properties, look in the Windows Installer SDK section of the platform SDK.

Custom Actions

It’s extremely useful to be able to add your own code to a setup. Windows Installer calls these custom actions, and they are basically functions that are called during the install. I’ll look at a simple one for now, and cover them in detail in a subsequent article.

Perhaps "real programmers" look down on VBScript, but there is excellent support in Windows Installer for calling VBScript code. Figure 16 shows an install custom action configured in the IDE, calling a custom action that is a VBScript consisting of this single line of code:

msgbox Session.Property ("CustomActionData")

Figure 16

As you can see from Figure 16, CustomActionData is being set to our WORDPATH property value (in square brackets so that it’s resolved as a property value). Session.Property in that script is part of the object model framework supplied to the script at run time.

Windows Installer supplies the same object framework to interact with the hosting environment as Internet Explorer and Windows Script Host. In this example, the Windows Installer session object is being used with Property to get the value of the CustomActionData property. Sure enough, the setup will display the value of the
WORDPATH property that’s been passed in via the CustomActionData property.

CustomActionData is a standard Windows Installer property that’s used in certain circumstances to pass property values to custom actions. The mechanism works by setting CustomActionData to the value you wish to pass into the custom action, which then retrieves it by looking at the CustomActionData property. This is unique per custom action, not per setup, so you can use CustomActionData in every custom action you use and it gets the value you passed in. This might seem fairly convoluted, especially if you’re sitting there wondering why you can’t simply display the property with code such as:

msgbox Session.Property ("WORDPATH")

The reason you can’t do that in a Visual Studio setup project is related to the architecture of Windows Installer and how Visual Studio setup projects use it, something I’ll cover in a later article.

Conclusion

Visual Studio setup projects offer a limited but capable introduction to Windows Installer-based setups. Their advantage is that they give you the basic functionality of a Windows Installer setup with MSI files. Their principal drawback is that they hide some of the more complex functionality of Windows Installer. This article should help you use Visual Studio setup projects successfully.

Not only does it reference an IP address (which is valid, but still bad-juju,) but there's an extra "iwritefor" in the path.

If you grab a local copy of the HTML, and manually fix the image URLs you can retrieve the article. It's a dirty hack, but come on, we're all geeks here, right?

Subject:

Images

Posted by:

Anonymous (not signed in)

Posted on:

Monday, July 31, 2006 at 1:47 AM

Message:

None the less the writer can't expect all readers to correct his broken links ;) After all it works this way.. but working links would have improved my rating for the article significantly...

Subject:

Darn Images

Posted by:

Anonymous (not signed in)

Posted on:

Monday, July 31, 2006 at 1:50 PM

Message:

Well I *am* the writer, but I don't control the web site. I have asked for the links to be fixed (ALL my setup articles have the same problem) but obviously they're still broken as of 7/31.

Subject:

Images missing (still)

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, August 10, 2006 at 1:42 PM

Message:

I'm glad you wrote this setup article. This is a subject that needs more coverage. However, I find the fact that the images are still not fixed a bit troubling.

I would be glad to mirror your article on my blog at http://blog.davestechshop.net/. I host the site myself, so it is easy to fix issues like this. (Plus, I need some good content - I just put the blog up yesterday.)

I use Subtext as my blogging platform, and it seems to have more features than what you use now.

Let me know if you are interested. And thanks for writing the setup articles.

Subject:

complete steps for fixing this

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, August 10, 2006 at 1:50 PM

Message:

If you use IE, do this:1. Click View on main menu, then click Source.2. When the html opens in notepad, save it as SetupArticle1.html to a local folder on your HDD.3. Type Ctrl-H to open the replace dialog in notepad.4. Enter "/iwritefor/iwritefor" as the search term.5. Enter "/iwritefor" as the replace term.6. Click replace all.7. Save again.8. Open IE and type Ctrl-O (for File Open).9. Browse to the folder where you saved SetupArticle1.html and click OK.10. You should see an article with all the images.11. In IE, select File > Save As. Save the complete web page to your local computer because obviously someone somewhere doesn't know what is going on, and these server images may disappear by the next time you want to reference this article!

Subject:

complete steps for fixing this

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, August 10, 2006 at 3:38 PM

Message:

If you use IE, do this:1. Click View on main menu, then click Source.2. When the html opens in notepad, save it as SetupArticle1.html to a local folder on your HDD.3. Type Ctrl-H to open the replace dialog in notepad.4. Enter "/iwritefor/iwritefor" as the search term.5. Enter "/iwritefor" as the replace term.6. Click replace all.7. Save again.8. Open IE and type Ctrl-O (for File Open).9. Browse to the folder where you saved SetupArticle1.html and click OK.10. You should see an article with all the images.11. In IE, select File > Save As. Save the complete web page to your local computer because obviously someone somewhere doesn't know what is going on, and these server images may disappear by the next time you want to reference this article!

Subject:

complete steps for fixing this

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, August 10, 2006 at 3:38 PM

Message:

If you use IE, do this:1. Click View on main menu, then click Source.2. When the html opens in notepad, save it as SetupArticle1.html to a local folder on your HDD.3. Type Ctrl-H to open the replace dialog in notepad.4. Enter "/iwritefor/iwritefor" as the search term.5. Enter "/iwritefor" as the replace term.6. Click replace all.7. Save again.8. Open IE and type Ctrl-O (for File Open).9. Browse to the folder where you saved SetupArticle1.html and click OK.10. You should see an article with all the images.11. In IE, select File > Save As. Save the complete web page to your local computer because obviously someone somewhere doesn't know what is going on, and these server images may disappear by the next time you want to reference this article!

Subject:

Sorry

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, August 10, 2006 at 3:39 PM

Message:

Refreshing my browser submitted my comment again!

Subject:

COnfigure .tlb file in visual studio dotnet 2003

Posted by:

Anonymous (not signed in)

Posted on:

Tuesday, September 26, 2006 at 11:18 AM

Message:

I want to reverse engineer the application with quick modeler tool My question is when i install quick modeler tool i am getting .tlb file, now how can i add that .tlb file in my visual studio dotnet(2003) for reverse engineering

Subject:

Thanks. Great one!

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, November 2, 2006 at 1:32 AM

Message:

Sheesh, so hard to find good articles on Setup projects. I finally figured out how to do registry searches. :D

Subject:

Thanx

Posted by:

Anonymous (not signed in)

Posted on:

Tuesday, November 14, 2006 at 12:27 AM

Message:

a very good article for beginner

Subject:

Demo Files

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, December 7, 2006 at 4:09 AM

Message:

Hi

Thanks for the details provided, but i faced one problem in this. We created Data folder(data folder consists demo files) in File System on Target machine. Installation happened very fine but when we delete that purticular files from build application is re-installing.

Can you send a solution for this.

Subject:

Demo Files

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, December 7, 2006 at 4:22 AM

Message:

Hi

Thanks for the details provided, but i faced one problem in this. We created Data folder(data folder consists demo files) in File System on Target machine. Installation happened very fine but when we delete that purticular files from build application is re-installing.

Can you send a solution for this.

Subject:

Custom action

Posted by:

Anonymous (not signed in)

Posted on:

Monday, December 11, 2006 at 9:09 AM

Message:

Hi

good article about setup deployment but i can't find how to run a custom action when the application start !

i work with visual studio 2003 and i've create a setup deployement program and create with note pade a vbs script with one line = msgbox 'hello '

i've create a custom action at install and select my file vbs i compile the program but when i run the setup.exe nothing can't be happen ! i can't see my script hello at the scree :-( !

What i can do thanksChristophe

Subject:

wat if target system does not have dot net

Posted by:

shaeron (not signed in)

Posted on:

Monday, January 8, 2007 at 10:58 PM

Message:

Evrythng is alright but tell me if my target machine is not having dot net then where should i place an EXE that will install dot net framework on target PC and what exe should i include for that. Is it "Dotnetfx.exe"

Subject:

How I can install COM+ component using windows installer

Posted by:

Anonymous (not signed in)

Posted on:

Friday, February 2, 2007 at 12:36 PM

Message:

This is a really very useful article. Could you pls suggest as to how to install com+ component using windows installer?

Subject:

WANTED: More info...

Posted by:

Anonymous (not signed in)

Posted on:

Wednesday, February 28, 2007 at 2:03 AM

Message:

Hi - Nice article!Does anyone know where to find more about Setup Projects and conditions?I'm working on some very complex MSI-packages.\Thanks

Subject:

.net 2.0

Posted by:

Anonymous (not signed in)

Posted on:

Wednesday, March 14, 2007 at 4:10 PM

Message:

I have a project done in VS 2003, is there any way i can check for framework 2.0 and install it instead if it is missing. exactly the same way as it does for framework 1.1thanksvishnu

Subject:

Batch File

Posted by:

Anonymous (not signed in)

Posted on:

Monday, March 19, 2007 at 12:58 AM

Message:

I have a project in VS2005 and need to execute a Bat file at the end of the install. At the moment, I rely on my client to run the bat file. Is there any way this can me automated ?

Subject:

Batch File

Posted by:

Anonymous (not signed in)

Posted on:

Monday, March 19, 2007 at 4:54 AM

Message:

I have a project in VS2005 and need to execute a Bat file at the end of the install. At the moment, I rely on my client to run the bat file. Is there any way this can me automated ?

Subject:

Batch File

Posted by:

Anonymous (not signed in)

Posted on:

Monday, March 19, 2007 at 6:15 AM

Message:

I have a project in VS2005 and need to execute a Bat file at the end of the install. At the moment, I rely on my client to run the bat file. Is there any way this can me automated ?

Subject:

Batch File

Posted by:

Anonymous (not signed in)

Posted on:

Monday, March 19, 2007 at 7:02 AM

Message:

I have a project in VS2005 and need to execute a Bat file at the end of the install. At the moment, I rely on my client to run the bat file. Is there any way this can me automated ?

Subject:

Hi

Posted by:

Anonymous (not signed in)

Posted on:

Tuesday, March 20, 2007 at 12:54 AM

Message:

It's an average article.

Subject:

pre install other software

Posted by:

Anonymous (not signed in)

Posted on:

Monday, April 2, 2007 at 6:37 AM

Message:

my subject is also like this if any one found an answer pls tell me.my mail id: iswimnet4u@gmail.com

Evrythng is alright but tell me if my target machine is not having dot net then where should i place an EXE that will install dot net framework on target PC and what exe should i include for that. Is it "Dotnetfx.exe

Subject:

pls help me get more

Posted by:

Anonymous (not signed in)

Posted on:

Monday, April 2, 2007 at 6:39 AM

Message:

can anyone help me in getting more info on setup projects.my id iswimnet4u@gmail.com

Subject:

Good Article

Posted by:

Anonymous (not signed in)

Posted on:

Monday, April 9, 2007 at 9:32 AM

Message:

Hi,This is very good article.I have small request. I want to put some text boxes, there user enters his/her userid which verified by webservice. if user id is wrong i want to revert back setup. how can we do this

I have a setup project in which I have added console project exe file.I have to make this exe file run before exiting from the setup project so that I can write some values in a text file uisng this exe file.

I have tried putting the exe file in the "Install" folder of the custom actions of the setup but it is not working.

Thanks,mnvk.

Subject:

Start execution after installation completes

Posted by:

Anonymous (not signed in)

Posted on:

Tuesday, April 10, 2007 at 2:15 AM

Message:

Hi,I am relatively new to dot net programming. I was coding a desktop utility and have created a setup for the same.. The setup is running absolutely fine but I wanted to start the execution of the app.. as soon as the installation completes.. Is there any way to start the app immediately after installation is complete.Thanx in advance.. regards.

Subject:

NOT overwriting existing file

Posted by:

Anonymous (not signed in)

Posted on:

Monday, April 23, 2007 at 4:25 AM

Message:

I'm creating a setup-project that can be used as an initial installation + an upgrade of an existing installation.

Is it possible in a Setup Project to choose NOT to overwrite a file if it already exists from a previous installation?

\Thanks

Subject:

batch file

Posted by:

Anonymous (not signed in)

Posted on:

Friday, April 27, 2007 at 2:22 AM

Message:

I have a project in VS2005 and need to execute a Bat file at the end of the install. At the moment, I rely on my client to run the bat file. Is there any way this can me automated ?

very urgent

Subject:

About Batch file

Posted by:

Anonymous (not signed in)

Posted on:

Thursday, May 3, 2007 at 11:35 PM

Message:

Hi - I don't think Phil Wilson is reading this anymore.

But I've successfully made a batch run - though you have to create a .vbs or likewise that runs the batch for you. I could not make it work calling the .bat directly.

Subject:

Some replies to comments...

Posted by:

Anonymous (not signed in)

Posted on:

Monday, May 14, 2007 at 2:26 PM

Message:

Framework installs are handled by Prerequisites on VS 2005 and by a built-in check on VS 2003 in the Launch Conditions view. In other words you don't need to do anything special, just get Visual Studio to do it for you.

There is no support in Visual Studio setup projects for validation of input as it's being entered. KB article 253683 describes how to edit the MSI file to do this kind of thing, although it's a little out of date.

Writing a registry entry from an exe is a programming exercise - it depends what language you're using. Registry APIs in Win32, Registry classes in .NET is the general answer.

Overwriting files from previous installs - a Visual Studio upgrade is an uninstall of the old product version followed by an install of the new version. So it's not an overwrite, it's exactly as if a user uninstalled the previous version and then installed the newer version.

To have your app running after the install, write a custom action that fires off the app asynchronously and then exits.

See the other articles in this series for details of how to run custom actions and how upgrades work.

The MSDN Technical forums for ClickOnce and Setup&Deployment Projects is a good place to ask these questions - I'm there a lot, as well as others. http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=6&SiteID=1

Subject:

Query on Search for register entry + Accessing property

Posted by:

Rahul (not signed in)

Posted on:

Friday, July 27, 2007 at 2:06 AM

Message:

Hi all,

Thank you for such a good article.

I am a newbie to Visual Studio.I got a doubt on my 'Visual Studio setup and deployment project'.

Please note that I added a new field @ "Requirements_on_target_machine->Search_Target_Machine->Search_for_registry_entry"

I am getting the search result path correct (say for example the result value is - 'C:\ABCD\'. Also assume the PROPERTY name of the search is 'PROP1')

I am using this 'PROP1' as the property of:"File_System_on_Target_Machine-> My_ABCD_DO_FOLDER" (suppose this folder contains a 'hai.dll' and my aim is to install/save this 'hai.dll' to 'C:\ABCD\DO\' folder while running the setup)

My question is how to get it done if i am getting the register search value as 'C:\ABCD\' and not 'C:\ABCD\DO\' !??(is there something like 'PROP1 + "DO"?)

[Here ABCD is pre-installed s/w and 'hai.dll' is a plugin to the s/w, which should be installed @ "install-directory-of-ABCD / DO /" folder]

Am i missing something here? Any help will be appreciated.

thanks,rahul

Subject:

Query on how to edit the "Disk Cost..." button label

Posted by:

Rahul (not signed in)

Posted on:

Friday, July 27, 2007 at 2:59 AM

Message:

Hi all,

I need to know how to rename / edit the "Disk Cost..." button name , which will be present, by default, in the "Select Installation folder" page, of a setup.

i have an installer that needs to invoke a 2nd installer - how do i do this using VS2005? is it something i can initiate via a vb script or is that going to fail because an install is already in progress?

Hi all, I want to disable the resilience feature in my installer package. how can I do it???

regards,nelluru

Subject:

Post Build (.bat files)

Posted by:

Anonymous (not signed in)

Posted on:

Wednesday, September 12, 2007 at 9:34 AM

Message:

Excellent article.

To those that are in need of executing batch files, you can take the same commands used in your batch file and add them to the PostBuildEvent or PreBuildEvent of the setup project properties. You can also add the batch file commands in the development project under the project properties, compile tab and clicking on the BUILD EVENTS button. For example, I want to have my executable digitally signed. I used to run a batch file after the build to digitally sign the file. Now whenever I build the project it signs the file automatically. I also sign the msi package, though I don't know if its necessary. Still, it can't hurt.

Subject:

Thanks for the article

Posted by:

Anonymous (not signed in)

Posted on:

Friday, September 21, 2007 at 12:31 AM

Message:

Thanks for the article

Subject:

Condition on shortcut

Posted by:

Anonymous (not signed in)

Posted on:

Sunday, October 28, 2007 at 5:07 PM

Message:

Hi everyone,Do you know if it is possible to put a condition on a shortcut? It is possible on a file, but I can find this for shortcut.Thanks.

Hello Phil,I would like you about having a dynamic deployment setup project.

Suppose the windows application I am developing the Setup Project to requires to have an XML file that has some data to be used by the application when it runs.

However, this XML file should be different for different customers.How can I create a setup project in a sense that, I can give the admin a way to edit that configuration file before deployment, i.e. for client X, I will include XX data in the XML file, for client Y, I will include XY data for the client, etc ...

Can this be done with Setup projects? Or a better solution would be by creating a confgiuration editor small application, that installs only for the admin who can change the data for each client? If yes, how to make this application (exe) available only for admins?

I've used the info on this page to create an installation project in VB.NET, but ran into a problem with the version number.

Until now I've simply used the deployment feature in VS 2008 to create all the files for the setup, and put them into a .zip file. (You can see what I mean if you go to www.KeywordAssistant.net , click on the free download link, and just open the .zip without actually downloading it.)

Although this produces a perfect installation, the instructions are likely to frighten computer novices.

To simplify the installation I followed your instructions on this page, but discovered that the 'keywordassistant.exe' assembly contains no version number, even though the setup project detects it in the 'Properties' window.

Consequently, the application can never be updated. When a check for updates is done, the app bails out with an error.

I've tried including the manifest and other files in the build, but that did no good.

Thanks for the great article. I have some questions if you have some time...1. Most important. Are you going to publish a new addition of your book? If not, is it still applicable to Visual Studio 2008/2010? How much has changed with the installers?

2. You talk about registering COM objects in your article and using vsdrfCOM. I've played with this and it seems to work fine. However, when I do an uninstall, the file is removed, however, I don't believe the registry entries are. I discovered this by backing up the file somewhere, doing an uninstall, and then putting the files back manually. All worked well, which is not to be expected. Is there a way to clean up the registry? Is it something one normally worries about.

3. I'm a little unclear on what needs to be done for interop assemblies. The code I'm bundling up (didn't write it) is an MFC application that calls a .NET assembly. The .NET assembly has had regasm run on it and there is a .dll and a .tlb file associated with it. When I pull the .dll file into the Windows Installer Project, a .tlb file magically appears. Not sure if Installer is grabbing it from the directory or creating a new one. In any case, I have the .dll set to vsdraCOM and the .tlb file set to vsdrfCOM. This seems to work, but I have believe I should not need the .tlb file. When I put the files down on the target computer directly, I don't need it! Also, like #2 above, I don't think these files get unregister or unregasm or whatever at uninstall time. Should they? How do I ensure it?

One questions arose concerning the update installation. Can the custom action get information about the state. For example, is it called because of an update. Or is it activated because of the final removal of the product?

I am modifying VDPROJ file for its different information programatically. In this process I am also adding an exe in projectoutput section. FYI..my solution contains multiple projects so there are multiple exe. Now my question is how can I give the string "Primary Output from <my.exe> (Release Win32)" programatically in VDPROJ file? Because by changing projectoutput's code programatically, following name string is coming automatically "(unable to determine name)".