I'm looking for a way to prompt a user when a new version of a project they're working on is checked in. I've gathered that there is a way to automatically Get Latest Version but it was removed from later versions of Visual Studio in part because it's considered bad practice.
What I would like to be able to do is prompt the user (rather than doing it automatically) with the option to Get Latest Version - or merge their work, probably - if the version they're working from is older than the newest checked in version. Is there a way to accomplish this?
I'm fairly certain there's no way to do this within Visual Studio (if I'm wrong in this, please let me know) but is there a way to write a script or something that uses something like the VS/TFS command line commands to perform the check and throw the prompt to the user?
Thanks!
This is really a training issue. Every Developer should do a get latest before they start coding, and before they commit.
This is a basic practice and removes the need for complex customisations.
In TFS, you can work with alert systems to subscribe alerts when there is one new version for controlled files. Subscribers will have one email, and they will determine whether to get the newer version based on their requirement.
You can subscribe to get the alert with the Checkin alert category:
Please check this MSDN article for the details on configuring TFS alerts: https://msdn.microsoft.com/en-us/library/ms181334.aspx
Related
I am not sure whether i can the problem good explaning. Well we use TFS for our building. And in our VS solution, there is also an installshield setup project.
Well, sometimes our team members forget the increase products' versions that why we want to give the version number automatically generated like 3.7.1.*
so when we build the project, the version of our product dll/exe will be 3.7.1.5655
and let say we've created the following versions
3.7.1.1234
3.7.1.5678
3.7.1.9134
and we gave the product Version 3.7.1.5678 to our customer. And after a while, the customer said that there is a bug in this version and the version number is 3.7.1.5678.
So, as I said earlier, we made the version number format like 3.7.1.* and we commit always like that so the assemblyinfo.cs file will not be changed. and when the customer said that the version 3.7.1.5678 has problem. how can we find the related version what the customer has, in tfs commit. Let say we committed several time in the same day and we cannot see (or i dont know it) where the version number 3.7.1.5678 has been stored.
Well, I need to find the realted commit and work on this time project but i dont cannot know which commit it was.
My question is that how you solve this problem?
I hope i could explain it.
We have TFS Version 16.122.26918.3 and we use mostly Visual Studio 2017
You could find the corresponding build of version number which is 3.7.1.5678.
For a particular build, it's easy to get related changeset/commit.
Then you could pull down that changeset/commit from TFS to your local workspace, and work on the bugs.
Not sure what your build number looks like, it's better to make a part of build number the same as the last version number(5678), like the usage of $(BuildID).
$(BuildID) is an internal immutable ID.
I've inherited an InstallShield 2013 InstallScript MSI project that installs our product and I'm really new to IS. I've figured out the basics and even created an new project, but this has me baffled. One of our installers uses SQLServerSelectLogin (or at least I assume that it does) to get the user to select a SQL server to install to, and just recently it stopped populating with the list of installed servers and I need to figure out why.
I've rolled back just about all of the changes that have been made since this started being an issue and it's still happening. (The changes that I haven't rolled back are really minor and shouldn't effect the install). Being new to IS I really don't even know where to look for this to debug it. So my questions are:
Where would I find the code that populates this list?
How can I debug an install to figure out what's not happening?
I found an obscure post that describes three files that need to be downloaded and installed. Doing this fixed the problem.
Is there an extension to show something (text, icon, whatever) when current project under TFS receives an update?
My problem: I am constantly forgetting to do "Get latest version". Seeing something should help.
P.S.: sorry if it's an offtopic, but I recall question regarding programming environment were allowed here and I am not asking for a library... unable to check for sure due to missing Help in the new shiny top bar.
No such extension by default. The easiest way would be creating an alert as #Richard mentioned. When there is a check-in under a team project or a specific path, you would need to perform Get Latest, so you can create a Checkin alert.
Alternatively you could add a script to your source control. In this script, you can use tf get command to do get latest. You can always run this script when you would like to run.
I've been bumping into an issue lately where developers on our team (mostly me) have a tendency to open a project and forget to Get Latest Version before coding and we end up making new changes to old code.
It'd be nice if Visual Studio would know that I'm about to make new changes on old code and either warn me or automatically grab the latest version for me.
Is this possible?
EDIT: I forgot to mention I'm using TFS
Good question, and fortunately for you the answer is 'yes' (since you're using TFS as specified in your comment).
Go to Tools > Options > Source Control (on the left) > Environment and ensure 'Get everything when a solution or project is opened' is checked.
I must add, though, settings like this shouldn't really be used as a substitute for good habits and best practices. You and your team should be aware of the importance of 'get latest' to the point whereby you want to get latest and don't want to work without it (if you're at that stage in the project).
Potential 'downsides' to this:
On the odd occasion, you'll hear our team members say "don't get latest yet". Because of a bad check-in they've made. If they break the build - you'll get that broken build. Not an ideal scenario, it should never happen, but the reality is that it does. You lose an element of that control if it does it automatically.
Not to mention the fact that if your team are forgetting to get latest, there's an even bigger chance of them forgetting to check the changeset for potential issues. The 'resolve conflict' dialog doesn't always highlight every issue you need to be aware of.
I suppose a really minor downside could also be the start-up time of the project (one of the reasons Microsoft more recently got rid of this feature as you mentioned). You're not just opening a solution anymore, you're opening it and waiting for a get latest. Which could, then, require further attention (conflict resolution).
I'm possibly rambling now - but what about when you take on juniors that might not be familiar with source control concepts such as get latest? If it's always been taken care of, they might miss a trick. For example, hypothetically, VS opens but fails to connect to the TFS server as it's temporarily down. Could this cause an already forgetful team to explicitly get latest at a later date?
We have an installer solution written in Visual Studio 2005 Installer; that calls a C# custom action and we have hit a known issue, regarding the fact that on an upgrade - the old install code is run and not the new code, because Windows is running a cached version of the custom action dll. We know this and although not over the moon about it - we have moved on.
When we release a new version of the installer and a user runs it, we now want it to check to see if an ealier version is installed - if there is one; we want to display a message telling them that they have to remove the old version via Add/Remove Programs. We know if they do a manual uninstall followed by an install, then all is fine and dandy - BUT it doesn't matter how many times we tell our users, via documentation; that this is what they have to do - they will still try and just run the new installer, without removing the old version first.
Therefore, we would like to put up a message and thus force them to to what they are told !! I've seen some installers do this ( though of course not sure what installer package was used to create these ). We only have VS 2005 and of course orca !!
Cheers,
Chris.
This can be done through a custom launch condition:
create a search which determines if the old version is installed (you can search for a component, registry entry or file)
use the search property as a custom launch condition
For example, if the search property is OLD_VERSION, the launch condition can look like this:
Condition: NOT OLD_VERSION
Description: An older version was found. Please uninstall it using "Programs and Features" in Control Panel.
When OLD_VERSION property is set to a value (an older version is found), this launch condition will show the message and stop the install process.
This doesn't quite make sense. Have you remembered to change the package GUID in your new setup? The package GUID identifies a specific setup file, and if two MSI files have identical GUID they will be treated as the same file regardless of whether they are or not. This could trigger a cached version of the MSI to be invoked and all sorts of hell breaks loose.
I would recommend reading up on "major upgrades" which will allow automatic uninstall of the existing version before the new version is installed. You also need to make sure you understand the basics of the technology before deploying to the wild. You must NEVER use identical package GUIDs for any MSI files. It's practically always wrong, and will lead to very mysterious problems.
I can't write up the whole major upgrade solution here, but basically it involves authoring the "Upgrade" table of your MSI to detect versions to uninstall. You need to change the package code, product code and version number (only 3 digits matter) and keep the same upgrade code (two MSI files with the same upgrade code "know" they are related - i.e they are from the same product family). Check MSDN for samples of major upgrades.
NB! If you have deployed MSI files with duplicate package GUIDs to your developer machine, it could have stray installs that must be cleaned up with MSIZap or similar. Use caution, or better yet test your new installer on a clean test system. Developer systems are full of junk and not generally good for MSI testing.