I've recently noticed that when I go to make a change which needs a file to be changed, VS2017 (Professional) has started to produce a popup saying:
The file <filename>, which you attempted to edit, is read-only on disk.
Would you like to make the file writeable or edit it anyway?
If I cancel this, I get a message:
The file '<filename>' needs to be checked out before it can be edited.
The file was not checked out automatically because you have disabled automatic checkout
when files are edited in the Source Control options page.
The Source_Control->Plug-in_Selection is set to Visual Studio Team Foundation Server; I haven't changed the Options under Source_Control->Environment; both Saving and Editing are set to Check out automatically.
As far as I know, apart from recently updating from 15.7.4 to 15.7.5, I haven't changed any settings. Is there some setting elsewhere which affects this?
Note, my installation of VS2017 Pro Preview, 15.8.0 preview 5.0, does the same thing and running VS2017 as Administrator does not fix it.
Update:
Visual Studio 2015 has no problem checking out the same files in the same local workspace. That is, if I open a solution in VS2017, edit a file and go to save it, I get the above messages. If I then cancel the edits and try the same thing on the same file in VS2015, the file gets checked out. Hence the problem is with VS2017 and not the files themselves.
OK. After further searching I found a pointer to the answer in this answer. Somehow, my VS2017 instances have gone offline from the TFS server. The menu option File->Source_Control->Advanced->Go_Online sorted things out.
My solution had become unbound from the source control server.
To resolve I used menu options File->Source Control->Advanced->Change source control... Select project or solution without Server Name or Server Binding. Click Bind.
Related
I get a blank security warning popup window when trying to open a website, in Visual Studio 2015 Community Edition. It worked on my other computer in the same environment.
I moves the files to a new fresh computer and I get this window.
Here's a screenshot:
Nothing is clickable, even what where the buttons should be. Visual Studio is just frozen, can't even close the IDE nor the popup window. It doesn't happen to Web Projects, only websites.
Any idea how to solve this?
I got the same issue. Just fixed it. In my case it was entity ".tt" files fault. I guess for some reason VS 2015 does not recognize ".tt" extension. I've just deleted these files and run website (not web application) successfully
The .tt files are needed if using Entity Framework.
Here is my workaround that worked in two cases of the blank security warning. Rename the files with .tt extension to .tt.old.
Open the project (it will not compile, so don't try)
Save and close the project
Rename the .tt.old files back to their original names
Open the project again, this time the warning will have content and will be clickable.
Visual Studio's Go To Definition is disabled and F12 doesn't work. Other commands like Alt-F12 may continue working.
Close the solution.
Delete the intellisense database file for the solution: [solution].ncb or [solution].suo
Reopen the solution.
Optional: Rebuild the solution.
Note that this can also be as a result of disabling database for C++/C#.
In Tools - Options, type "IntelliSense" into the search box, and click on C/C++ - Advanced. In the Browsing/Navigation section, change Disable Database to False, if it is not so already.
After re-enabling, close and reopen to force rebuild.
NOTE: IntelliSense will produce large files on disk (*.sdf and ipch) that should be excluded from Git, for example.
I know the solution has been resolved. However, I encountered the exact same problem. I searched internet. None of the trick works including this one.
Eventually, I figured out. I right clicked on the file that had the problem. I included the file in the project. Isn't that obvious. Actually not, the file has been included for a week. I have been working on that file more than 7 hours a day for the whole week. Up till yesterday 6:20 pm.
Oh, I could not compile correctly this morning. There were tons of syntax error message yesterday. This morning, I was able to compile. Strange. right? Then my go to definition was gone.
Took me a while to find out cs and designer.cs were certainly excluded, but aspx file was.
I solved the problem. Did my figure slip? I don't know.
That is one thing people check. Either yourself, someone else, or system accidentally exclude the cs files without the knowledge. I know it is strange, but it solved the problem. There are weird scenarios in Visual studio. People can present 200 solutions. They work for 99% of time, but not our cases. I just bring one more scenario
I encountered this in Visual Studio 2010.
For me, this solution did the trick
Close all the files.
Reopen the files.
and you are good to go.
This also happens, if Visual Studio has files opened, which are not in the current Solution.
I don't know how I got to this state, where files of a different solution where open as I didn't open them manually, but a quick check of the file path showed that those weren't files of the opened solution.
Therefore, "Go to Definition" was disabled.
I found that I had to remove my TFS mapping:
VS 2010 > open Team Explorer > Drill into the team project > double click source control > right click on the team project in the left pane and do "Remove Mapping" > after everything was removed I manually went to the local folder and deleted any lingering files > back in source control explorer I re-mapped to the same local folder and re-pulled all the code. Now the "go to definition" works again.
Not sure why I had to do this...
Check dll in references which is yellow. Remove it and add again.
I've just had this happen with a CMake-based C++ project in Visual Studio 2019. Everything was fine yesterday, then when I opened it up today all the Go To Definition/Declaration etc options were greyed out everywhere in every file in the project, even for things defined within the same file (and the syntax highlighting didn't look right either). It did work if I opened one of the .cpp files separately on its own (without loading the Project/Solution).
I tried various things including the answers here and telling it to generate the CMake cache again, but what finally fixed it was actually deleting the CMake cache. The Delete Cache option didn't seem to work (all the files were still there on disk, and there was some sort of failure message in the Output window) so I just deleted the entire "out" directory from the project directory (well, moved it somewhere outside of the project, just in case). Loaded up Visual Studio again, it rebuilt the cache again automatically and IntelliSense immediately started working again! I just had to wait 5 minutes for it to compile everything again when I wanted to run the project.
Maybe it wasn't necessary to remove the entire "out" directory, but when I clicked "Open in Explorer" under the "CMake Cache" menu it opened the actual build directory (which was the only thing in the "out" directory anyway) so I assumed the entire thing was related to the cache and was getting too fed up with it to try to narrow it down further. It's probably only certain files within that directory really.
Tried all the above solutions in my VS2019, nothing worked for me. Than I've noticed an update sign on the bottom Right corner. After updating the VS all options were restored.
Simple just check your bottom left corner of Visual Studio if Restricted turn it as a trusted and your problem will solve.
In my case due to my project is mapped with TFS so I am unable to go to definition also my project files showing read only when opening from Solution. So I have move to my root folder mapped with TFS and then right-clicked on folder > Go to properties > Attributes section was Read-Only I have unchecked it and clicked Apply. Reopen visual studio. Everything is now working fine.
I faced the same Issue in my Visual Studio 2019 version.I followed the below Steps:
Go to references folder in the solution.
Click on Manage Nuget packages.
Click on Browse.
Search for 'Microsoft.Net.Compilers'.
Click on Update.
This Worked for me.
In my case, another Visual Stuidio was opened (not closed succsessfully). Close all examples of VS, then re open solution.
Just open the Solution using Windows Explorer, instead of opening it from inside VS...
I'm having an issue where Visual Studio 2012 hangs for way longer than it should whenever I do a manual save. Previously it seemed to do this randomly, but I noticed that it was whenever it was doing an automatic save to the backup recovery files. I have since disabled the AutoRecover system.
By using sysinternals Process Monitor, I learned that VS2012 is trying to access a network location that no longer exists, and not just when trying to save, but when starting up, etc. Any time it is trying to access the .../My Documents/Visual Studio 2012/ directory, it's looking in the wrong place:
What happened I believe is that when I originally installed 2012, \govstor-01 was the name of one of our servers. I went back to using VS2010 for a while, and during that time our IT/Network guys renamed that server (simply removed the -01).
My question is: Where is VS2012 saving that path and how do I change it? It doesn't seem to be a system related thing because VS2010 and VS2013 RC both work perfectly fine so I'm not sure why 2012 is stuck with outdated 'hooks'. Like I said, I disabled the AutoRecovery feature but it still seems to be trying to access that directory when doing a manual save.
Quick Edit: I should note that I have tried reinstalling VS2012, as well as performing the 'Reset all settings' in the Import and Export Settings Wizard.
As noted, there are several settings in Visual Studio that can refer to the original Documents directory. Short from hunting through the Tools + Options settings, the easiest way to find them back is by searching the registry with Regedit.exe for the old server name. And editing the value you find to now refer to the new server name. Restart VS and you should be back in business.
When i try to access my solution Properties, i get the following error:
Object reference not set to an instance of an object
I am using VS 2012. What could be the cause of this?
Some extensions may cause this.
Try disabling extensions and restarting Visual Studio.
Quite often error will be gone even if you re-enable extensions after this.
There's a bug report on Microsoft Connect (link).
It is marked there as "Closed as External", but it seems that it may occur randomly with any extension, so would be worth voting it there to bring it to Microsofts attention.
In my case, the problem was solution-specific. NuGet was causing this error, but not the extension itself but a NuGet package that generated an error on VS load. When I opened NuGet Package Manager Console I saw a big red text with a description of the error. In my case it was T4Scaffolding.Core package, which in turn is a dependency of MVCMailer.
If this is your case, you will probably see what package generates an error in PM Console.
I faced this dialog too and i'm not sure what exactly causes this as i couldn't even open the NuGet console to see detailed error messages.
Closing Visual Studio, deleting %AppData%\Microsoft\VisualStudio and restarting Visual Studio worked for me as it causes a reset of various things like window configurations.
I think if this dialog is displayed some files may be corrupt in %AppData%\Microsoft\VisualStudio and by deleting that folder Visual Studio can start normally again.
Update:
The issue arises on my machine when i start Visual Studio by using "run as administator" whereas Visual Studio has been started before without that option and %AppData%\Microsoft\VisualStudio had been created without the administator association.
Visual Studio 2013: I had this issue when I tried opening TOOLS -> Extensions and Updates.
I used #ViRuSTriNiTy idea, but only cleaned the files from:
C:\Users[myUserName]\AppData\Local\Microsoft\VisualStudio\12.0\Extensions
There are 2 cache files over there.
Deleted them and restarted VS2013 and it was fixed
The way it was happening for me might be unique to me/my setup, but I'd love to know if anyone else has this happen, and if they find out why:
If I launch an .sln file by double-clicking it, it will load VS and I can right-click the Solution and get Properties to come up no problem.
If I go to "Open Project" on the Visual Studio welcome page or from File > Open > Project/Solution, navigate to the .sln file and launch it by selecting it and clicking "Open" in the File dialog, that's when I have this issue.
I'm going to just always launch the .sln file from now on, but I'd love to know why this happens when using "Open Project" from the welcome page or from File > Open > Project/Solution! I tried going into Tools > NuGet Package Manager > General and I unchecked the options for allowing NuGet to download missing packages and Skip applying binding redirects, and under Package Sources I de-selected the checkboxes (my dev machine does not connect to the internet). Environment > Extensions and Updates: I tried it with and without "Load per user extensions when running as administrator" and running it as an Admin and without running as Admin. Also tried just deleting everything at C:\Users\me\AppData\Local\Microsoft\VisualStudio. No change from those 2 bullets above.
Note: I saw "There appears to be a discrepancy between the solution's source control ...." , but this doesn't apply, as I wish to fix this without changing the .sln file.
For some reason, any time I open a solution which has in the sln file:
SccTeamFoundationServer = http://servername:8080/tfs/defaultcollection
SccAuxPath* = http://servername:8080/tfs/defaultcollection
My copy of VSS insists on switching it to
SccTeamFoundationServer = http://servername:8080/tfs/
SccAuxPath* = http://servername:8080/tfs/
Saving these changes does fix everything for me, but everyone else using the same version control server is fine with the 1st version but not the second version. I wish for my computer's version control server/paths to be consistent with that of my coworkers.
Everyone is using Visual Studio 2010 with Visual Studio 2010 Team Explorer.
I had this problem with a Solution containing *.vcxproj project files, that were previously migrated from VS2008 to VS2010.
The path to TFS was defined in both the .sln file and the .vcxproj files.
The simplest fix was to update the *.vcxproj project files to use the SAK keyword.
ie update from the format:
<SccProjectName>$/MyProject/Directory/abc</SccProjectName>
<SccAuxPath>http://servername:8080/tfs/defaultcollection</SccAuxPath>
<SccLocalPath>.</SccLocalPath>
<SccProvider>{11111111-1111-1111-1111-111111111111}</SccProvider>
to
<SccProjectName>SAK</SccProjectName>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
<SccProvider>SAK</SccProvider>
Have you tried connecting to http://servername:8080/tfs/defaultcollection instead of http://servername:8080/tfs/ in your Team Explorer settings - Team Project Connection? Try to do that, let someone who have the http://servername:8080/tfs/ version check-in, remap your local instance then get latest.
I just had this exact problem. I finally solved the issue by disconnecting from TFS and reconnecting:
In Team Explorer (View-Team Explorer), right-click on your TFS server name and click 'Disconnect'. Then click Team-Connect to Team Foundation Server...
I did not have any pending changes when I did this. I would check in your code or at least shelve your changes before doing this to decrease the chance of losing work.
The computer that this happened on had been working fine for over a year, but I guess Visual Studio somehow cached the name as http://servername:8080/tfs/ instead of http://servername:8080/tfs/defaultcollection and disconnecting and reconnecting to TFS reset VS to the correct path of http://servername:8080/tfs/defaultcollection. On my server (and I would guess on everyone's) http://servername:8080/tfs/ and http://servername:8080/tfs/defaultcollection point to the same thing. Raymund's solution didn't work for me - I had the same problem that Brian had with it.
Using Visual Studio you can solve this problem by unbinding and binding the solution and/or projects. Try this:
Open the problem solution in VS (did this in VS2013 just now)
Commit anything you need to commit (let's keep it simple - nothing to merge/checkin)
If there are any pending changes then undo all pending changes to all the projects in that solution and any changes to the solution itself
Go to File -> Source Control -> Advanced -> Change Source Control
Select the problem projects and click "Unbind"
Click OK and close the window (THIS IS IMPORTANT - if you don't click OK VS doesn't update the solution properly)
Go to File -> Source Control -> Advanced -> Change Source Control
Select all the projects you unbound in #5 and click "Bind"
Click OK and close the window
Check in your Solution & Project changes
Close the solution and open it back up and everything should be fine now
Also try opening the .sln file from Source Control Explorer, I think that may have been what solved the issue for me.