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.
Related
I am working in the enterprise on Visual Studio 2013 and Team Foundation Server. We have a test source and a production source, and I Get Latest on them both regularly. As there are only a few developers, we make changes directly in test, we don't have personal branches off of test (though when our shop was bigger, we did).
So I opened a file in Test, made a simple change to it, saved it, checked it into test, and published it to production. When I went to merge Test with production, I spawned a merge conflict. I am looking at the "server" version and the "local" version and neither one is correct. The "server" version is the file I edited, minus the edit I just made. That makes sense. But the "local" version is something I haven't seen before, what looks like perhaps an older version that I've never never worked on. Maybe this was my local copy and Get Latest didn't update it. But the local file I edited was exactly what I expected it to be.
So, what could cause that? How do I troubleshoot this problem? All I want is to get the correct version in TFS so it doesn't get blown away later, but I have no idea how to proceed.
This may due to when you do the get latest option, TFS didn't update the workspace correctly.
A clean way to do this, back up your file with changes, undo your pending changes. Delete the old workspace, create a new one. Get latest version from server for both test and production source.
Edit the specific file with changes, check it into the test, and finally do the merge Test with production again.
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
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?
I am new to TFS. (using TFS 2012 and vs 2008)I may be asking some very basic questions. How to make the TFS build fail when number of warnings is increased compared to the last build? I am willing to write vbscript/perl for it.
Finally I also want track also is there a new warning type compared to the last build?
If some guidance is provided.
Will it better be integrated as postbuild event?
Do i need to create a new Build Quality(in msft jargon)?
Check below article explaining how to do that. It has link to the Xaml file as well.
http://blog.stangroome.com/2011/03/28/fail-a-build-when-the-warning-count-increases/
You might be able to use something similar for your second question about warning type as well.
I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.