I made some changes to my website, then had to reformat my server, and over two weeks I tried to undo what I did (it was a stupid forum thingy). Obviously I missed something, becuase now I have the dreaded Build Failed With No Error problem.
This is my home server, so no I am not running source control.
After staring at it for a few days, I decided to try somehting. Today I allowed VS to run the last successful build, and it still works.
QUESTION: How can I go back to the last successful build? I don't care about any changes made since it worked. That's really all I need.
THANKS
Have you checked to see if you have Previous Versions available?
It sounds like you won't likely be able to recover the source files / project config, though you could certainly attempt to recover the "source" by using tools like ILSpy or .NET Reflector. You can use them to examine the output assemblies, and reconstruct your code if necessary.
As a lesson learned, both Mercurial and Git work wonderfully for versioning home projects - I'd give a slight nod to Mercurial in your case as it works just a tad bit easier on the Windows platform.
Related
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'm very new to Visual Studio and Universal Windows Apps Development. As a part of the course, I have this codeSHOW project provided.
I've cloned it successfully in VS 2015, but I can't run the project using the .sln file. Error:
Here's the error log: http://pastebin.com/c012Bba4
I have no clue how to fix it, and the issues on github go unanswered so I can't expect much from there.
This is an known issue in Visual Studio 2015.
The problem is with files with the exact same name under different folders in a Shared project, which in your case is "resources.resjson".
The only workarounds are either to make the file names unique and if that is not an option, to duplicate the files in the projects instead of sharing them out of the Shared project.
This is a VS2015 specific bug, the solution loads just fine on VS2013. You can get some insight into what is going wrong. First note that your got two message boxes that announced this error. Barely visible in your screenshot.
The failure.txt file gives more hints, you can see the stack traces of the two AggregateException that are raised when the solution is loaded. You'll see that two tasks are trying to load the same resources.resjon project item. Not correct of course, quacks like a standard concurrency bug.
Nothing actually goes wrong, Visual Studio can handle the exception and declares it "Recoverable", the projects are still loaded correctly. And compile just fine. Only other thing you need is the Bing Maps SDK, you can download the correct version here.
If you have VS2013 then prefer that version, it doesn't have this bug and loads the solution without any complaint. And minimizes the odds that you'll run into other quirky problems. Given the current stability of VS2015, not great, it is the best way to avoid losing time. Otherwise just ignore the mishap and close the message boxes, some future Update will no doubt fix the bug. You can report it at connect.microsoft.com if you wish. Not actually necessary I think, it looks like VS is phoning home.
Actually I have faced this issue many time during working with SVN. Most of the time I am working with VSS for source control but since last couple of months working with SVN.
We are using tortoise and AnkhSVN with VS 2010.
In our team there are 5-6 people and some of them are working on same file at a time. Now when somebody commit , we have seen that some other developer changes get vanished and Sometime we get some line with version number. This thing get consume lots of time and we have to resolve conflict and all.
Please provide information so we can avoid such issues.
If two developers are working on the same file and make changes to the same are of code, then you have to manually resolve this conflict. There is no way to avoid it, no matter which version control you use.
The version control cannot know what the correct code is, so it requires a human intervention.
There is no way around this, other than preventing the users from working on the same code. this is done in svn by locking the file.
Each developer must svn update before svn commit. Between the update and commit, the developer must do a full, clean build and run all tests to make sure their code still works after merging in all other developer's changes into their copy.
You can set svn:needs-lock on files or folders that need to be locked before making changes, they'll be forced to check for locks. When you will try to edit a file, you will be required to lock it first. And when it is already locked by someone else, they you get an error message, preventing you from making any changes. This can be done in Tortoise SVN in Properties -> Advanced
I have a project that is source controlled using TFS. I was doing some coding on my laptop when, unfortunately, my computer crashed and I ended up having to re-install Windows. I was afraid that all my code would be lost, but thankfully I was able to restore the code files.
My problem is that now I need to commit the changes to TFS. Currently the projects do not have any source bindings. I can't overwrite the current code base because there is work that has been done since my crash by other devs.
How can I add the changes I've made to TFS?
The way i've done something like this is kinda hackish, but what i usually do is get latest from TFS onto my laptop, and checkout all of the code from the project in question. Then i take the changed code and copy it over that folder, check it in. TFS should be smart enough to only really affect the actual code items that have been changed. You can see in the history the actual files that got changed to be sure.
If you know the exact files that you need to update, then that will make things much easier, because you can do the above steps, but then just check out the particular files you know of. You can do a compare between them and your new code to make sure that you don't overwrite anything your other programmers have done. Again, hackish, but i don't know of any streamlined way to do this.
You might want to make sure that you download the TFS visual studio extension, since that will give you rollback capability.
We've only recently begun using TFS (2008) with Visual Studio (2008). A couple of developers discovered the "Get everything when a solution or project is opened" option in VS and decided it was a good idea--and it would seem to be.
However, we've been getting some curious results when opening some solutions. The solutions in question contain several projects of mixed types--mostly class libraries and web apps. The curious part is the list of files in the "Get" dialog box that comes up.
Here's what I've found out so far about the files in the list:
The list is incomplete; not every controlled file in the solution is listed.
The version in the workspace matches the version in source control.
They are not missing from the workspace.
There are files from each of the projects in the solution; though, not every file in each project is included.
The list of files is the same for three seperate developers on three seperate machines.
Running a tf get from a command line does not yeild the same results.
Any insight into this would be greatly appreciated. As I mentioned, this option seems like a good idea, but we're a bit hesitant to rely on it when the results are unexpected.
Thanks.
I know that any files that are not in any project will not be pulled down by TFS when you go to get a latest at the solution level. My guess is that is part of your mixed/unexpected results.
I personally do not have that option checked. I always pull everything down from source control first thing. Whenever I check in source code, I also pull down everything again, compile it and run it first. That way I do not introduce any issues into TFS.
I would make sure that everyone on your development team is using the same general settings for TFS source control. I always have it prompt for check out (saving/editing) and get latest version of item on check out.
Have you applied the latest SP for TFS 2008 (SP1 last I remember). And SP1 on each developer's machine as well?