Related
I have a setup where I have one computer at the office and another at my house, and the project data are being shared via OneDrive. This is purely for my own convenience and I only ever work on one computer at a time, shutting down Visual Studio when I'm not using it on either computer.
My current problem involves a project that is being synchronised via OneDrive but uses a SQL Server LocalDB database for development and testing but, despite the files being synchronised between the two computers, data that was inserted on one computer does not appear in queries run on the second computer.
Synchronisation only occurs once Visual Studio is shut down, since file locking prevents the process. I have verified that both the .mdf and the .ldf files are being copied (the file sizes and modification dates are correct). I have also physically copied the files via external harddrive to rule out the OneDrive synchronisation step, but the problem persists.
I have also verified that even after the files are copied, the inserted data is still present on the computer where the INSERT was done, but is not appearing when doing a SELECT on the second computer.
I was under the impression that LocalDB only used the .mdf and .ldf files, are there caching files somewhere else that I also need to synchronise?
All code and other project files are being synchronised just fine, it's only the database that is experiencing this problem.
I understand that this is probably a weird setup for most people, and I would never do this if I were in a team setting but I would appreciate some insight into what could be going wrong.
Sorry for the trouble to anyone, I seem to have solved the issue myself.
Just for pure sanity, I tried to detach and then re-attach the .mdf file on the second computer (the one that was not picking up the INSERTed data) and got an error about the LocalDB instance being a version too old for the file.
Turns out the computer on which the INSERTs were done was running a v13 instance and upgraded the .mdf file to that version, while the other computer was running a v11 instance. Both computers are now running on the same instance version and the missing data is now showing.
I develop both on my desktop and laptop, and I am frequently switching between them. Are there any problems that could arise from keeping a project folder in my dropbox and always accessing/editing from there? I'm running the VS2010 on both, but W7 on one and W8 on the other.
I'm using it often. But I do experience some issues. It seems that sometime VS and Dropbox conflict. This shows by leaving some temporary source files or by errors during compilation of file being locked.
In fact I came here while looking how to solve them. But still they are only a little issue and I keep using it that way for a long time.
EDIT: It is not just me. See Visual studio 2012 and dropbox don't play nice together question on SuperUser.
I'm using Dropbox to host my project and I edit and build directly on there and have experienced no problems, ever. Win7, VS2010, CPP. I find Dropbox to be simpler and equally robust to than version control software. I'm a big fan. I should say Microsoft OneDrive once failed me, horribly, and I no longer trust it. With Dropbox, I always check the icon in the systray carefully to make sure it is finished updating before I turn my computer off.
I use both git and Dropbox, as I also switch which machine I'm working on. This way I can use source control with the rest of my team, while also able to pick up where I left off. My 2 PCs that sync are my one at work and at home. Both desktops, both almost always on and running dropbox.
Rarely I get conflicts, when a machine is offline or something. The solution 99% of the time is to simply delete any conflicting files. Because I'm constantly up to date with git, it's fine if I ever have to delete all my local code, since I can always get it back.
So it's really for nothing other than being able to run out of work on an urgent task, and then resume where I left off when I got home.
Occassionaly, but fairly often, for no apparent reason, VS 2012 will lock up with a dialogue that says, "Waiting for a background operation to finish". E.g. this may happen during a plain old code edit, not on explicitly invoking any IDE command.
What causes this, and is there anything I can do about this?
I am running ReSharper 7, and I am not the only one I know experiencing this.
I was having the same problem, especially in cshtml pages. I found this page: https://devblogs.microsoft.com/aspnet/visual-studio-11-beta-razor-editor-issue-workaround that suggests changing the indent option in Tools > Options > Text Editor > HTML > Tab to Smart instead of Block. In my case it was already set to Smart and changing it back to Block fixed the problem.
Update: I was wrong, that didn't fix the dialogue, it just delayed it until I copied or pasted. What finally worked for me was to go to Tools > Import and Export Settings... > Reset all settings.
Possibly related question: Visual Studios 2010 - Asp.net MVC 4 Beta - long delays on paste and frequent crashing
It is a very generic diagnostic. It is triggered by COM, heavily used in Visual Studio to implement extensibility. The underlying trigger is the IMessageFilter interface. The trigger occurs when COM marshals a method call to another thread and that call doesn't complete for 60 seconds.
There's little value in the actual notification, it is telling you something you already know. By the time 60 seconds have passed, you typically already have noticed things are not working well. Short from the wee bit of useful knowledge that Visual Studio isn't actually completely dead. The call however has to complete before VS gets usable again. There's little you can do but tap your foot and wait.
This problem is almost always caused by an add-in. Resharper is certainly a good candidate. You find the trouble-maker by disabling the add-ins one-by-one until the problem disappears. It is the kind of problem that's common with new versions of Visual Studio, it takes the add-in vendors a while to get the bugs and hangups ironed out. Contact the vendor for support and in general look for updates that may solve the issue.
Deleting the Solutions "suo" file worked for me.
I was having the same problem and in my case it was DevExpress.
It seemed to hang Visual Studio everytime I did a copy or cut operation, bringing up the message:
"Waiting for a background operation to finish".
Turns out it was actually doing a one off task in the background and it really was taking a while to do it (over 5 minutes).
Perhaps if I had waited normally, it could have gone away, but what finally fixed it was to bring up the Toolbox into view (was hidden/collapsed), which in turn brought up a window saying:
"adding [SomeDevExpressAssemblyNameHere].dll"
this kept updating itself with the name of every dll required by DevExpress to populate the toolbar.
This way I could see the operation progress and after it finished I could use copy/cut paste again as usual.
Hope this helps.
For me the fix was to update the Web Essentials 2012 to version 1.8.
The problematic version was 1.6
Tools > Options > Text Editor > HTML > Tabs -> Identing -> None settings solved this problem for me.
This fixed it for me:
Tools > Options > Text Editor > HTML > Miscellaneous
Uncheck the option "Auto ID elements on paste in Source View"
I will post an update if the problem comes back.
I had this problem for a couple of days, tried uninstalling and reinstalling my visual studio 2012 ultimate edtion SP3...
Still didn't work.
So I deleted all my extensions (git tools for VS 2012 and Nuget Package downloader),
restarted my VS and it worked liked a charm again!
Hope it works !
Good luck!
I experienced this problem while running visual studio in a virtual machine - Virtual Box 4.2 running on Mac OS X Mountain Lion, hosting a fresh Windows 7 install with nothing else installed but Visual Studio. I found that the problem was caused by 2 separate issues.
Firstly, my project was on a folder shared from the host OS. In other words, on the Windows Guest, my project appeared on a network drive. So opening the project in Visual Studio from a network drive seemed to cause this problem because the problem went away when I copied the project onto the C drive of the Windows VM and opened it in Visual Studio from the copy on the C drive.
Secondly, I began to experience the problem again when the hard drive on the virtual machine was getting full. I had about 1GB free space available on the hard drive. When I increased the size of the hard drive on the virtual machine, this issue went away.
Just reproduced similar problem with Codemaid add-on. Found this conversation:
There's a lot of details in this issue, but to try and recap the issue
is that the VS2012 C++ API introduced a deadlock issue when the API is
accessed from a UI thread (e.g. a WPF context like Spade). It wasn't
an issue in VS2010, and Microsoft has fixed it going forwards for
VS2013 but they will not be patching it for VS2012.
Seems to indicate that a fix (for Codemaid) should be coming:
Please keep an eye on this thread for the ongoing resolution of the
issue. It ties in to that larger rewrite so I've been building towards
it by adding a lot of unit tests first to help ensure functionality
remains consistent after the changes.
For me it seemed to be related with the razor syntax, since I only had it on one particular file.
For example if I put the following code in one line I had the described issue.
#section BodyClassName {note}
But when putting the closing parenthesis on the next line the issue went away
#section BodyClassName {note
}
Kind regards
Stijn
Far from an ideal solution, but please trying running visual studio in administrator mode
i tried virtually everything, and this was the only thing that worked for me
Open Visual Studio, create a new MVC application, close the new application, open the old application and it works!
Check if IIS or another process (BizTalk maybe) is locking your DLLs/references
Kill/stop IIS or the other process if it is
http://geekswithblogs.net/sevenfortytwo/archive/2006/11/23/97947.aspx
RUN> iisreset
Now it is working fine with VS 2012
i think i have found a clue! Every thing is ended to dcomcnfg.exe!
Open it and go under following path:
Component services>computers>my computer>dcom config
after click on dcom you'll see many warnings depend on amount of components on your pc.
Click yes on each message box in order to add correct record for dcom.
I found that VS also loads packages during the "background operation". You can remove unneeded extensions to make the operation faster.
I have it fixed weeks ago after I turn TeamViewer 8 Clipboard Sync off! now it appears back with no reason so I tried reset all settings and it worked for me.
I was having the same problem and running VS as an administrator seems to have done the trick for me (I had posted a similar question at Visual Studio 2012 Express Hangs with Message "Waiting for Background Operation to Complete" on Format Document Command that was marked as a duplicate for this one so I figured I would share here as well).
For me, it was Resharper addon opening a dialog which didn't show. I only found the dialog icon in the hidden icons menu on the task bar. When i got rid of the dialog, Visual Studio returned to normal immediately.
We are working with Visual Studio 2010 and Team Foundation Server 2010. We did not have any problems for about half a year, but:
Since a couple of days we get the following error: Team Foundation services are not available from server (...) The remote name could not be resolved; (...)
The problem occurs randomly (we are unable - yet - to pinpoint the conditions on which it occurs) and persists until we restart Visual Studio. The problem occurs about 8 times per day per developer.
Because we seem not to get past this problem and we cannot find anybody writing about this specific combination (the error and the 'remote name' part), I thought it wise to ask you guys about it ;) . Could anyone please help?
This is a client, server or infrastructure related problem on network level. The DNS entry for your TFS server cannot be resolved correctly at times for host dfz-vm223.
Suggestions for troubleshooting:
On some developer systems, replace the hostname dfz-vm223 by the ip-address of the TFS server. If the problem stop occuring there the DNS system is instable.
Setup a continuous ping stream (ping -t dfz-vmm223 from command window) and see if the host system is pingable in case you have TFS server problems.
Just found out what the problem was: the problem is proxy related. When we disable our proxy, the problem is gone. It appears our proxy and TFS are troublesome together. If anyone experiences the same problem and you are working with a proxy server, I would suggest you try disabling the proxy too.
I had the same problem, although I'm using VS2012 and a WAN connection to TFS.
I solved the problem by flushing the DNS cache.
To flush the DNS cache, start a command prompt with admin rights: ipconfig /flushdns
You need to do this in all the computers where the problem occurs.
I know this is old, but I had this problem sometimes when I ran Fiddler.
Sometimes Fiddler would crash or not clean up properly and the whole machine would get into some weird state where not even reboots were helping. The solution to it usually is to start Fiddler again, turn off any interceptors/collecting traffic and shut it down again.
Some of my co-workers and I had this problem as well. Out of about 25 developers, most never got this error. But three of us got it pretty consistently. The symptoms are identical, but we are using Visual Studio 2013 almost exclusively. In this version of Visual Studio, the error is preceded by the code: TF400324.
We found eventually that the three of us had all installed Productivity Power Tools 2013. And the developers that were not affected by this error had not installed it. Most had not heard of it. This used to be a very popular extension, so I have always installed it as I set up my system since about 2007. But apparently, in its modern incarnation in Visual Studio 2013, perhaps in combination with some quirk in our network or something, it can cause this problem. We have each uninstalled it, and have not gotten this error since. (It's been several months now.)
If you have this extension installed, you probably already know about it, because you probably installed it yourself. You probably started using it years ago, and it became a habit to add to each new installation. You will find that today, the default installation of Visual Studio actually includes most of its features already. To uninstall, go to Tools --> Extensions and Updates... Then click on Productivity Power Tools 2013, and click Uninstall.
Hade the same issue. For whatever reason the windows DNS Client service on my PC wasn't running. Changing it from Disabled to Automatic solved this problem for me.
Too long for comments:
First off, as #kroonwijk stated, this is an infrastructure issue. Your DNS queries are either timing out or the DNS server is not responding at certain times.
In a comment you mentioned a change over from regular machines to laptops for your entire dev team. If I had to make a bet I'd say that the DNS configuration on the laptops is not the same as what you had on the other machines.
You need to take this up with your infrastructure people. If you still have access to the older machines boot one of them up and compare the IP configuration. If not, get them to fix the problem. The DNS resolution problem could be any one of a number of factors. For example, the new machines could be pointing to an incorrect DNS server that has network issues or their might be some incompatibility between how Win7 makes DNS requests and your DNS server.
I have also experienced this problem and it doesn't always have to do with name resolution.
If you add an entry to your %systemroot%/system32/drivers/etc/hosts file for your TFS server, it removes any dependance on your name resolution servers.
If you are still experiencing the problem, then it has to do with either visual studio or one of the VS Extensions that you are running. There may be a memory leak somewhere. Disable all your Extensions using the extension manager, restart VS, and see if you still experience the problem.
I am getting very annoying message called "system.outofmemory.exception" while I do have a lot of unused memory in my laptop. Unless I closed and re-opened the solution, it won't letting me to continue my work.
Is there any configuration or service pack that can fix the issue ?
Thanks
My Solution was was fine in the Visual Studio environment.
But when I was trying to execute tha builded project I was getting System.OutOfMemoryException
After few hours I change the my Comodo Antivirus Settings. I made the builded solution as trusted file.
After that I did not have this problem any more.
Maybe it help you... too
Try reinstalling VS and run a memory check. If there's any update that is able to correct an issue like this, it's maked as important on Microsoft Update, so be sure to run it and select all the updates marked as important. Also, check if running VS as administrator solves the problem, sometimes a normal user has some limitations (on business' networks it's possible that the IT limits memory usage by program, and windows 7 has some new security policies that I'm not sure how they work yet but running a program like adminitrator usually solves the problem).
I have this issue on a daily basis on a WinXP with 4GB of RAM (only 3 utilized, obv). As soon as VS 2010 Ultimate closes onto 700 MB of memory usage, I start getting OutOfMemoryExceptions. Only redemption is to restart VS, even if I close other memory-consuming applications. I also notice that the problem sufaces faster if I run unit tests. Probably because this is a memory-intensive task.
I see two separate issues here.
Visual Studio reporting out of memory when there really is available memory in the OS.
Visual Studio goes into a malfunctional state after the exception, unable to acquire new memory freed by the OS.
1) may be OS-related and not VS, I don't know enough about memory handling in Windows XP to be sure about this. I belive 2) is a VS-problem and should be fixed.
VS reinstallation is temporary solution. Jus increase your machine Virtual memory size. this resolves this issue.
ref below link -
http://windows.microsoft.com/en-in/windows/change-virtual-memory-size#1TC=windows-7