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.
Related
I don't know when this started, but I discovered that Visual Studio 2013 Update 5 aborts when attempting to open properties for a project within a solution. It seems to only happen when we have more than one project in the solution.
I've been able to reproduce it in two circumstances:
The first project is C++ and the second project is Fortran. Right-clicking on the first project and selecting Properties crashes Visual Studio without a crash dump or any kind of pop-up notification. Visual Studio just ceases to exist. Right-clicking on the Fortran project brings up the property sheet without any problem.
The second circumstance is with two projects, both C++. In this case, I'm able to open properties successfully for the first project, but not for the second one.
In every case I've tried where there's a one-to-one solution and project, it's working fine. A colleague who's working with VS 2013 Update 4 verified that the crash occurs for him as well.
We don't know when this started, but historically, we've opened these property sheets many, many times. However, it's probably been a few months since I've worked on a mixed-language process, and same with my colleague.
I've turned on logging and there was a complaint in the log about two versions of the Desktop SDK having the same internal ID. I removed one of those altogether, but that didn't seem to affect anything. It's also not clear if that error has any relationship to the crash.
I've also done a repair on Visual Studio, and that did not correct the problem.
I've also tried deleting the .suo and .user files. Again, no luck.
I've done quite a bit of googling but haven't found anything that matches this specific problem.
Any ideas?
Thank you,
Doug
I have a solution with several projects that have Register for COM Interop checked.
I have a Visual Basic 6 project that references the resulting TLBs. One issue with VB6 is when it references a dll/tlb, it puts a lock on that file.
Using Visual Studio 2010, unless I'm doing a rebuild or have made a change to one of these interop projects, I can build/run the solution (with the VB6 project open) without it barking that one or more of the assemblies is locked.
However, using Visual Studio 2012, even on a simple build where nothing has changed, apparently it always does the regasm, which makes it impossible for me to debug my VB6 project.
Is this new feature of Visual Studio of running regasm on build something that I can turn off?
EDIT: Allow me to simplify:
Using Visual Studio 2010, I hit Build-->Build Solution and check the output for one of my assemblies that is marked as Register for COM Interop and the file has not changed.
Using Visual Studio 2012, I do Build-->Build Solution and check the same assembly, it has been updated, and does so every time I hit Build Solution.
I want the behavior in Visual Studio 2012 to work the same as it did in 2010.
EDIT (again):
I posted this to Microsoft Connect. If someone answers it there or posts a workaround, I'll urge them to also post the answer here.
I've always encountered problems like this when running VB6 and VS20XX, but I always did a rebuild. My suggestion is to stop using VB6 for testing purposes. I found it was far easier to simply create a testing project and do all of my testing in .NET on my .NET code. This should only require a small amount of set up, but it is well worth it in my opinion.
I know this isn't an answer to your specific question, but it offers an alternative. As far as the problem you are describing, I can't duplicate a change in behavior. I start off with only VS201X open, full solution rebuild, open VB6 and add a reference to an exposed COM DLL. I didn't notice anything unexpected.
Build works fine as long as I haven't changed anything in the COM DLL
Build fails if I changed the COM DLL's code as the file is locked
Rebuild fails as the file is locked
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'm debugging classic asp code using VS 2008 sp1 on windows 7. Everything works great, I attach to the process and can debug. However, If I stop debugging visual studio will crash.
I read the recycling the app pool would help, but it has not helped me end a debugging session with out crashing. I have hunted through Google and stack overflow for a solution, but so far I've mainly found complaints.
Has anyone figured this out?
Coworker found answer:
http://code.msdn.microsoft.com/KB967631
This QFE fixes three complete separate issues in the VS2008 SP1 Debugger:
Debugger can hang the IDE after setting a breakpoint when working with a large C++ project
Breakpoints do not bind correctly when an MSIL file is built containing .line directives
VS crashes when debugging a classic ASP web and debugging is stopped.
I have had this same problem and the conclusion I came too after scouring the web and reading other user's stories is that VS 2008 has a bug when debugging classic asp! It crashes when you stop debugging. Sort of a time killer to have to restart VS every time you debug.
I have had to resort to using VS2005 to open classic ASP projects and debug them there. If I need to have the ability to work on an app in both 2005 and 2008 I've found that you can have 2 separate solution files, each created by the applicable app (for example I've got appName.sln that I open in VS2008 and then appName2005.sln that I open in VS2005). You will need to create a new solution in VS2005 and add the files, then save that solution with the slightly different .sln filename. This works, it just takes a bit of time to setup.
Supposedly MS is going to resolve this issue in VS2010 but they didn't consider it an important enough problem to issue a patch for VS2008.
When trying to execute from within Visual Studio 2008 your application and you get the (uninformative) message "The operation could not be completed".
The solution to this is to turn off the "Visual Studio Hosting Process".
The problem with turning off this "hosting process" is that all the "run and rewrite" functionality is no longer available. OK, so this isn't a big deal, but I'm always getting this message no matter what machine I use (and it might be nice once in a while to use the rewrite and execute functionality).
Am I doing something wrong? How come this "feature" within VS seems to complain so readily? Do other people have success with enabling the hosting process and making use of it?
The problem with turning off this "hosting process" is that all the "run and rewrite" functionality is no longer available.
The Visual Studio Hosting Process is not needed to allow Edit and Continue. It is used for "Design time expression Evalutation" in the case where the project is a dll rather than an EXE. It is also used to provide debugging for partial trust scenarios. See the documentation for everything it does.
It is highly unlikely it does anything you need, so don't feel bad turning it off.
Is your project output folder set to a network share?
If so, try changing it to a local folder and see what happens. It appears that VS is not always able to terminate the process if the host exe is running from a share.
The other possibility is that the project is open and running in debug mode on another instance of Visual Studio - although I suspect you will allready have ensured this is not the case.
I honestly have never seen this message and I work with Visual Studio for at least 8 hours a day. Is this reproducible on other machines? If so is there anything weird or abnormal in your code that could cause this to crash?
I use 4 different machines and have got this situation on all of them. I understand what is causing the problem - it is that the VS hosting process isn't terminating after the first debug session ends, which means that the next time that you try to compile the exe the hosting process is locking the exe and preventing compilation. Another solution therefore is to use Task Manager to kill the VS hosting process and compile and debug as normal but thats even more of a hassle!
I can't think that its anything in my code that would be causing this - its probably a VS issue itself isn't it?
Here's the anwser: disable "Enable he Visual Studio hosting process" in he debug tab of your projects properties.
I found it here:
http://social.msdn.microsoft.com/Forums/en-US/vbide/thread/40d2d241-a0c0-4137-9da9-e40611972c0e/
There are several causes and workarounds regarding to this problem and you might try the following ones that are useful most of the time:
Delete the "Your_Solution_FileName.suo" file and restart Visual Studio.
or
Right click on the project and select Unload Project and then click Reload Project by right clicking on the project again might also fix it.