I have done a bit of googling, and I cannot seem to find a solution.
I work on a VS 2013 project with 1 other person. Some times the developer doesn't check everything in, or has errors in the code. I do not always have the ability/authority to make the other developer to correct the errors.
How do I continue being able to compile the parts of the project I am working on, with out having to ask the other developer to check in or solve the errors.
Just to clarify, we are working on two separate forms/files that do not interact with each other. Is there a way to compile the current form I am working on, and run from the last successful build on the forms that have errors?
As the Title says,I am using TFS, and maybe that can be part of the solution?
Is what I am asking for possible?
You should implement a gated check-in build in order to prevent developers to check-in code that doesn't compile.
If they really want to put the code that is not complete in Source Control they should use the shelvesets.
Related
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.
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.
my team uses Visual Studio for our development environment, we like it very much
we use the same project files in our automated build
our problem is that it's so easy to make changes in visual studios UX that get applied to the project files. we're seeing frequent build breaks
...I know...I know... dont submit them to the repro!
I wish I could convince everyone to be more careful, but lets be honest - it's very easy given the number of permutations {x86,x64,any} {release,debug}
My question: Is there anything I can add to a VS project that would make it more difficult to make changes? I'm not looking for a perfect solution, but the UX in VS works great up until a point, and then I'd prefer notepad to keep mistakes down
I could make the file read only, I dont know how that would play with our source control but I could investigate.
I'm hoping for something clever, maybe a mode that would prompt for confirmation before changing?
ideas / tips?
Bring a piggy bank to the office. If a user commits a file that breaks the automated build, then that person has to add $1 to the piggy bank. At the end of the project, or when the pot reaches a particular amount, buy something for the team and print up a sheet showing how much each person "contributed" to the pot.
You should check visual studio for options so that check out and check in are explicit.
You can also add check in policies, which among other can demand that a clean build was done locally before checking in.
If you would like more help, you should add some information both about your current setup and what you would like to prevent and what you would like achieve.
I usually have the team lead check-out the project file and keep it locked. Then nobody else can check-in changes. It is a little lo-tech, but it worked each time we did it. A benefit to this approach is that, when a user tries to make a change to the project file, he/she gets a reminder right away (because it can't be checked-out).
If we need changes, the project lead makes the changes, checks-in and out right away.
I found a similar question here, but of no help.
I have a solution with nearly 10 projects in it. I am able to edit the code while debugging the solution, but for 1 particular project (say "Defect.csproj"), I am not able to. I am receiving the error as
I have compared the properties of this "Defect.csproj" project ith other project properties and everything is found to be same. In Debug and Build tab in properties, Configuration is Debug. Optimize code is off. Can anyone suggest me whats the problem with my solution?
Are you using any special references on this project?
Using office references or delta lambda expressions can silently break the edit and continue functionality.
Also using some third party component winform items can really play havoc with edit and continue.
Also keep in mind that using linq breaks edit and continue fairly often and editing inside a try catch block on the active function is bad.
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.