We develop using VS2008 solution that have about 26 project that's added to Team System Source control.
The problem is: sometime when developer try to debug a project, VS check out all projects before debugging, we don't know Why this happen especially if we close all vs and try again the problem not appear ... Is any know how to solve this issue ?
That's how it is. I hate it too. The best you could do is configure Visual Studio to ask every time before it checks out a file so that the developer is being warned of what is happening behind the scenes:
Related
Environment:
Windows 10 2004
Visual Studio Enterprise 2019 16.7.6
TFS 2018.2 on Windows 2019 Server
I have a VS 2019 solution containing 14 C# projects. All of the projects are in TFS. For some reason one project is not showing in Solution Explorer as being in TFS (no lock icon). At one time it did show, sometime in the last month the lock disappeared. If I use Source Control Explorer in VS2019, I can navigate to the project and perform TDS operations on it.
If right click on the project on go to Source Control -> Add to Source Control I get an error window that simply says "Unspecified Error". Is there someplace I can look to find the error?
If there is any additional information I can provide, please let me know.
Thank you,
Eric
Thanks, G-P The link at VS2013 or VS2015 shows "unspecified error" fixed the issue. I should have widened my search to older versions. Another life lesson.
Thanks again,
Eric.
I have a VSIX extension (https://github.com/eduelias/AssociateRecentWorkItems) that worked really well on my VS2015 but, as I built/run it on VS2017 (yeah, I've put the prerequisites on the .csproj properties), it is not appearing at 2017's TFS Pending Changes tab.
I've tried updating MIcrosoft.TeamfoundationServer.Controls to the 2017 version but still no success.
As I try to debug it, it seems that VS2017 isn't loading the extension at all. (Breakpoints aren't not been loaded)
Any help is welcome. Thanks!
Give a try with another new extension on VS2017(from marketplace) in your side. If this could also not installed successfully and you are using VS2017 RC.
You may encountered this issue--Unable to install extensions after updating VS2017 RC
Either update to latest VS version or use Stefan Z Camilleri 's workaround in above link.
If only your old extension could not be installed, since
Huge changes have been made by Microsoft on the installation, so
previous approaches of detecting VS won't work any more. For example,
to detect VS installation folder, now a few extra tools or scripts are
required, https://github.com/Microsoft/vswhere
So guides such as How to: Migrate Extensibility Projects to Visual
Studio
2017
are critical and you can follow the tips.
You could also refer more details in this similar question Visual Studio 2017 is not detected by extensions for installation
Looking through the log, I was able to find that some of my references were asking for Microsoft.TeamFoundation.Client Version=14.0.0, in fact, It was the Microsoft.TeamFoundation.VersionControl version=12.0 that were looking for it.
To solve it, I've made a 'binding redirect' like this:
[assembly: ProvideBindingRedirection(AssemblyName = "Microsoft.TeamFoundation.Client", NewVersion = "15.0.0.0", OldVersionLowerBound = "12.0.0.0", OldVersionUpperBound = "14.0.0.0")]
It started appearing at the Exp instance and I was able to debug it.
Note that I strongly advise against doing such kind of workaround but, in my case, it was the only way I could make it load my extension so I could debug it.
We are attempting to add MVC to an old, large, legacy webforms app. (The intent is to gradually re-implement portions of the app using MVC until the old app is gone).
Setting it up has gone smoothly. We have an MVC Area, and I created a controller which is accessible when running the app, by means on directly typing the url.
But whenever we "Add > Controller" or "Add > View"... Visual Studio hangs for around 10 minutes "Not Responding".
Clearly there is some bug in visual studio interacting with some quirk in our legacy project.
Googling, I have so far found only a few similar cases that are old & do not seem applicable.
Not sure where to begin resolving this.
UPDATE:
For what it is worth, we have converted the original VB webforms project to C#. I then added MVC Nuget package and and MVC area. Visual studio no longer seems to hang when adding controllers. So this might be a VB specific thing. Or maybe some windows update to visual studio fixed this in the interim since i posted this. Not sure.
The problem is still present in Visual Studio 2015 Update 1.
As a workaround, instead of selecting "Add View" you can select "New Item" and choose a page template from Web/MVC instead.
It is still in Visual Studio 2017; It takes time and you can restart making Controller/View or you can wait sometimes
this seems like bugs from visual studio,
you can copy other controller and paste it then rename namespace.
for temporary until visual studio is fixed.
I'm having the same issue. This should work. I'm selecting "Add Controller" from the context menu. It just spins saying Visual Studio not responding. This is with Visual Studio 2015.
In my case this situation arises when adding view to the controller and visual studio 2015 hangs indefinitely. However it creates the view file in the directory but not shown in solution explorer. I have manually copy pasted the file from directory to solution explorer and everything worked well.
Check if the below blog could help resolve your issue
http://digioz.blogspot.co.uk/2013/06/visual-studio-2012-freezes-or-crashes.html
I'm working on a project in Visual studios 2013. I was trying to figure out how to do something and was recommended to look at another project on TFS that does something similar. When I got latest version of this other project, I found out it was made in VS2010. It migrated it to VS2013, and locked the file to me. I undid the changes because I don't want to modify this other program. I was unable to find a way to open that file without it trying to lock the file to me with migrating to VS2013.
As an attempted solution, I copied the file elsewhere on my computer and tried opening it without connecting to TFS. I assumed this would allow it to migrate to 2013 without updating the database. It still had issues and gave me this error: Solution file '%s' cannot be migrated because the solution cannot be checked out from source code control. To migrate the solution, make sure the solution file can be checked out and re-open it.
How can I open this solution without updating the TFS solution and locking the file to myself?
I just ran into this same problem. I checked the permissions on the solution files I was trying to open and saw that it was set to 'read-only'. I deselected read-only and the solution opened.
If everyone else is using VS2010 with Service Pack 1, then upgrading the solution isn't a problem. People will still be able to open it in VS2010 SP1, even if you check it in. See the Visual Studio 2013 Compatibility notes on MSDN for specific things to watch for.
Alternatively, after checking the files out but before opening the .sln file, create a copy of it in the same folder calling it MyProject2013.sln (for example). Add this new solution to source control using Source Control Explorer and then open it, letting Visual Studio upgrade the .sln file as it would normally. The 2010 .sln file will be left untouched and you should be OK to do what you like with the 2013 solution.
I'm considering using VS2012 RC to put together coded UI tests (since VS2010 SP2 FP2 does not fully support IE9).
Currently, my test projects are contained within a solution which is connected to our TFS team project. I also set up a build definition to build the project when new code is checked in (the builds are performed on our build machine).
I suppose that if I upgrade my solution to VS2012, then to be able to build the solution on the build machine I will need VS2012 RC installed there too, right? But then is it possible to specify in my build definition for my project to be built by VS2012 instead of VS2010?
Is it possible for me to upgrade my project with VS2012 while still using TFS2010? I should note my solution will be the only one upgraded to VS2012. All the other solutions in the company still need to be built by VS2010. A company-wide upgrade to VS2012 won't be in place for at least a few months, I imagine.
Or do I need a separate build machine or anything?
Any thoughts, ideas or solutions appreciated!
UPDATE: So I gave it a try, and everything worked okay. My only problem is that the Coded UI tests I have didn't work after being re-built on on my build machine, but I suppose that's probably something I'd need to ask about elsewhere. To clarify, the solution built successfully, but the tests still failed.
Visual Studio 2012's project changes allow most types to still be opened by Visual Studio 2010 with SP1, so it depends on what kind of projects are in your solution - see this page for the full compatibility list:
If you created your assets in Visual Studio 2010 with Service Pack 1
(SP1), many of them will load and run in Visual Studio 2012 without
any further action on your part. Many assets will also open again in
Visual Studio 2010 with SP1 without any issues, even after you open
those assets in Visual Studio 2012.
See also "Round-tripping with Visual Studio 11" on the VS blog which has more detail.
Note though that if your build process uses custom build activities then just installing Visual Studio 2012 breaks the build definition on your local machine, and also that MVC1 or MVC2 projects just aren't supported by VS2012. Oh, and Visual Studio 2012 isn't a RC any more, it was RTM'd last week.
(I presume you mean 2012 RTM rather than RC, now that the final release is available)
Theoretically (from what I've read) VS2012 and VS2010 use the same project/solution file format, so you should be able to switch between them without any compatibility issues (aside, presumably from obvious things like creating new file types that VS2010 doesn't understand)
TFS updates have historically been backwards compatible, so you can usually use different client and server versions (but usually you need a compatibility pack installed for old clients on new servers, a new client running against an old server has usualyl been fine). So I'd expect this to work well.
I'd say try it, but diff any files that appear in VCS2012's Pending Changes carefully before you check in to be sure that it hasn't changed anything that will cause problems. The worst that can happen then is that your development machine gets a "corrupt" version of the code and you'll need to revert to 2010.
(This is the approach I've been using with our 130-project C# solution, and so far (1 day) it's working fine, apart from the new UI making my eyes bleed as they try to find the information in all the indistinguishable monochrome clutter)