I've seen several articles online where people show how to create windows setup projects, and then subsequently use the same setup project to deploy updates as in: Updates to setup projects. When performing this sort of install though, the previous version is always uninstalled first before the new version is installed. I'm curious if anyone has found a way to create versioned folders to maintain the previous versions that the user has already installed?
Example:
On first run of the setup.msi, it creates the default directory: [ProgramFilesFolder][Manufacturer][ProductName][ProductVersion] -> C:\Program Files\Manufacturer\Product\1.0.0.
On each next update, it creates new directories as in: C:\Program Files\Manufacturer\Product\1.0.2
There are some cases based on certain configurations where for performing certain functions, we would want to use an older version, rather than the latest version. I know this may sound weird, so I'm not going to get into the reason for why. Just curious if anyone thinks this is doable through regular setup projects.
This is called side by side installation and it's not supported by Visual Studio setup project. Basically, you need to modify the upgrade rules to allow two different versions to be installed on the same machine.
However, each version functions independently of other versions. So version 2.0 shouldn't use files from the version 1.0 folder.
If you want to preserve existing files during an upgrade, you can try this approach: https://web.archive.org/web/20130513032659/http://setupanddeployment.com/installer-concepts/preserve-data-install/
Related
While upgrading my solution from version 1 to 2 using the new MSI, I noticed one of my custom actions which configure the application was using values which belong to version 1 (on the OnCommit action)
I added messageboxes and logs that print out the assembly version and confirmed that during an upgrade, the windows installer is using the dll from the previous MSI. However, if I manually install the newer MSI the correct custom action is used.
Is there a way to get around this? Have not found much information on why it uses the previous custom action?
I set the RemovePreviousVersions = true and UpgradeCodes are equal while ProductCodes are different.
I believe that this is an old bug:
https://support.microsoft.com/en-us/kb/555184
and there is another support article about it that I can't find. It may have been deleted because it applies to older versions of setup projects. I think the detours are things like renaming the assembly, and changing its assembly version.
The issue (as you might guess) is that the uninstall loads the assembly to do the uninstall, and the assembly from the upgrade install is identical as far as the load rules determine in this situation (reflection loading), so it does not load your new assembly but uses the older one that is already loaded. This all implies that you are using a very old version of Visual Studio setup projects that first uninstall the old product then install the new one. That hasn't been the default behavior since (and including) Visual Studio 2008, so I don't think you'd get the issue with a newer version.
I keep running into an issue with our TFS build server. I've got 2 projects (both in the same solution), 1 is a WebForms project, running .Net 4.0. The second is an ASP .Net MVC5 project running .Net 4.5. There is also a Silverlight project, but the problem is reproducible with just the first two.
Both of these projects use NuGet packages for various libraries. Sometimes there are different assemblies within a package for their respective environments. A .Net 4.0, 4.5, SL assembly, etc.
The build server seems to dump all of the libraries required into a single folder, then pulls from that to build the solution. This causes problems in many cases, with the wrong project getting the wrong assembly version. This does not occur locally, only on the build server. I can't figure out what I need to do to keep this from happening. Any ideas?
Yes, I hate this standard behavior, but TFS will output everything to the same folder by default, and then you will get various errors depending on which order msbuild compiles your projects if you have references with the same name or even project outputs with the same name.
The easiest workaround is to use the AsConfigured option on the Process tab, '2. Build' -> 'Output location' of the build definition window. This keeps your normal source structure intact, but I think you will lose support for automatically dropped outputs (i.e. you will have to provide a script to do that yourself). If you are only using TFS Build for validation, this is the cleanest approach.
You can also use the PerProject setting and split up your projects into two distinct solutions, perhaps suffixed by platform (we've done that numerous times in our company). Then, you specify both solutions to the build process and it will create two separate folders in the output, one for each solution.
This is all assuming you are using TFS 2013. In TFS2012, there is a similar option but it is in '3. Advanced' -> 'Solution Specific Build Outputs'. You will probably have to go this route if you are using TFS2012 or you will need to modify the default workflow yourself to add your own logic.
EDIT:
From your comment to the other poster I see you are using TFS 2010. Well... I think this was absolutely not supported at that time, I remember having similar problems, but we upgraded to TFS 2012 and all was well.
I think your only option is to either create two separate build definitions and build each solution that way, or you will need to checkout the xaml workflow and edit it with your own logic. Perhaps downloading the TFS2012 template and "porting" it to TFS2010 would be a better approach since at least you would not be reinventing the wheel that way.
Situation - We have a .net mvc solution with WCF layer. the solution has about 20 odd projects that get compiled into DLL. the site is running on SQL server 2008. we maintain the SQL scripts in the solution folder as versions. So we have SQL scripts eg. version 1.0.0.0 to lets say latest which is 3.0.0.1.
the solution is source controlled in TFS, we also use TFS to manage the work items, bugs etc etc. SQL script files are also in TFS
Question - the question is that do we need version numbers on the assemblied i.e. dlls aswell. Our DLLS are not exposed in any way or from to the outside world they are just in the runtime of the mvc app. we do not expose the WCF to outside clients,again its just used by the mvc app.
the deploy process is simplly the latest code against the latest db, so when we deploy we check what version the db is in and run a tool to upgrade it to the latest version that is in the db project in the solution.
One of our senior architects is saying that we should maintain the version numbers in the assemblies aswell. I am saying that we dont need any version numbers in the code. beacuse TFS manages that. when we release we just deploy the latest code with the latest assemblies/ deploy package.
I have not come accross the assembly versions unless them assemblies where released to the outside world (if you know what i mean)
please can you suggest... Also note we dont do feature development its just version numbers so that we know what version a particular DB is at.
I would prefer the security of knowing and being able to double check versions. If there were a problem with the publishing process, or there were a bug that manifested itself that appeared to be a publishing problem I would want to rule things out as quickly as possible. I also think that it's so easy to implement you've spent more time discussing and thinking about it than you would have actually spent doing it, and there is no down side to it that I can think of.
In a similar project at my job, we use version numbers.
Every commit against the version control system (VCS) causes our CI server (TeamCity) to build a new artifact, with the version set to "LATEST". Every successful build of "LATEST" get deployed automatically to our test environment. We could, in theory, also deploy this "LATEST" version to production, but we don't.
When we want to deploy a new version to production we run a different, manual build job which creates a versioned release (e.g. 1.4.7). The build job also creates an SVN "Tag" of the current codebase. To have our DLLs have the appropriate version, we use TeamCity's AssemblyInfo Patcher feature. This way, we don't have to constantly manually update our projects' AssemblyInfo.cs files. Instead, they get to always have placeholder version info like this...
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]
These number get automatically updated during the build by TeamCity. The versioned artifacts (which include any corresponding SQL scripts) are saved to our "Releases" directory where we keep all our versions of the codebase.
Now this all seems like overkill, right? Not really.
This gives us the following benefits...
Our deploy process does a wget to our monitoring page which lists the version number and asserts the versions match up (version expected to have been deployed vs. the version currently running on the server). This gives us confidence that our deploy process worked properly.
If bugs are found in the versioned release (the production release candidate), we can SVN checkout the tag, apply a fix, and create a new release without having to worry about other changes on trunk which could compromise the release. It is hard to stay "releasable" all the time, this allows to not have to be. Although, don't get me wrong, it has it's advantages.
If problems are found with a versioned release but they can't be resolved quickly, you can always just re-deploy the older artifact which is known to work. Being able to revert a deployed release to an older version has definitely saved us on a couple occasions.
If bugs are found on production that need to be investigated, we are free to deploy the same versioned artifact to any of our test environments so that we can try to reproduce the problems outside of our production environment.
There are probably more advantages I am forgetting at the moment but the above list should give a general idea of the power that proper version management can bring to the table.
What I would advise against is continuously, manually updating 20+ projects' version files. This seems like a lot of busy work which is mostly a waste of time because it is prone to human error. Whatever you decide to do, automate it and verify the results.
I am looking at making an application more modular and accessing dlls so that I can change them if the client was wanting different functionality.
I know how to create the dlls and reference them, but I am trying to find a way to create an executable that will install a different version of a dll into the required application folder. I want to avoid having to put the new dlls into the original project and build a new install file and I want to keep things simple for the end user.
Currently I am using visual studio 2010
You could create MSI files for each of your dlls and use the standard installer process to update the dll. It is also possible to write an exe that downloads and extracts which will have an arbitrary amount of logic (licensing, download location now and then...).
A combnation of both might seem an interesting thing. A bootstrapper downloading msi files and silently installing them. You could have advanced features in the installer while having the freedom to decide what and when to install on your own.
Technical aspects popping into my mind: files in use may not be changed and if you change the interface theunchanges main program won't be able to use the new library.
It seems you're searching for a plugin architechtecture, you might want to look at MEF or Unity to perform the compositiom, but that is more a side comment.
There are few SO thread available on this great website. You should explorer them and try the best way to implement whatever situation you have..
Check these reference links:
from: Creating a patch to upgrade .NET application
If you already use a a VS Setup Project you can deploy the new version
of this project and it will upgrade existing installations. Have a
look at the setup and upgrade ids. The stop and start of the service
can be done by custom actions that can be defined in the project and
will be executed i.e. when your setup is committed or rollbacked etc.
Patch development in DotNet
How to make Patch-able/Update-able application?
create patch file using .net windows application
Note: Ref this For clickonce how to build a patch for existing installer
I would like to create a patch for my .NET application. The requirements are:
Find the installation directory
Overwrite the old files with the new ones
Restart a windows service
I want to send the updater to the user so that they simply run it and update the application. My original installer is created using Visual Studio Deployment Project.
I did alot if research, and found this:
https://stackoverflow.com/questions/3767/what-is-the-best-choice-for-building-windows-installers
How to Update the installed Window Application (Creating Patches)
http://wyday.com/forum/viewtopic.php?f=1&t=245&p=793&hilit=offline+install#p793
http://www.advancedinstaller.com/user-guide/tutorial-patch.html
I tried created another installer which would just contain the files I need to replace, however I could not find a way to determine the installation directory of my application.
WyBuild seemed like a good solution, however they do not support an offline install and require you to host the update files on the server.
I tried creating a patch using Advanced Installer but it just generates a bunch of build errors that I could not fix.
There are tutorials how to modify the MSI files using Orca or WIX, but that seems alot more complicated than it should be.
I am tempted to roll my own but I am not sure how to go about it, and this seems like such a basic requirement that there's got to be a solution out there already.
If you already use a a VS Setup Project you can deploy the new version of this project and it will upgrade existing installations. Have a look at the setup and upgrade ids. The stop and start of the service can be done by custom actions that can be defined in the project and will be executed i.e. when your setup is committed or rollbacked etc.