I have made an installer which contains the exe and dlls, made in using Visual studio the thing is can i add some code to it?
example when it install i just want to run 3-4 lines of code.
1- Get mac address add to database, with a unique key.
And similarly on uninstall remove the mac address from the database .
Is this possible in this current scenario using the default setup project?
You will need to use a CustomAction for your installer. With this you can run a program, script, write a registry key, or whatever. Here's a simple example using a custom installer class to show a message during the installation (in VB.NET but easily translatable):
Public Overrides Sub Install(ByVal stateSaver As System.Collections.IDictionary)
MyBase.Install(stateSaver)
Dim myInput As String = Me.Context.Parameters.Item("Message")
If myInput Is Nothing Then
myInput = "There was no message specified"
End If
MsgBox(myInput)
End Sub
You would need to follow the steps in the link to fully reproduce the sample.
You could use the .NET installer classes and wire those up from the default setup project. You override some methods and then they get called at install/uninstall time. Here's a tutorial on how to do this.
That said, a lot of people hate these .NET installer classes (and the default setup projects) altogether and implement true Custom Actions using a WIX or InstallShield based project.
Depending on what exactly you want to do and when you want to do it, you also introduce a .NET dependency. For example, if you are checking for .NET being installed, you won't be able to do this from a .NET custom action if the user does not have .NET already installed.
Adding Custom Actions is a bit of a slippery slope. Once people realize you can customize the installer, you'll likely be asked to do more and more. At that point it may make sense to use a more flexible tool (WIX (open source) or InstallShield ($)).
Related
I am trying to create installer using InstallShield and have requirement to execute some code during the installation process. Earlier I was using VS 2015 setup extension to create MSI but due to some advance needs in MSI we are planning to migrated to InstallShield and code that we were executing in onBeforeInstall / onAfterInstall of ServiceInstall also needs to be executed and as per my understanding we need to create CustomActions and for that requirement is to create functions and put them in dll file.
I tried to look into documents of InstallShield but wasn't able to find good way or example code that i can start with to write such code. I prefer to write in C# it will be helpful if some one can guide me to write function to attach with custom actions.
Help Material: The documentation included with InstallShield should have good information to get going? Installscript Reference. Also check the Installshield installation folder under Program Files - I think there are some samples there.
Installsite.org: Setup consultant Stefan Kruger's installsite.org has a number of coding examples for custom actions.
Github.com: You can search github.com to find samples of just about anything. Sample search for MsiGetProperty (used by most Installscripts).
Custom Actions: Managed code (Dot Net) has a number of technical problems for large scale package distribution. It is recommended that you use Installshield's proprietary Installscript language or straight up C++ (minimal dependency, static linking when possible). I don't have a nice summary of managed code problems, only this half-mad answer that was written some time ago.
I need to change version of Setup project in VS dynamically, from generated class? Can i do that?
All VS projects are basically text files, so theoretically you can do what you want, but maybe not from inside VS.
You will want to change the ProductVersion property of the project. In the text file, look for a line containing something like the following:
"ProductVersion" = "8:1.0.1001"
The "1.0.1001" part should be whatever your current version is. The 8: seems to be a type identifier; I would guess 8 means a string.
When you update the ProductVersion, you should also update the ProductCode. This is simply a GUID, so you can simply generate and ToString() a new random GUID. DO NOT TOUCH the UpgradeCode if you want the installer to find previous versions of your program and remove them.
This is all perfectly possible to do with a simple .NET program. Integrating it into a VS build is trickier, because the install project is not an MSBuild script like the others, so you don't have access to the kinds of custom build logic tools you have in MSBuild from directly inside the install project. You could set up your primary project's MSBuild script to include a build task to update the install project version when built, possibly. You could also set up a post-build action.
Here's an example of a script file you can use to increment that version number calling it from a PreBuild event of a setup project. (http://www.codeproject.com/Articles/22256/NewSetupVersion-for-MSI-Projects)
Read the issue raised by amthog in the comments though. The fact that the project is not reloaded after this script runs, but prior to the build can cause headaches. I have a post build event that is now failing due to changes made "externally" (by this script) which haven't been reloaded at the time the post build event runs.
If that doesn't concern you, this script seems to work well.
I have a c# solution with two regular projects and a setup project. One of the regular projects is an executable, while the other is a dll, that I also use in other solutions. The dll project relies on there being a certain event log source, that it can log to, and since the program is intended to be run by users that are not allowed to create log sources, this source must be created at installation.
I have done this by creating an installer class for my executable project, creating the log source in the installer, and included that installer in my custom actions in the setup project. This works, but now I have to create a similar installer for every other project, that also uses that dll.
The best solution would be, if I could write an installer for the dll, and then choose the dll for the custom actions in the setup project. This way I would only have to state the log creation requirement once. However, I am not able to select the dll project output for the custom actions in the setup project.
Another good solution would be, if I could somehow specify that the installer for the executable should be transitive, such that it would also perform install actions for any projects that the executable project depended on, but I don't know how to specify that requirement.
So what can I do to avoid duplicating installation code between different projects?
You should be able to add an installer class to your DLL then register the DLL for execution of custom actions in a setup project. If you have tried this and encountered problems, could you please be more specific about which version of Visual Studio and which type of setup project you are using?
I just have a MyApplication.Installation assembly where I put a custom action that creates the event source. All my setup projects reference this assembly and invoke its custom action.
How about this? You create a simple batch file or a powershell script to create the log file that you want to create.You could make an installer for the dll file(or even the entire solution it doesn't matter.) You can then invoke the batch file that you just wrote from the installer.[Refer here] . This way, you are not duplicating the creation logic for a dependent files/resources; and you can use the same batch file for multiple setup projects basically(provided they use the same resources.)
I hope this answers your question.
One step further, what environment are your clients on? Are they still on Win XP(SP2 or before)? If that is the case, you have to do something similar to what you already have in mind right now. However, if that is not the case, if your clients are on Win 7, You could use nuget to publish your bins(Refer here). I admit that this is still looked at as a source code sharing solution. But I believe that the approach can be extended to publishing binaries too.
I am using visual studio set up project to create my msi Installer.My requirement is to create multiple instances of the application using this same installer without changing version number/product code.
Is there is any way to do it without using Wix/Installshield.
Sorry, if you want to use MSI and install multiple instances, you need instance Transforms (i.e. changing the Product Code)
http://msdn.microsoft.com/en-us/library/aa369528(v=VS.85).aspx
Why don't you want to change the product code using and instance transform?
Windows Installer doesn't support multiple instances with the same Product Code and Upgrade Code. Product Version can remain the same. A different instance is actually considered a different product.
Multiple instances are not supported by Visual Studio setup project files and they are not easy to implement. The general approach is this:
Create a MST transform for each instance. Each transform should use a different Product Code and different component GUIDs.
Write a custom EXE bootstrapper which can apply these transforms to your original MSI.
Optionally find a way to include the transforms and MSI in a single EXE setup file.
Other authoring tools do offer support for multiple instances, but the instances number is usually limited. It all depends on how many transforms you create.
In my current project, I'm producing weekly releases. I've been using the technique described in this post to keep the version numbers of all of the assemblies in my project in sync. (I don't presently have any good reason to track the assemblies' version numbers separately, though I'm sure that day will eventually come.)
When I push out a release, I build a new version of the installer. Unlike all of the assemblies, which can get their version numbers from a shared SolutionInfo.cs file, the version number of the installer isn't, as best I can tell, an assembly property. So my release process includes manually advancing the version number in the setup project.
Or, I should say, usually includes doing that. I'd like to turn that into something I can't screw up. I'm finding the documentation of setup and deployment projects to be surprisingly opaque (it was quite a bit harder to find out how to make it possible for the MSI to uninstall properly if the user installed it to a non-default path, which is a pretty freaking common use case to be undocumented) and have no idea if it's even possible to do this.
Any ideas?
Edit:
Just to clarify, this is a Visual Studio setup and deployment project I'm talking about.
CodeProject has a script to set the version number of an MSI file, which you could run in the pre-built step of the setup project. You find it here:
http://www.codeproject.com/KB/install/NewSetupVersion.aspx
More Details
Be aware that with Windows Installer things are a bit more complicated. MSI files (as the one that you create using a VS Setup and Deployment project) not only have a version number but also a product code which is a GUID value. This product code is used by Windows Installer to uniquely identify your product e.g. in Control Panel -> Add Or Remove programs where you can decide to uninstall or repair a product.
However, when changing you MSI version number, this product code must also be changed in a number of cases. MSI technology is poorly documented but you can find some recommendations when to also change the product code on the following MSDN page: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx.
In my projects I always generate a new product code for every new version. The script on CodeProject will also change the product code for you.
And one more thing: Windows Installer only checks the first three places of the version number afaik, anything in the forth place will be ignored, i.e. 2.3.0.1234 is considered equal to 2.3.0.5678. (ProductVersion)
(There is a related article on CodeProject which might also be interesting to you: http://www.codeproject.com/KB/install/VersionVDProj.aspx)
Its going to depend on the installer toolkit you are using.
We use TFS Team Build and WiX v3. I have a custom build task that increments the build number in Team build (5.0.0.X for example), then this version number is pushed to the common AssemblyInfo.cs AssemblyFileVersion field. It is also passed by MSBuild to our solutions/projects as a property which is then passed into WiX and used to update the installer version as well.
We probably will need to do better with the assembly versioning someday as well, but right now this has been working pretty well for us.
I use a workaround for VS2010 Setup projects (.MSI + setup.exe). Open the .vdproj in Notepad and edit the ProductVersion assignment value (3.2.1 in the example below). Save the file and launch VS2010 by double-clicking on the .vdproj file.
"Product"
{
"Name" = "8:Microsoft Visual Studio"
"ProductName" = "..."
...
"ProductVersion" = "8:3.2.1"
"Manufacturer" = "..."
...
}