Today, while trying to publish an app so I could test it, I suddenly got this error message:
The item
D:\ScratchSrc\TryNewReportViewer2017\TryNewReportViewer2017\TryNewReportViewer2017.csproj.vspscc
could not be found in your workspace, or you do not have permission to
access it.
That's a mystery to me, as I've never gotten this before and I was working with this app just last week. Publishing it, too.
I've looked for the .vspscc file. Found it exactly where it said it should be. So, the alternative is that I don't have permissions to it. I don't understand why I shouldn't have permissions to a file on my machine that I created, but whatever. So, how do I get permissions to my own file?
I'm working with VS 2017, TFS 2015 on premise.
This issue may due to the wrong source control binding for that specific xx.vspscc file.
Double check your source control bindings for that file in TFS. You could also try to unbind and rebind the file.
Then delete the file in local(back up local changes first) and get latest version from TFS. Finally do the publish again.
If above solution is still not working, try to delete local workspace and create a new one, get latest version of the file, modify the file with local changes (if you have) in your backup , check in the file, then do the publish .
Another reason for this problem is, that the vspscc file is not checked in.
Just do a "Compare" on the project folder to see, if it's missing.
If the csproj.vspscc is missing you can create a new one by removing the project in visual studio and adding it back
I was able to 'fix' the problem by going to the source control explorer, selecting the smproj file (which was checked out for editing), and checked it in by itself. Then, I checked in the Model.bim. Was able to do both of these things without getting the error.
I also tried all the usual things, deleting the entire solution directory, getting it from TFS again but nothing worked.
Noticed the version of Visual Studio 2019 was a few months old so upgraded to the latest. That fixed it!
Related
I am having some trouble with TFS:
I have ignore rules for certain files. For example:
\Build\Scripts*.sum
It does not seem to recognize this. But, if I exclude these files in the Visual Studio UI, it remembers that I excluded them for some time.Then I lose connectivity and I have to re-exclude them. Why doesnt the tfignore file seem to be working. This leads to:
I routinely lose the ability to connect to TFS. Ill be moving along happily working. then Ill go and check in some code and I will get the error that I do not have access to TFS. If I restart Visual Studio, I can then successfully connect and check in code. Things will be fine for a few hours, and then it will happen again. Why do I lose the ability to connect? And why does restarting fix it?
First make sure you were using the correctly .tfignore file.** This file does not have any suffix. One way to create it, suggest you to rename a new.txt file with "tfignore." It will auto change to right .tfignore file.
You can also use the auto automatically generated .tfignore file, follow below steps in my answer here.
More detail info about the .tfignore file please refer this tutorial.
Note: This .tfignore file will not affect with those files already in source control. You need to remove them from source control first. Also make sure your .tfignore files have checked in source control.
That sounds wired. get the error that I do not have access to TFS what's the detail error here? If restart Visual Studio, can then successfully connect and check in code. It shouldn't be a permission related issue.
One possibility is network related, double check and confirm if there is any instability of your network environment. If you are behind VPN, try to connect without VPN.
Since Restart Visual Studio fixed the issue, it also may related to cache. Try to clear TFS and VS cache, which may do the trick.
The issue was that TFS thought these items had been "added" although that was not entirely clear from Visual Studio UI. I had to go to the Source Control Explorer and look at the folder where these files were. They were listed as 'add' which is how I figured this out. I never explicitly added these files. I had to right click on these items and remove them.
Am trying to publish my Web Application. It worked fine literally 15 minutes ago and not aware of anything changing in the meantime. Now receiving this error:
Copying file bin\myApp.dll to obj\Release\Package\PackageTmp\bin\myApp.dll failed. Could not find a part of the path 'obj\Release\Package\PackageTmp\bin\myApp.dll'.
Tried copying the dll manually and Windows just hangs.
Any ideas?
Usually this happens to me when a file is locked (still in use) by windows.
Try right clicking on the solution and doing "clean" solution. Then rebuilding.
If that does not work. Try cleaning solution, closing Visual Studio, re-opening it, then publishing it.
Think I've fixed it. Had to remote directly into the server and cut the release folder to the desktop then copy it back again. Window's threw some permission errors, which it shouldn't have as I have full permissions but worked when I clicked "Try Again". Then manually inserted the dll the same way and tried publishing again. This time it worked. Bit of a weird one but seems to be working now.
I was looking for a solution to this problem and I've found out, in my case, that the folder was not being created when the project was published in IIS. So I've copied the folder from my project's directory to the location where the project is published.
It worked for me!
I had a similar issue and found that the cause was the permission set in the Build folder located in the project folder where the software is compiled to.
For some reason the permission were not set to full, and on further investigation the delete permissions were not set to active.
This meant that the first compile succeeded, but the second failed because the original folder could not be cleared by Visual Studio, or the original files could not be overwritten.
Setting the permissions to full fixed this issue.
This happened to me when you have a files that the path that is longer than 255 chars.
Ensuring all file paths from the drive root to all the files in the Debug\Package\PackageTmp folder were shorter than 255 corrected the issue for me
I have a Visual Studio 2013 solution that is under source control (TFS, Visual Studio Online). It is mapped to a local workspace, I have checked out some files (e.g. web.config, global.asax).
When I try to save any changes to files I get a 'Save File As' dialog, and if I hit Save it warns me the file already exists (say, web.config), and asks me if I want to replace it. If I hit Yes I get I get an error dialog saying 'the process cannot access the file '....\wyfvmjia.p1p~' because it is used by another process. I have no idea what this file is or how it is related to the file (web.config) I am trying to save.
This is infuriating, any help would be greatly appreciated!
EDIT 1:
It looks like the Visual Studio process (devenv.exe) is creating and deleting random temporary files in the same folder (e.g. wyfvmjia.p1p~) and is causing a 'sharing violation' on those files (I used a sys internals utility to monitor the folder) when I am trying to save let's say web.config.
EDIT 2:
This seems to suggest in one of the comments that VS2013 creates a copy of a file and then replaces the original when trying to save a file in your project. This would explain why I see temporary files getting created and deleted. It's odd I get the 'Save File As' dialog though. It looks like some other process (antivirus?) gets hold of the temporary file before VS can do something with it?
EDIT 3:
I created a console application project with only a program.cs file and the same is happening. This may be a problem with Antivirus software interfering with the VS2013 'copy-replace' feature.
EDIT 4:
Changed title. Still have not been able to find a solution.
EDIT 5:
See the accepted answer. Apologies for not getting back earlier.
For me it was Google Drive.
Once I've closed it, I was able to save the file.
Try running Visual Studio as Administrator.
Extensions might be the problem. Or you could be opening some readonly files.
It's worth to mention that some of the extensions can turn any file you create in to a readonly file, and this would be the same result that you're facing.
So first, disable all extensions, and check for the little icon near the files's name (in the tab) that indicates a readonly file.
It turns out this was caused by disk encryption software. Disabling the disk encryption software services each time after starting VS2013 solves the problem. I did not have this problem with earlier versions of Visual Studio, presumably because of the new copy-replace cycle adopted by VS2013 mentioned in EDIT 2 in my original question.
Apologies for not coming back to comment and answer my original question, I completely forgot about it.
I had the same problem and it was caused by "Backup and Sync from Google". After I’ve closed it everything went back to normal.
I had this problem as well. It went away once I uninstalled VS 2013 and installed VS 2012 instead. Good enough for me.
I had the exact problem on a company computer. I had to uninstall VS 2013 RC2 and reinstall vs2013 ultimate. Then I had to go through the update process for update 1. I believe it must by the Symantec progressive scan along with the VS 2013 upgrade handling of files. I guess the moral of the story, if I can be so cliché is "If it aint broke don't fix it".
I had the same issue and created a bug on Connect. Let's hope this gets fixed
https://connect.microsoft.com/VisualStudio/feedback/details/860265/unable-to-save-files-in-vs-2013-update-2-rc2
I got mine fixed by making a copy of all the files with git clone then deleting all old files and pasting the copied versions over it. Not sure how this fixed permissions or an antivirus denying permission but it did
martijn_himself sounds correct, problem could be because of Disk Encryption Software. This problem started om my PC when i changed settings (domain etc) on Disk Encryption Software. and a simple "Update 2" for VS2013 fixed this issue.
I had the same problem with only one html file in a project. For me it seems to have something to do with VPN that I was using to upload this html file to CRM system. Whenever it was on it seemed to "block" the file somehow. When I closed the window where I was uploading the html file I can save without any issues.
I tried all the suggestions here but none worked. Then, with the modified file open in Visual Studio, I navigated to the file on disk and deleted it. Then clicked build and the save file dialog no longer popped up. I was able to build and check in.
For me, it was Windows' Controlled Folder Access, even though I didn't get the standard warning/error. In "Allow an app through...", I had to add
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\WDExpress.exe
(Backup and Sync from Google) when I close it The problem vanished
I'm getting this message when connected to a TFS repository and trying to edit a local .sql file that's not yet in the repository.
The item C:\bla\blabla\blablabla\USP_BLA.sql could not be found in
your workspace, or you do not have permission to access it. No items
were checked out
If I disconnect from the TFS repository everything is fine. If I re-connect to the TFS repository I start getting the message, even just trying to type/save the file.
The file is actually there in my local folder and I have the corresponding permissions, for those who are thinking otherwise. It is just a text file that I should be able to edit irrespective of whether I'm connected to the repository or not.
I got Windows SP1 installed on my Windows 7 this morning; don't know if that could be the cause of the issue. We are using the.NET Framework 4.
Any idea of what the issue is or how to resolve it?
It turns out the issue was with one of the "facts" in my question, "file that's not yet in the repository".
A file with the same file name I had locally was already there in the TFS repository, it had been checked-in a month ago by someone else.
Only when I tried to check-in the new local copy I became aware of that; the file was not supposed to be there.
Anyway, after checking-out the file from TFS everything went back to normal; I'm able to edit/save the file without issues, even if connected to TFS.
Try to get the latest version of your source code It should resolve the issue..Or Get Specific Version and allow to overwrite existing files.If still does not resolve make sure the file is present on local directory.
Do not forget to rebuild after getting latest code
Visual Studio (and possibly TFS) has somehow (I think perhaps during a source control merge) become confused about the path of a project within my solution.
It thinks it is here (example paths for simplicity):
C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj
whereas actually, the project file is located here:
C:\My Projects\ExampleSolution\ExampleProjectCorrect\ExampleProjectCorrect.csproj
I cannot for the life of me get it to recognize the correct location. I have tried:
Removing and re-adding the project from the correct location. An error message comes up saying The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found.
Manually editing the .sln file to ensure all references to ExampleProjectCorrect.csproj have the correct paths.
Doing a find in files on the solution directory for both the correct and incorrect paths, to try and track down where studio is hiding the incorrect path.
Deleting the cache directories for VS and TFS
I'm tearing my hair out because I can't recreate the solution as it has near as makes no difference 100 projects in and is tied in to source control with several other developers working on it.
Can anyone point me in the right direction as to where it is storing this incorrect path and/or how to reset it so the damn thing will load correctly?
Go to Manage Workspaces (either through the File/Source Control menu or the workspace drop down in Source Control Explorer)
select edit for your workspace.
You should see, under working folders, a mapping for the source
control directory to the old/wrong project directory.
Select it and click remove.
Close VS and delete the suo file.
It still references the wrong directory. Maybe rebinding might work at this point but I didn't try that. Reload your project and you should be good to go.
Simply deleting the solutions .suo file worked for me.
I was facing this issue after performing a migration from Visual Source Safe 2005 to TFS 2012. I couldn't wait for the "Conversion Wizard" due out in the next couple weeks so I just ran VSSConvert.exe. This took 6 or so years of history and moved it into TFS.. while I didn't get the actual timeline history.. I got a bunch of entries on the same day with the comments indicating the actual check-ins of the history.. not bad.
So after it ran all night (Successfully, yay!), I was having trouble loading my projects just as this question stated. For some reason, a few projects were being referenced to an incorrect directory. I checked the .sln, the .vsproj files, and getting latest, deleting re-getting, adding removing, etc.. I tried everything noted here... even upgrading my workspace, which I'm not sure what that even did.
FINALLY... I deleted the *.suo files and viola. It worked.
I spent a couple hours on this one.
A slightly different solution.
TFS was displaying a non-existing path for a particular Solution. Previously, I had a laptop with a separate D: drive, but now, I just have a C: drive. TFS still thought my project was stored on D:\Project\MikesProject
I didn't have a .suo file to delete, the D: path wasn't mentioned anywhere in my Workspaces (buried away under the File\Source Control\Advanced\Workspaces menu), TFS showed that I did have the latest files in my (no-longer-existant) D: directory, and TFS in VS2013 didn't have a "Remove Mappings" option for this project.
But what did work was to simply do a "Get latest version" on the project.
After doing so, a fresh copy of the code was written to my C: drive, and (interestingly), now the Local Path was shown underlined.
Previously, the D: path wasn't shown like this.
Odd. Very odd.
We've had similar issues with moves and renames.
Deleting the local directories and then getting again solved it.
Even after deleting the .suo file and .vs folders, I had to edit the .sln file and remove the old relative url from SccProjectName# despite the SccLocalPath# being correct. Apparently VS also uses the name as a hint path.
Try to delete or rename .suo file (including extension). This file is at the same location where your solution file is. It worked for me.
Just guessing, but perhaps some of your other projects references your project from the wrong location? In this case, you have not just to delete and re-insert the project into your solution, you will also have to delete and recreate the references from the referencing projects (stored in their .csproj files).
After trying many recommendations I deleted the suo file ( again ). The last time worked. Why it did not work earlier I do not know. In general I find deleting the suo file one of the first steps I do.
I had my asp.net website solution opened from my Dev Branch.
Then for some other purpose I opened same solution from Main branch.
I made a change to one of my .ascx.cs file in the dev branch and set breakpoint. When I ran the debugger, all my break points were hit in the Dev Branch except for the .ascx.cs which was hitting the Main branch. Have not idea.
Tried cleaning the Temporary folder but didn't work.
What worked:
Closed all instances of Visual Studio
Opened the solution from Dev branch again.
Run again and the break points started hitting.
In my case i copied the *.sln file into the project folder and changed the path to project into the *.sln file. Only this resolved the problem (vs 2015 sp1, winservise project).
Delete *.suo does not helps for me.
Yet another solution worked for us - after trying the delete of suo and almost everything mentioned in this thread. We had a project in the solution which was showing a ghost version of the csproj file. We deleted that file and our paths fixed on another project we were trying to add.
Deleting obj and bin files would solve the problem...
I know it is an old line. I just went through the same problem. We recently migrate the TFS, so I created a new workspace to map to new server and kept the old one. Every time when I open a solution which is supposed to target to my new workspace, VS always tried to load projects from my old mapping directory, till I removed my old workspace.