I am working on an Asp.net web application. Since yesterday I am unable to check in my code. But I am able to get latest code, compare files , View history and create work items.
While check in- Neither the error message is displayed nor The file that needs to be checked in is locked.
Suspect:-
The application is written for VS 2010. But,Once I opened it on vs 2012. Later I made necessary changes to the solution file so that It re-opens on VS 2010 again. Can this be the reason why check in is not working? Please let me now if you have any suggestions. Thanks.
"Lock "Check-in". This is also known as the "antisocial":-). A check-in lock prevents anyone else from committing their changes to that file until you have released the lock. This means that they will be responsible for performing any conflict resolution activities that result. You can place a check-in lock on a file even if somebody has a file checked out with a lock type of "none" i.e. I know you are working on this file but you are not allowed to check in your changes until I have made this important quick fix."
Probably this is the case, someone check out the file after your check out. Check who check out the file and contact with him, this is the best advice which I can give you.
Related
I often get blue question marks on files in my VS2012 Solution Explorer when opening a solution bound to Perforce through P4VS.
Looks like something is having trouble to "synchronize" with the depot/workspace/whatnot. Hitting "Refresh View" always solves the issue but I'm growing tired on doing this everyday:
This is my VS version:
Microsoft Visual Studio Professional 2012
Version 11.0.61030.00 Update 4
And P4VS:
2014.1.85.4506
This is persistent across P4VS versions for a few months now, and seems to be affecting sometimes individual files, sometimes entire projects, with no apparent pattern.
How can I diagnose what's going wrong, be it a server issue, a VS issue, a workspace issue?... The Perforce Source Control output shows nothing special.
Actually it's not entire folders, it's entire projects. It appears that even if refreshing a project "fixes" the issue for one run, re-opening the solution brings it back. Whereas I think that for individual files, refreshing them solves the issue once and for all. I'll play with it a bit more to confirm that.
To help diagnose what is going wrong you should probably turn on logging, and check the preferences that will show everything in the output window. For the P4VS log, go to:
Tools- > Options -> Source Control -> Perforce - Logging
(This is not the same thing as the Visual Studio Activity log.)
There could be a possibility that you are getting disconnected and refresh reconnects you. I am not sure if you have your connection set to use solution-specific settings, since you did not mention the connection dialog coming up.
This "solved" the issue for me, at least for the entire projects that went blue-question-marked:
1) Tools > Options
2) Source Control
3) Perforce - General
4) Tick the option "Treat Solution/Project as directory when
selected"
Not sure why but that's one less annoyance for me every day. Thanks to Perforce support for suggesting that.
The file is probably not marked for version control. I noticed this icon in one file and opened Perforce to check. For whatever reason, this file was not marked for add in Perforce. After marking the file for add and submitting, the blue question mark went away.
I use Visual Studio Team Services to store the source code of my projects as I work on them, I love the service, especially that it is free, but I have been running into the biggest pain lately.
Randomly when I go to save, modify, check in check out I get this error for every single file I am modifying. So if I am trying to save changes to 8 files I get this message 8 times and it takes 45 60 seconds of trying to check out for each file meaning to takes 6 - 8 minutes for the errors to stop (even if I hit cancel).
The local data store is currently in use by another operation
I looked it up online and found many people with the same issue but the response from MS has nothing to do with my situation.
http://blogs.msdn.com/b/phkelley/archive/2013/05/31/tf400030-the-local-data-store-is-currently-in-use-by-another-operation.aspx
It basically says this can happen when you have to many files in your workspace or have several large solution open at once.
This does not apply to me as I usually only have on solution open at a time and my projects are very small (400 -500 files).
Ran into this issue as well on VS 2013 and TFS - every time I opened my team explorer it would take 10+ seconds to show all projects, then when I would expand the project in source control, another 10+ seconds would roll by.
Earlier today I began to experience the "local storage is being used" error when trying to save data in class files. I did some original research, and this following link saved the day for sure. Now TFS is blazing!
Local Data Store Solved
What you do is edit workspace (including all projects associated), and change the "Location" dropdown from "Local" to "Server". It took about 4-5 minutes for the changes to finish, but well worth it.
Hopefully this will help someone down the road.
Lately I started to get same error message and Visual Studio started to work very slow with TFS and nuget. I have tried repair and uninstall but not solve the problem. At the and it was so painfully slow that I cannot continue working. (Expanding one item on source control explorer takes 10 seconds)
Here is my story and how my problem be solved:
I was mapped tfs folders separately not to get whole TFS because there are lots of irrelevant documents. After trying lots of fix suggestion, I thought this might be the problem because I did this separate mapping first time while I have been using TFS. I generally map and get all items at once and never met this issue before.
I removed all mappings and it was like magic. Error is gone, slow TFS source control is gone and it is rocket fast now. Just to be in a safe side I also delete my workspaces and create a new one and get all TFS items at once.
I found the error would be triggered when I had more than once instance of VS 2012+ running utilizing Source Control Explorer, Solution Explorer and/or Team Explorer windows. I've not had this problem when running a single instance of VS 2012+ (on updates 2+) utilizing Source Control Explorer, Solution Explorer and/or Team Explorer windows in tandem.
I found this article and gave it's suggestion a shot: to prevent multiple threads from accessing the data store simultaneously.
http://blogs.msdn.com/b/phkelley/archive/2013/05/31/tf400030-the-local-data-store-is-currently-in-use-by-another-operation.aspx
This proved to be a remedy for this issue.
I would add for other users with large file repositories, using source control and share this issue, it may be greatly beneficial to create multiple workspaces for each of your branches/repositories. I found that by doing this my queries to TFS sped up immensely and also helped with this error. I found this suggestion here: http://blogs.msdn.com/b/phkelley/archive/2013/05/30/using-multiple-workspaces-with-visual-studio.aspx. I share this as users mention TFS running slowly.
I also started getting the same error this week. Maybe there's something wrong with VS Update 3?
Simply could not work on any of the projects of the "broken" local workspace anymore.
VS would show all files as being checked out, but none were really.
Other local workspaces were working fine.
I tried removing a project from the workspace, but when trying to confirm it, I would receive the same TF400030 error again.
Suggestion
If nothing else works, you might want to try this: simply delete the whole workspace and create it again, this time separating projects into different workspaces. This worked for me.
You'll probably want to back up your files first.
I did as mentioned below and TFS started working fine
Close all the VS instances
Go to: C:\Users[UserName]\AppData\Local\Microsoft\VisualStudio\15.0_46af8b8e
Delete the privateregistry.bin file
Reopen the project solution
Above worked for me.
Had the same problem,can be fixed in 3 quick steps:
Remove current Workspace: Source Control Explorer->Work Space ListBox->workspaces... and remove the workspace.
- Make sure that all pending changes are checked in
Delete Workspace local folder.
- Its Better to delete the folder entirely.If eventually keeping some folders make sure to delete all $tf folders (hidden folders inside the workspace folder)
Remap the projects you need ( the less the better )
Hopes that helps.
In my case the cause was a compressed folder containing my local data store, shown in blue in Windows explorer. Removing the compression did the trick.
I ran into this error when renaming my workspace. After changing back to original everything worked fine again
Restarting the Visual studio resolved the issue for me.
I have a very odd situation where by changes committed to the repository by my colleagues when updated to my local copy of the software, Visual studio doesn't recognise them immediately, and reload. the result (and this is very odd) is that most of the times, I will save my changes without the reloaded projects and will overwrite my colleagues changes. It is so embarrassing that sometimes I am asked why I had to change a piece of code and in reality I hadn't.
Another thing is, when I check in some VS project level changes like when someone added a new class, or form or anything and continue to work in Visual studio, it will take me at least 5 to 10 minutes before I get the warning that there was some changes and be asked to reload the project etc...
I think there should be a setting somewhere in visual studio to trigger an automatic reload, but can't find it.
This affect me and another person so far but mine is the strangest as it can take up to 30 minutes before a project start reload.
Any Ideas welcome
This is my settings
If you are working using Source Control, you will need to synchronise your local workspace with the server ("get" the latest code) before any changes by your colleagues will be copied to your PC.
If you don't "get" the latest code before you make changes then you may have to merge your changes with somebody else's, which can be a difficult, time consuming or even dangerous process - especially if you use the default Visual Studio automatic merge process, which usually does the wrong thing, resulting in essentially corrupt code (making it look like you deleted your colleague's works, just as you are describing, for example).
The best way to work with source control is the "little and often" approach:
Get the latest source code before you start any new work, so that your PC is as up to date as possible.
It's usually a good practice to "get" the latest code frequently (e.g. I do it first thing every morning) so that any merge conflicts are flagged up and dealt with as early as possible. The longer you wait before merging the worse the merge process tends to get. (Caveat: Check with your build system that the current version of the code on the server is working before you get it - you don't want to get broken code onto your PC as it may stop you being able to work at all).
Arrange your work as many small incremental steps that can be safely checked in as they are completed (rather than working for 3 months on hundreds of files and then dumping it on the system as one massive change )
When you are ready to check in, get the latest code, rebuild, and re-test your changes to be sure they still work when integrated with the latest program code. Only check in if everything works well.
Also be aware that when you try to edit a file, the source control provider may automatically "get" the latest version of that file for you (which could cause Visual Studio to tell you it has reloaded the file, and perhaps explain why you say it sometimes takes a while to "update", as it doesn't happen until you start editing a new file that has been changed recently by someone else). If this is the case, then the truth is that you have not "updated" the entire set of source code, only one file - in this case you really need to get all the latest changes to the source code (if you don't you may find it is uncompilable or (even worse), compiles but exhibits undefined behaviours due to only part of the code being up to date)
Lastly, a very good practice when checking in your code is to go through the list of files you are checking in and diff them one by one against the latest server code to see what you have changed. This may sound laborious but it confers several benefits:
It reminds you what you did, which can sometimes be helpful for filling in the check-in comment to clearly describe all your changes and make sure you don't miss an important note.
You will easily spot anything that has been screwed up in the merge process - there will be chunks of code that appear to be created or deleted that you know you didn't touch. So you'll be able to discover and fix these problems before you check in rather than annoying your colleagues by "deleting" their changes.
I find this very useful for finding temporary debugging code that I have forgotten to take out before I check in.
Sometimes you may even do a double-take on a bit of code you are about to check in and think "huh? why did I do that?". And then you might decide to re-examine and possibly even rewrite the code you thought was good to go.
Final Note: The options you show in your edit only relate to changes that are made to the files on your PC by another program on your PC. If another user makes a change and checks it in to source control, these options will have no effect. It is only when your Source Control system copies those changes to your PC's hard drive that you might see Visual Studio reacting to those changes (depending on how well your source control system is integrated with VS).
If you're sure the problem is Visual Studio (e.g. the file really has changed on the disk but you don't see it in Visual Studio)
Make sure that the Detect when file is changed option is checked.
Tools > Options > Environment > Documents > Detect when file is changed outside the environment
Since you are sometimes getting an alert to reload your project due to external changes means you already have the settings required to detect file changes in Visual Studio.
However, reloading of project/solution will only be triggered if the .csproj (or .vbproj) or .sln file was changed.
By the way, are you using some version control system? It seems that you are just sharing the solution and editing simultaneously.
I'm using TFS source control.
When I add a new resource key to my resource file - Resources.resx - and hit save, TFS checks out Resources.resx but doesn't check out Resources.Designer.cs. This causes the update to Resources.Designer.cs to fail with error:
The command you are attempting cannot be completed because the file 'Resources.Designer.cs' that must be modified cannot be changed. If the file is under source control, you may want to check it out; if the file is read-only on disk, you may want to change its attributes.
The error is correct in that the file IS read only and the file IS NOT checked out. I don't want to have to manually check out the designer every time I add/edit a resource key. Does anybody know of a solution or work around to this issue?
Note that I have TFS set up to "check out on save" as opposed to "check out on edit". This is deliberate to reduce the amount of unedited checkouts.
EDIT:
This happens in other file types also. For example, I am using RazorGenerator to create compiled MVC views. The same problem occurs if I try to edit the .cshtml without checking out the .generated.cs first.
UPDATE:
This issue occurs on all (as far as I've seen) files that have an autogenerated code-behind: .resx, .edmx, .aspx, .cshtml (when using RazorGenerator for compiled views), etc. I've decided that it's not worth the pain just for having "on edit: do nothing" set. I've decided to reset this to "on edit: checkout automatically". Thanks to everybody for your input. No thanks to TFS team for this FAIL.
Well, I did not think this counts as an answer so I wrote it in comment.
Checkout on save is only triggering when you save file, it does not trigger when file is autogenerated (autogenerate is not trigger for save which does checkout, as this file is edited by custom tool assigned to resx).
I'm afraid you will not get proper answer (the one which will solve your problem) besides that it is by design, but it may be worth opening a case on connect and ask to change this behavior.
Why do you want to reduce the amout of unedited checkouts? If a file is checked in without changes, TFS notices and it will not show in the checkin history of the file.
You can test this yourself by checking out a single file and immediately checking in. TFS will tell you there where no changes and the checkout is undone.
So maybe consider setting it back to checkout on edit? As mentioned in the other answer, this will solve your problems...
I think this is the problem
Note that I have TFS set up to "check out on save" as opposed to
"check out on edit". This is deliberate to reduce the amount of
unedited checkouts.
To avoid above problem, revert back to default settings. Then download TFS power tools.
Then use this command to revert changes which are checked out but contain no edits
tfpt uu /noget
Update: On changing above setting the issue no longer occurs. For details, refer below discussion in comments.
I have to work with TFS at work. I've seen to many miracles and we've spend a lot of time figuring out where the problem is. TFS is the choice of my company, but it's not my favorite.
TFS (especially when server is slow and you have regular network problems) is a disaster for me as a developer. VS looks for modification only over files in solution, and as you can see not all of them. When you use third party tools (fitnesse for integration tests or custom build steps) wich requires to modify files outside VS - you'll probably get the same error as you have.
But we found a solution. On my machine I use git. We've installed git-tfs.
And all you need to remember is three magic commands
git tfs fetch
git merge remotes/tfs/default
git tfs ct
That's it. You will never break company rules. And at the same time you will be free of that kind of weird problems. We've forgot about that nightmare.
EDIT: Local workspaces in the upcoming TFS 2012 will solve several issues, and TFS 2012 will become closer to SVN, but it will not be DVCS. MS invest in integration with external DVCS - please, welcome - Git-TF.
COM Excel AddIn, C#, VS2008
The error happens occasionally when I install/uninstall my AddIn.
sometimes I see Error 1001 the specified file can not be found
Anyone know what causes these and how to fix? thanks
I use windows installer
http://msdn.microsoft.com/en-us/library/2w2fhwzz%28v=VS.90%29.aspx says if use [TARGETDIR], it should be like "[TARGETDIR]\" or "[TARGETDIR] ". I simply use /filepath = "[TARGETDIR]myinstallfile" in CustomActionData
What I do not understand is it works almost all time and fails occasionally
Also even if I change this to including space or backslash, I can't tell if that fixes issue since the issue does not happen every time. Anyone has experience? thanks
I found this and it fixes the issue though I am not sure I ever use DDE in my program
http://sympmarc.com/2010/02/04/microsoft-excel-error-there-was-a-problem-sending-the-command-to-the-program/
Then I found this http://www.opendylan.org/documentation/opendylan/interop2/inte_278.htm
It talks about COM Server
so I went to cmd, type in "Excel.exe /RegServer", then the error disappears.
I am not really not sure if this solution works for all cases.
In fact, I am concerned that I miss sth in installer.
Here is a Microsoft Support page related to an issue which looks quite similar to yours. So for me it looks like a bug in Excel rather than in your installer.
The article is quite large, but it boils down to making sure that:
your Excel app is not running with elevated rights
advanced setting "Ignore other applications that use Dynamic Data Exchange (DDE)" is unchecked
Other than that you might try to repair Excel installation or follow the advice given in this thread of ASP.NET forums to fix the registry for Excel installation.
I hope it helps someone facing similar issues.
If you get this type of error when uninstalling a VS setup project MSI, then the most likely reason is that TARGETDIR is not preserved between the install and the uninstall, therefore it has no value, and attempts to use it in an uninstall custom action will result in failure to find the file. The easiest solution (apart from always installing to known locations such as common files etc) is to save TARGETDIR to the registry and retrieve it later. In the VS IDE you can create a registry item with the value [TARGETDIR] to have it resolved at install time.