Visual Studio 2019 is not updating a mex service reference. If I try to remove the service reference, the problem gets worse, and the service reference gets marked with a red cross and it is not possible to go back to the previous state.
The error message includes the error code 0x8007007c.
Restarting the IDE does not solve anything.
A system process misteriously blocked a file inside the service references folder, and Visual Studio doesn't make it clear with its messages.
Restarting the IDE wasn't a solution because the process was independent from the IDE. Rebooting the system (or finding a way to kill the process with the file handle) is the solution. Probably a Visual Studio bug.
Since it took me two hours and there wasn't any post citing this error code 0x8007007c and the correct solution, I came here to post the problem/solution I would like to have read before.
I need some help. I have put in dozens of hours into a VB.NET project, it has been built in release mode and distributed. Now I have to make some changes to it, and I am unable to debug it properly. My code changes result in behavior where my code is not even recognized.
Also, I installed Visual Studio 2013 recently (moving from 2010), but this project behaves the same in both environments.
I believe that my code has become 'optimized'. The error window tells me that code is being skipped over, and that my code is optimized and JIT is checked.
I have turned off JIT, and I have tried everything to make this project work again that I could think of. I am desperately wanting to know how I can get this project to be in a state where it will debug each line of code again when I make changes.
I can even purposely write bad code, and the debugger does not see it.
This project is now in debug mode, not release. I have checked and followed threads on every thing that other people have done to solve this issue, but nothing works for me.
Either my project launches and works properly as it is coded, or if I change any code only the form launches with no code being run - at all.
please help.
I finally figured it out. The applications that I was struggling with were all built in Visual Studio 2010 on Windows 10. I was trying to work with these in Visual Studio 2013 on Windows 7.
Once I tried to work with them on Windows 10 (visual Studio 2013 this time), they started working and debugging just fine.
I think it may have been DLL assembly paths? Took me more than a week, but I figured out my issue by moving from Win7x64 to Win10x64.
I'm getting the following error message
Cannot access a disposed object. Object name: 'MarshalingWindowFrame'.
This message came when I tried to load a SLN file into VS2013.
What is the reason?
I am using VS2013 Ultimate with Update 4 on Windows8.1 pro x64 bit OS (8GB RAM, 500GB HDD)
If you get that when opening a solution, either an addon is bugging out or (worse, but less likely) you found a bug in VS itself. Try safe mode and see if that helps.
If however you get the error when opening a form rather than the solution itself (remember opening a solution loads the various forms), there's a bug in an user control that's trying to access a disposed object. Remember that user controls run as binaries when hosted in VS, so make sure you put actual code inside guards that require you not to be in design mode.
Was that project created in the earlier versions or in the Visual Studio 2013 Preview? Because, if you update this project from Visual Studio 2013 Preview, you have to check the update procedure (http://blogs.msdn.com/b/lightswitch/archive/2013/08/12/upgrading-your-lightswitch-projects-raghuveer-gopalakrishnan.aspx) first, perhaps it can give some hints why this happens.
What's the reason for error message "The snapshot is out of date and cannot be used anymore because type tree has been updated, A new snapshow needs to be acquired"?
This error appeared right after I launched VS2010 and added username/pwd to connect to TFS repository.
I am using VS 2010 professional edition.
It happened to me with VS2012 as well after loading the project without source control binding, a local simple WinForms project. All I needed to do was Clean & Rebuild. After that the problem was solved.
This is a bug in Visual Studio. According to http://connect.microsoft.com/VisualStudio/feedback/details/742959/the-snapshot-is-out-of-date "We've taken a closer look at this problem and it isn't one that we'll be able to solve in the next release of Visual Studio."
They recommend waiting around until the background language parser service is done (or, in other words, don't try to be too productive there partner.) My experience is that closing all documents, cleaning the solution, rebuilding it and then closing and re-opening with a pause after does remove the error.
Until you do something silly, like edit code. Then all bets are off again as to when it reoccurs.
I had a similar issue with VS2012 and after rebuilding the solution twice, I still saw the same error message.
Following an advice from a post from this site, I closed the Designer tab, reopened it from the Solution Explorer, and the problem was resolved.
I got this error too, but after I unload project and reload project, the problem was resolved.
Simply restarting Visual Studio 2012 was a workaround for me, but it kept happening about every hour and having to restart visual studio that often was very annoying.
I also found this post which suggests that the Productivity Power Tools are the problem and to simply turn off the Automatic Brace Completion in Tools->Options->Productivity Power Tools. Since making this change I haven't seen the error message again :)
I'll note though that I am using Visual Studio 2012 and the OP is using Visual Studio 2010, but the Productivity Power Tools are available for VS 2010 too, so this may still fix the problem in VS 2010.
The same issue persists in VS2013, but no amount of Clean/Rebuild or restarting VS will help. The only way I can do a successful publish, is to disable the AutoT4MVC extension.
I got this error too. I closed Visual Studio 2012 and opened it again and the error was gone.
I got this error when I had conflicting class names / namespaces. I was referencing a UserControl from a different DLL in my XAML file which had the same name as my XAML file (class name). Maybe this helps.
I used Visual Studio 2012, and just faced this error on my Windows 8. It seems like Turning off the VM and restarting Visual Studio fixed the issue.
I just got this with VS2010.
I had a form with a user control (UCa) with a user control (UCa) from a different project on it. Made a change to the UCb then flicked to the designer for the form and boom! Snapshot error.
Resolved by a full clean and then rebuilding just the UCb project before building the rest of the project.
I'm using Visual Studio 2012, and I got this error when starting Visual Studio, letting TFS connect to the server, and THEN opening my solution. The fix was simply closing VS and launching the solution directly.
I'll throw my two cents in here as well.
I've tried every combination of Clean, Rebuild, Restart, etc. What I've found is that restarting Visual Studio usually makes the problem go away for at least one Publish. Here's the weird part, though. You can also fix the problem by doing absolutely nothing. If you just let Visual Studio sit for about a minute or two, and then publish, it will usually work just fine. There's some background voodoo going on here, and waiting for it to finish seems to do the trick.
I have a solution with two parts that need published. One is a WCF service application, and the other is the ASP.NET MVC5 website itself. Anytime I publish the services, and then try to publish the site I'll see this error. I can publish the services, restart VS, and then publish the site, OR I can publish the services, go get a drink, and then publish the site. As long as I give VS a chance to "settle" between any kind of rebuild and the publishing of the site, everything seems to work as expected.
Take a walk, come back, problem solved. OR if you don't have the time. Clean, Rebuild, Restart, Publish (lather, rinse, repeat).
I have a periodically occurring problem when building with Visual Studio 2010.
Sometimes it refuses to build with an error message like:
Error 102 Unable to copy file "xxxxx\Debug\Services.dll" to "bin\Debug\Services.dll". The process cannot access the file 'bin\Debug\Services.dll' because it is being used by another process.
The only remedy I have found is to restart Visual Studio. Closing the solution is not enough.
I have tried to find the culprit with Process Explorer since I suspected that one of my own threads didn't close down as it should. However the process is devenv.exe, i.e. Visual Studio itself. Also I get this symptom only with VS 2010 even when building upgraded VS 2008 projects. I never experienced this problem with the same projects under VS 2008.
I have a lot of custom made WPF user controls and I have a theory that it is the WPF designer that sometimes hold on to the control's dependent dll's when it should be releasing them for a build. The theory is not well established since this is a periodic problem and sometimes it occurs without the designed being open. I also have the same problem for a windows forms project. Sometimes I get through a day without a locked dll. Sometimes it is every other build or so.
I have asked Microsoft about the problem and they told me to make a dump of Visual Studio and debug the dump. I didn't find that to be sound advice.
Have anybody experienced something similar? It is really annoying.
Update 1
Since this appears to be a Visual Studio bug and Microsoft has responded that they do not intend to do anything about it I would like to encourage everybody who works with custom user controls to up-vote this bug at connect.microsoft.com.
The bug is both reported here: https://connect.microsoft.com/VisualStudio/feedback/details/587281 and by me here https://connect.microsoft.com/VisualStudio/feedback/details/568672
Update 2
I have hacked together a simple Visual Studio macro that closes down all .XAML files before building. So far I have not experienced the lockup with this macro.
Add the following macro in Visual Studio and assigned to your favorite build short cut. Maybe / maybe not that will fix the problem.
Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports EnvDTE100
Imports System.Diagnostics
Public Module CloseXamlAndBuildModule
Sub CloseXamlAndBuild()
For Each myDocument As EnvDTE.Document In DTE.Documents
If myDocument.Name.EndsWith(".xaml") Then
myDocument.Close()
End If
Next
DTE.Solution.SolutionBuild.Build()
End Sub
End Module
I finally found a stable working solution. I realized that the source of the problems were initializing code in the constructors of WCF services and WPF controls. After cleaning the constructors from any dependencies to other assemblies everything has been fine.
Try using VSCommands plugin.
It has option to 'Apply Fix' that will allow you to close any process which keeps the file locked (most often than not it is vshost process which can be killed).
This is a fairly persistent complaint about VS2010 although it is not wide-spread. I haven't seen a good diagnosis for it yet. The feedback item to watch is this one, it seems to be the collector for most duplicates. Getting it resolved quicker probably is going to require opening a case at Microsoft Support.
I actually reported this problem to Microsoft Connect a while ago, but had not checked up on the issue in a while.
My original report to Microsoft is here.
Among the comments is a way to reproduce the issue with custom user controls (as I suspected).
Microsoft just replied with a standard "thank you for your feedback, your suggestion does not meet the criteria to be addressed". Thank you Microsoft. I guess I will just have to live with restarting Visual Studio a couple of times every hour.