I think that I have somehow screwed up my install project because my application fails during the installation project. So I would like to revert to an earlier version. My solution consists of 47 different projects and it actually works fine after installation, so I would like to keep the changes that was made after I screwed up the installation process. How do I go back to an earlier version in Team Foundation Server for a single project only?
All I know is that I have a working version from 03.03.2011 at 13:00 and a non working version at 03.03.2011 at 16:00. Please help me isolate the affected files.
Firstly you get get a specific version to overwrite your workspace with earlier versions of everything (by change set number, date/time or label). This would be a good place to start: verify that the earlier version works first (even if you recall it works it is always worth verifying). In Team Explorer right click for the Get Specific Version... command. From the command line the tf.exe syntax allows specifying change set etc. (see the documentation for details).
Once you know you want to roll back one or more change sets you need to use the rollback command from the TFS PowerToys (download link) command line tool tftp.exe (in TFS2010 this is part of tf.exe).
Related
I've been googling this all afternoon and I found any number of people ask the question, and all of the place a few people would answer it with the same things, and then there's a dozen comments by the rest of the world and the OP about how those answer don't fix it. So I'm going to include what I've tried here, and if your solution is to do one of the things I've already tried, I'm going to be very sad.
I have a solution in Visual Studio 2019 that has a class library, a wpf application, and a setup project (using the setup project extension). The WPF app also references a bunch of assemblies of course, but one of those is from another project I maintain in a different solution. I copy/paste the compiled dll after I update it from its own project to this one. Nothing tricky, everything works.
The problem is the installer. If I build everything and then build the installer, it produces an MSI as expected. If I right click on the project in Visual Studio and choose "Install", everything is perfect.
The problem is after I make some updates to either of the code projects, I then build both and build the setup project, and again if I right click to install it's perfect. If I run the MSI though, it doesn't always update the target files. If I delete the target files it will create them with the new ones, but it won't overwrite the old ones correctly.
AssemblyVersion and AssemblyFileVersion are both being incremented each time and are being kept in sync with the "Version" property of the setup project. I tested with these extensively, the new installer that isn't working properly 100% has updated dlls in it with correctly updated version numbers.
When I change the "version" of the setup, it asks to change the GUID for the ProductCode. I say yes, it changes the code. I have also tested without doing this and that makes it much worse as we all know.
"RemovePreviousVersions" is set to "true" in the installer project
If I right click the project and choose "Install" it seems to be 100% reliable at upgrading the existing installation.
If I run the MSI directly it seems to be 100% unreliable and never gets it right.
Side note, it does seem to usually but not always get the WPF application upgraded and the other project dll I bring in if I remember to update its version, but the class library (which is referenced by the WPF application) almost never works.
Has anyone got this to work reliably?
For all the people finding this in the future, here's the final word:
The build project can be inconsistent, this is well documented all over the internet as I have above. You're not doing anything wrong - it is just inconsistent.
Stop trying to solve it if it's affecting your project and move on (I've had a dozen projects before this one work just fine). The consensus seems to be to use WiX, but I'm not here to discuss the alternatives. Personally I am going to embark on the WiX learning curve though.
I am having the exact same issue/error as this post from yesterday. Similar SO Post
SIDE NOTE...As you can see, I am new and therefore, only have 45 reputation. As such, I could not simply add a comment to the above existing post and had to create a whole new post even though they are the same issue....seems silly. But I digress....
I wanted to provide additional comments in the hopes to get an answer. My issue started suddenly the a few days ago. I made no major changes to references, VS updates, etc... However, when I right click my csproj in visual studio, I get the error and I have to click it five times before it goes away, at which point I finally get the menu.
Again, I have made no major changes BUT I went ahead and confirmed that:
My target version and Min version is Windows 10(10.0; Build 10586). That is the SDK version that I have installed and am using.
I verified that my NuGet updates are complete and that my Microsoft.NetCore.UniversalWindowsPlatform are installed and update to date (5.2.2 as of now).
I do have a reference also to "Universal Windows". This was created automatically when I created my project and I cannot remove this reference but it is there. When I select it, I do see that it is "UAP,Version=10.0.10586.0" so this should be good. I do notice a possible issue here. Again, this reference was created for me and I cannot remove or change it. However, it is pointed to a folder named
C:\Program Files(x86)\Windows Kits\10\References\Windows.ApplicationModel.Calls.CallsVoipContract\1.0.0.0\
Why did the Windows Universal reference default to that folder and only that folder? I am not using VoIP so I wonder why it chose this one? Also, what if I need some of the other references in the References folder?
I created a brand new Windows Universal project and the same error happens on a fresh project.
Please help, it is annoying. Project still seems to build and work fine though.
Thanks!
I found the issue in my case, it was an extension that I added on to Visual Studio provided by SyncFusion (which their installer actually creates 7 or se extensions in Visual Studio). After troubleshooting my issue and doing some of the same things to resolve (repairing .Net, SDK, Visual Studio) I then thought about the error a bit more. While it is cryptic (and has poor english "An Exception has been occured") these are all clues that it could be any of the frameworks that I have installed via extensions as well.
I also had another clue, the issue started happening a few weeks ago, around the time I updated my SyncFusion controls to the latest version.
So, I went to Tools > Extensions and Updates. I went to Installed > All and found all of the SyncFusion items (there are several) and disabled them all. After I disabled them, and restarted Visual Studio, the problem went away!!!
This is a workaround for now. In the meantime, I put in a support ticket with SyncFusion on the issue. I will certainly update this thread when I get a response from them. Also in the meantime, I then went back and re-enabled each of them again, one at a time, to see who the real culprit was. In my case it was the SyncFusion Web Conversion and Migration extension.
If any of you are not using SyncFusion but having odd Visual Studio issues such as this, I suggest doing something similar by going through your extensions and disable any that you added on, starting with the most recent add ons, especially if they were added around the same time you started having the problem until you find the culprit.
Hope this helps!
I made the mistake of changing a subroutine in a project and publishing it. Now I want to revert back to the older subroutine. Is it possible to find the older project and retrieve the older subroutine?
Team Foundation Server can do this for you. You can now be set up without any hassle on your developement machine. The integration in the VS Team Explorer is seamless. Very easy to handle. See this guide for working with source control projects
https://msdn.microsoft.com/en-us/library/ms181384.aspx
Even easier and not so much overhead on your machine: sign up for Visual Studio Online (free for a 5 user team). The cloud source control is set up in minutes. If you are not against saving your data in the cloud give it a try.
https://www.visualstudio.com/en-us/products/what-is-visual-studio-online-vs.aspx
The alternatives (SVN, GIT) are also very good (consider reading about the difference of central and decentral source control) but need a little more knowledge and a good workflow.
If you happen to have lost changes before installing version control there's nothing you can do in visual studio. You can try a restore on file level (the option would be previous versions in the windows explorer)
as source code is plain text. There`s a "previous version" mechanism of windows explorer! Just go to the properties of your project folder
Note: previous version / shadow copying must have been enabled before or else the tab will be blank.
No, it is not possible unless you have stored your code in source control. It sounds like you have not yet done this, so I suggest using this is a (harsh) lesson and make the next move the one to install some kind of SCM.
You can signup for a free version of TFS online from microsoft the will integrate directly into Visual Studio. That will allow you to instantly check in changes and view the history of files and in this case, get a previous version of a file.
https://www.visualstudio.com/en-us/products/what-is-visual-studio-online-vs.aspx
Just had 2 questions.
1) I am writing a simple program in C# just to test out how to set up updating, However the program automatically updates ( I am using ClickOnce) and I was wondering is there any way to prompt the user to update?
2) I am publishing my project to a localhost, and I have published it about five times (v 1_0_0_1 - 1_0_0_5) and the folders are stored as such, however, when I publish, it changes ALL of the different versions, not just the latest one. I am trying to allow version control where I can allow a user to go back to a previous version.
Thanks in advance!!!
After the user installs your app for the first time, every time after that when the application is started it will check for an update. If there is an update it will ask the user if they want to update to that version.
This happens by default and you can even prevent them from opening the application if they select not to update. (Preventing the program from opening if the user does not update is not the default configuration but can be set in the publishing wizard or properties of the application)
Also you should know that publishing the application will not cause you to lose or overwrite all of your previous deployed versions. They are all still there under root/Application Files. You will see the latest version though because the app will look at the manafest file and that will tell the app which version to run. If you wanted to push out a later version you would change the manifest to point to that version.
However, a single user will not be able to choose which version they want. Once they choose to update they will be on that version until you push out a different one. This is for security and compatibility so that your users are on the same version once they choose to update and you don't have a bunch of different people running different versions whenever they feel like it!
I have a Windows service written in C# using VS2005.
The installation is via a wizard that calls msiexec to install the msi file also created using VS2005.
I am having trouble generating an msi file that will upgrade from one version of the service to another. The wizard program handles detection of the currently installed version, stopping the service, coming up with an appropriate command-line for msiexec and then re-starting the service.
The existing msi has a version property of 1.1.02, the new one is 1.1.03. The product and upgrade codes are identical.
Uninstalling 1.1.02 manually via add/remove programs works fine, as does installing 1.1.03 onto a "clean" system.
Upgrading 1.1.02 to 1.1.03 goes through the motions but the end result is 1.1.02 installed.
The command line that the wizard uses for upgrading is:
msiexec /qb /i "MyProduct.msi" REINSTALL="ALL" REINSTALLMODE="vos"
Where am I going wrong? I'm assuming I must have missed something fairly fundamental...
The fall-back position is to inform customers that they need to manually uninstall 1.1.02 before running the wizard to install 1.1.03 but I'd rather not have to do that.
Edited to add:
Changing the product code (as VS2005 also prompts you to) actually removes the ability to upgrade at all, as it the installer won't let you do a reinstall if that product code hasn't previously been installed.
All it will then let you do is install (and then you get the usual "service already exists" -type message).
There are several things that need to be done to get "upgrades" to work with MSI's if you want to automatically remove the previous version.
First some background information about the mysterious "codes". There are 3 codes (GUID's) associated with an MSI:
Package Code - This identifies a particular version of the MSI installer and should never be reused across builds. It must always be updated.
Product Code - This identifier is used to ID a particular version of the application. It is up to the installer author to decide when to assign a new product code.
Upgrade Code - This identifies the application and should not change through it's lifetime
The Upgrade Code should never change. For you upgrade scenerio, the Product Code must be changed for each version. Additionally, as you mentioned, you must bump the version number. The Product Code and Upgrade Code can be found by selecting your setup project and going to the Properties Window. The Package Code is hidden in Studio and will always be updated.
The item you are probably missing, is that you also need to set the RemovePreviousVersions setting in the Properties Window to true.
One more thing in addition to mohlsen's answer (For Visual Studio 2008):
In order for your Primary Output (your EXE!) to upgrade properly, you must increment the FILE VERSION
This setting can be found in the Project Properties: Application Tab -> Assembly Information
An easier way to manage this is to REMOVE the AssemblyFileVersion from all assemblies, including the main executable and all the managed DLLs.
In each of your AssemblyInfo.cs files, I recommend doing something like this if you don't care about the version numbers, but want to have some traceability.
[assembly: AssemblyVersion("1.1.*")]
// don't need this [assembly: AssemblyFileVersion("1.0.0.0")]
Everything still compiles fine, and if you don't have the AssemblyFileVersion defined, then the installer assumes that everything is different every time (which is probably fine if you are installing all of the DLLs next to the main EXE).
I spent a long time figuring this out, especially if I don't want to have to increment anything manually!