I am creating a setup msi using a Project Output (Say Project-A), which refers another project (Say Project-B).
When i update application using new msi, dll of Project-B does not get updated though latest build contains some changes in Project-B
Note: When i uninstall the application, dll of Project-B remains in installation folder( not deleted).
It's not clear what you mean by "update ... using new msi" but the way you upgrade using Visual Studio installer projects is to increment the setup project's version and accept the changes, which include generating a new ProductCode. RemovePreviousVersions also needs setting to true. This should help and is still relevant:
https://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
In addition you must increment the file versions of files you need replacing - it's not enough that they are just different.
Related
This question is a complement for the post How to change the output name of an executable built by Visual Studio.
After reading this post I did the following:
Firstly, I followed the answer for this post and I could define the executable file name successfully.
Now, I would like to know if instead of only define the name as "Demo.exe" as mentioned in the example post above, it would be possible to embed the version defined in AssemblyInformationalVersionAttribute or in AssemblyVersionAttribute in the built file, resulting in something like "Demo_v1.0.0.0.exe"?
I'm developing my application in C# WinForms, using Visual Studio Express 2017.
Why would you want to change the name of the executable? Whenever you try building a Setup for your application, you need to change the Setup to include the new file. And when you install an update, your Setup needs to know all versions of your executable in order to delete the old version. That's just not what you want to do.
If you want to keep all versions of the software for yourself, come up with a different solution, e.g. moving the executable into a folder which has the version number.
That said, I have done this for Setups, so customers can download different versions of the Setup. I did that using a commercial tool called Visual Build, but there are other build automation tools available. So, my answer is: set up a continuous integration / continuous delivery pipeline (CI/CD) and automate the step there, not in Visual Studio.
From the project properties, you can add Post build event command line to rename your exe
pseudo
Maybe you can create another console renamer.exe which reads version defined in AssemblyInformationalVersionAttribute or in AssemblyVersionAttribute of your app and renames it and then call that renamer.exe from Post build event command line
write a powershell script to rename the newly built exe and call that script from Post build event command line
I have made a msi project for my software in VS2015. I have made a.Net based desktop application. My requirement is that I would like to handle 2 cases :--
1- If our software is installed already, and user try to install it, it should automatically un-install existing software and delete database file (created by my application).
2- If installed version is lower then it should only uninstall application and leave my database file as it is.
Now in my setup project I have added Custom actions for install and un-install where I have given path of my dll and set Installer Class property to true. In this dll I have made a class inherited from System.Configuration.Install.Installer and handle Install , beforeInstall, uninstall like below :--
public partial class SetupManager : System.Configuration.Install.Installer
{
public SetupManager()
{
InitializeComponent();
this.BeforeInstall += SetupManager_BeforeInstall;
//this.Committed += new InstallEventHandler(DarkMailInstaller_Committed);
}
private void SetupManager_BeforeInstall(object sender, InstallEventArgs e)
{
MessageBox.Show("In Install event");
}
}
Now in un-install, I delete DB. it is working fine if I am un-installing from control panel and it removes my DB file as well.
But if I want to upgrade my product, before getting hit in my override function Like install or BeforeInstall it shows error "Another Version of this product is already installed. Installation of this version can not be continue. To configure or remove the existing version of product, use add/remove program of control panel".
Now I have searched on internet and it seems if I update my package code or product version, it should be able to install over it. Now I have following issues :--
1- In VS 2015, I dont have any property in setup project where I can set product version or package code ?
2- I have tried to edit it using Orca but even then if I try to install edited MSI file (with updated version number, package code and product code), I am facing same error.
3- I dont know why this this error is coming before executing Before-install event ?
4- I have found "RemoveExistingProducts" would be helpful in this case. But I can not find this property / action in VS2015. Where can I find it ?
Can some body please help me to solve this issue ?
In a Visual Studio setup project it's the RemovePreviousVersions property of the setup project, in with the other properties like Manufacturer, Version etc.
Increment the setup version's project version, accept the changes.
Set RemovePreviousVersions to true.
The UpgradeCode needs to be the same, so don't change it.
Increment the file versions of the binaries you need to be updated.
If you select the setup project in solution explorer and do F4 you should see the relevant properties.
Don't worry about PackageCode because Visual Studio creates a new one with every build, as it should.
Visual Studio custom actions all run after the files have been installed (despite the "before" name), so there's nothing you can do to influence the course of the installation. In any case you don't need them.
What you get is an MSI that will install as a fresh install to new customers. It will also upgrade an older product as it installs, and the Windows Installer overwrite rules mean that a data file updated by the application will not be replaced.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370531(v=vs.85).aspx
The generated MSI will have a RemoveExistingProducts sequenced towards the end of the install. Basically you don't need to worry about the internals of PackageCodes and so on because Visual Studio hides them.
We are working on a WPF application and we have used Install Shield Limited edition to create the installer of the application.
As per requirement we need to keep a “Key” and “Value” in the app-settings of the “app.config” file. “Value” will be dynamically generated at the time of installation and it will be different when we update to new version(installing the new versions of the application).
I found that each installation time app.config file is overwriting. How i get the old config “value” when we installing new setup.
Can i get the old value from an installer class?
You can do it in custom actions, it is like PreBuild/PostBuild actions in Visual Studio. If you are not comfortable with scripts (neither am I), you could write two executables in C#, one to be executed before overwriting the old files to get the old values, the other to be executed after installation to restore the old values.
I want my WPF application publish version. I tried using the answer for this question. It works but the problem is we can manually change the values there. I want to know how many times my project was actually published (don't need version number. Just how many times did I publish my application). Can this be done?
Using Click Once, each time you publish, Visual Studio will change the number automatically. It will increment the value each time you publish. Your problem is that you have manually changed the number. The solution is to publish and just let Visual Studio update the value... you should notice that your project needs to be saved once you have published. This is because Visual Studio just incremented the value for you.
UPDATE >>>
If you want to access the published version from code (which you should have made clear in your question), then you can use this code, but you have to ensure that the application is network deployed first... that means that it has actually been published, so it won't work while you are debugging. Try this:
private string GetPublishedVersion()
{
if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
{
return System.Deployment.Application.ApplicationDeployment.CurrentDeployment.
CurrentVersion.ToString();
}
return "Not network deployed";
}
You may be confused by 2 sets of numbers. Please note that you can set version of your WPF app in TWO different places:
Project Properties / Publish tab / Publish Version
AssemblyVersion declared in AssemblyInfo.cs file, which you can find if you expand Project Properties node in Solution Explorer.
They are similar in the sense that they both provides 4 numbers: major, minor, build and revision. The difference is that Publish Version is only available if the app was actually Published (i.e. Installed). It is not available in your debug session nor if you just copy the executable to another machine and run it there. SO, if you just need to track version of your EXE file, use AssemblyInfo.cs.
Correspondingly, to read the data use the following code:
1 To read Publish version (declared in Publish tab)
using System.Deployment.Application;
ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString();
Note that in this case: a) you need to add reference to System.Deployment assembly, b) if the app was not deployed, it won't work.
2 To read Assembly Version (declared in AssemblyInfo.cs)
Assembly.GetExecutingAssembly().GetName().Version;
This one always works.
Universal solution if we get application version from not startup assembly:
var version = System.Reflection.Assembly.GetEntryAssembly().GetName().Version;
string appVersion = $"{version.Major}.{version.Minor}";
GetEntryAssembly give version of startup project.
var obj=Assembly.GetExecutingAssembly().GetName().Version;
string version= string.Format("Application Version {0}.{1}", obj.Build, obj.Revision);
OR
string version= string.Format("Application Version {0}.{1}", obj.Major, obj.Minor);
whichever properties suits you.
I have created a setup project for Windows Application . I have set following property to replace the existing version with the new version.
RemovePreviousversion=True;
Productcode=change;
But when I run exe from new installed version. I cannot see my new updates. It gives me the output of previous version!
The whole Explanation is Here
I have RemovePreviousVersions set to TRUE and InstallAllUsers set to TRUE.
When I need to do a new release, I update the Version field with a new version number in the installer and VS prompts me to update the product code, to which I answer YES. I have verified that it does indeed change the product code, but the package code also gets changed with it (verified by diffing project files using sourcesafe).
The UpgradeCode never changes between versions.
My version number changes are of the form: "1.1.2" -> "1.1.3" for example (just in case that has anything to do with it).
So only 3 fields are different between builds: ProductCode, PackageCode, and ProductVersion.
When I've done all that, I build the installer.
When I install the new version (I always install for all users and always into the same directory), I have seen three different results at various times:
It will appear to in install the new version, but I really end up with the old files still there (and one instance in the add/remove programs).
I end up with 2 instances of the app in the add/remove programs, both with the same name, and both pointing to the same directory.
It will uninstall the old one first and then install the new one (what it is supposed to do).
It is very frustrating to explain to users that to be safe, they have to uninstall the old manually before installing a new release because I have to tell them "it doesn't always uninstall the old one like it is supposed to".
Any suggestions? Why isn't this working? What am I missing here?
I Found answer.
Also need to change AssemblyVersion and AssemblyFileVersion in AssemblyInfo.cs