I get this error repeatedly when developing ASP.Net applications:
Cannot create/shadow copy 'XXXXX' when that file already exists
Where XXXXX is a random DLL. Typically the DLL is one of the DLLs from Microsoft's Enterprise Library, but it varies.
It's really random, and it's very frustrating. I will go hours without getting the error, and then get this error every 10-20 minutes.
I've seen several solutions. For instance, this question. I've tried using Clean Solution option, and I've also simply restarted my local IIS. However, it still occurs at the same random but persistent frequency.
I've also seen many people mention using this option in the config file:
<hostingEnvironment shadowCopyBinAssemblies="false" />
However, others have mentioned it being problematic, and it should definitely not be used in production.
So, should I just give up and try the shadowCopyBinAssemblies option? (And make sure not to copy this change to other environments.) Am I the only one who gets this issue that often?
Note: I am using Visual Studio 2008.
Wait somewhere between 10-30 seconds and hit refresh. For some reason this always works for me.
The following workarounds come from this now defunct connect issue:
add <hostingEnvironment shadowCopyBinAssemblies="false" /> to the <system.web> section of your web.config file.
Restart Cassini when you get the problem
If you get the error, stop the debugger, right click the solution and "clean solution". Hit F5 to restart debugger. This is really annoying as it has >50% fail rate for me and you would think that there should not be a manual option to CLEAN SOLUTION! This $1200 POS application should clean it for you automatically!
Here's another workaround that may be more appealing to some, courtesy of Gary Farr (http://blogs.claritycon.com/blogs/gary_farr/archive/2007/03/09/2888.aspx).
Add the following to your pre-build events:
IF EXIST $(TargetPath).LOCKED (del $(TargetPath).LOCKED) ELSE (IF EXIST $(TargetPath) (move $(TargetPath) $(TargetPath).LOCKED))
A workaround that does the job for me is instead of using "Build" use "Build Solution"
After a successful build, I count to ten, then I refresh my webform.
I have found that by re-registering ASP.NET against IIS the problem "goes away" - I haven't had the problem since. You will need to run the following on the command line: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i. This more than likely won't work for everyone - it's a complex problem.
restart VS.
When Cleaning the solution, a few warnings were issued about files that could not be deleted. These files had their read-only property set. After setting the property of these files to read/write, the problem was solved.
Restart IIS
EDIT: Items retrieved from an old version of the page (courtesy of archive.org).
Just restart Visual studio, that worked for me.
Open your project properties, open the Web tab and make sure the Enable Edit and Continue option is not checked.
In my situation only iisreset worked.
I was getting the same issue, by placing this code in a web.config in <system.web> section it worked fine for me.
<hostingEnvironment shadowCopyBinAssemblies="false" />
I was getting this issue frequently when working with an imported DLL which we created.
Attempts to stop is happening failed, and even introduced different problems, but whenever it occurred I would just do a rebuild solution and the problem would immediately disappear for that build.
Also, I haven't seen the problem since working on Visual Studio 2002. 2008 does not have this issue that I know of, neither does 2005. Are you using an older VS?
GO to the design mode and then right click and hit view in browser, the issue will go away
Anil Madan
Add these lines in the pre-build event command line, which basically unlocks the DLL within Visual Studio:
IF EXIST $(TargetPath).LOCKED (del $(TargetPath).LOCKED)
ELSE (IF EXIST $(TargetPath) (move $(TargetPath) $(TargetPath).LOCKED))
Re-compile and your unable to copy DLL error will not occur.
If you use Entity Framework:
Error Message:
"Cannot create/shadow copy '' when that file already exists."
Solution:
"Wait a few seconds and refresh the page."
For more information please visit: Advanced Entity Framework 6 Scenarios for an MVC 5 Web Application (12 of 12)
You just Refresh (F5) your page.
Related
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.
My company gave me a web application project and I went to debug it and set some breakpoints and they dont fire. I am using Response.Write all over the place to debug. Anyone know what maybe going on?
I am running the application off my localhost I was pushing F5, but since the breakpoints dont hit by making changes and adding Response.Write statements and clicking save then refreshing my browser I get the changes for whatever reason.
Hovering over the breakpoint it says "The breakpoint will not currently be hit the source code differs from the original version"
Another tidbit is I created a new web application project and created a breakpoint and it works, its only specific to this application it seems like, but dont know what it could be?
Hovering over the breakpoint it says "The breakpoint will not currently be hit the source code differs from the original version"
Try this:
Close Visual Studio and make sure any instances of ASP.NET development server are closed as well
Delete everything from "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files" (where v4.0.30319 is the version of your .NET Framework)
Definitely need more info, but I would check that your are building with debugging symbols to cover the dumb stuff.
Okay, after reading the comments posted on your question I was making the following assumptions.
You are running using the built in VS development server
You are compiling in debug mode
You've set debugging true in your web.config
I've seen this problem before and for me it's been resolved by restarting Visual Studio.
Assuming that you are running on IIS on the same machine that you have visual studio installed:
Have you attached to the application pool process
Is you code the same as what is deploy? (Is the latest version deployed)
Are you logged in as administrator?
Are you running visual studio as administrator?
Just to make sure, you are running in debug mode?
I ran into this problem a while ago as well, instead of using response.write, you could try outputting the data to a label control's text value instead to see the values of your code.
It's a bit of a sloppy work around, but I couldn't figure out why that one particular project I was working on didn't let me debug it.
This problem is, for me, mostly caused by a mismatch of the loaded dll files (symbols) by webserver, and those that the project are pointing to when you try to breakpoint. It's different files. I have located different causes. One could be a simple hang-up by webdev instans (force shutdown. But also that there occur some kind of mismatch if you got different compilation methods between project within same solution as the web project.
This desc may not be your exact problem, but perhaps it will lead you into right direction. I find this often being a dirty unlogic error that just are irritating (but also completely fixable without data loss or reconfiguring, when u understand the trick).
I had the same problem, and it turned out only Internet Explorer works with debugging and breakpoints. To avoid having IE as my default browser, I changed the launch settings in the .Web project to run IE with the path as command line parameters.
I know that many people have had this problem... but I am now having it and cannot solve the issue. VS 2008 is randomly giving me an error after working on a project for weeks. When I set a debug point, I get a warning: The breakpoint will not currently be hit. No symbols have been loaded for this document.
I have re-built the solution with no debug points and re-tried. I have also tried to Load Symbols from path and that has not worked either... Can someone please help walk me through the necessary steps to getting my debug function working again.
Thanks.
Delete the solutions suo file. This has fixed weird debugging problems with breakpoints every time for me. Note, you will lose your solution settings, such as bookmarks, breakpoints, and such.
1) Does creating a new project work? If so, you have a corrupted settings somewhere. Moving your files over to your new project would be the easiest procedure to resolve your issue.
2) Does taking your solution to another PC work? If so, then you have an issue with your environment.
Try these checks in order:
1) Select your Configuration Manager, check if your CPU is "Any" or your "x86" or "x64" depending on your hardware.
2) Try remove all the other configuration other than Debug. Add a new Configuration based on your Debug and the CPU as Any
3) Drastic move.. close your visual studio and run the following
devenv /ResetSettings
4) Even more drastic move...
devenv /Setup
Good luck
There is a hotfix for Visual Studio SP1 regarding debugging issues here. It did fix issues I had with catching breakpoints in multithreaded source code. It also fixes other potential causes for breakpoints to be missed, so it is definitely worth a try.
Also, have a look at this SO question.
Regards.
I run into this occasionally and each time the solution is a bit different. This time I was using a different user profile to develop than I normally do in Visual Studio 2008 and found that I couldn't debug (breakpoints cannot be hit) shortly thereafter - on a solution with 2 vb.net projects. I ended up doing 2 things but I think the latter did the trick for me.
In the main projects properties, go to the Advanced Compile
Options button on the Compile tab and ensure the "Generate debug
info:" is set to Full.
Right-click on the main project and
select "Set as a startup project"
I'm going crazy and wasting a lot of time. I am running in DEBUG, checked the web.config to ensure debug=true is there, checked the code to ensure I am reaching it, cleared all temp files and pdb's. The only thing that works is to continually kill the solution, create a new solution and add all the projects again. I shouldn't have to do this every day.
If you're using Windows Vista, try launching Visual Studio as an Administrator. Even if you're already running as an Administrator on the machine, still right-click on Visual Studio and select "Run as Administrator."
Right-click the solution node in solution explorer end select Properties. Check the configuration settings in there.
If you are attaching to a process sometimes this can be caused by symbols not being loaded. If you see the code skip over your breakpoint hover over the breakpoint it will tell you if symbols were not loaded. If that is the case Here are several potential solutions to your problem.
Clear out all files in C:\Windows\Microsoft.NET\Framework\v2.0.50727\ASP.Net temp files.
Ensure you deployed the *.pdb files to the bin folder of your application.
The web process has not loaded your assemblies at the time you attach your debugger. Reset the process and wait a little longer before attaching to the process to give the process a chance to load your dll's.
Actually your visual Studio is not attaching your project with process WebDev.WebServer.EXE
Do the following Steps:
click on Debug Menu
Click on Attach to process WebDev.WebServer.EXE
Now your Debugging is enabled.
I never had this problem before, but I reinstalled my computer recently and Visual Studio is not behaving well in debug for an ASP.NET site.
I am attaching visual studio 2008 to the w3wp process to debug a website. When I am debugging a method line by line with F10, sometimes visual studio will decide that it continues until it encounter a breakpoint... It's almost like if I pressed F5 to let it continue, but I press F10. For example if a method call is called more than once and there's a breakpoint at the beginning, while I am debugging line by line inside the method sometimes the execution will continue to the breakpoint at the beginning for no apparent reason so I lose all my debugging...
Anyone had this problem before?
Thanks,
I have the same problem, whenever I press step-into or step-over it continues to execution as if I pressed F5.
Debugging is working only if I put a break point on every line I wish to evaluate.
Is anyone else experiencing this besides me and the poster?
I've tried re-installing VS and everything but that didn't help.
Furthermore, debugging does work in some other projects, to be specific WinForms projects, and when I press step into on the webservice call and "attach", debugging still works as it should.
OK, Update...
I have found that my problem lies with Optimizations in compilation.
I had optimizations turned on in debug configuration.
Make sure you uncheck that for debug configuration on all your projects and their references.
Also try: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193
The patch for this issue is here: http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796
KB957912 - Update for Visual Studio 2008 SP1 Debugging and Breakpoints
Cehck to make sure that your build mode is set to Debug not Release. In Release mode the optimizer is turned on and code can be rearranged or removed. Your breakpoints may make no sense from the perspective of the actual code.
You're probably debugging an assembly with an out of date PDB file, or perhaps the code has changed and wasn't recompiled.
In any case, it sounds like you have a mismatch somewhere between:
code
dll
pdb
(and as another guy noted, make sure you're building in Debug, not Release).
This almost sounds like the behaviour you get when debugging while having several threads or requests going on in parallell, alternatively if your method makes recursive calls. Are you sure this is not what happens?
I had the same issue after rebuilding my computer. After searching for answers, I found this thread. The solution for me was the hotfix found on MSDN, noted by a user in this thread.
http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796
--Notable discussion--
MSDN does also have a great topic discussion, also noted by a user in this thread, with some workaround and a link to the patch.
social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193
I have seen a post where the following line of code was placed at the beginning of Page_Load(...) method. Personally this was not an option for me, but if you are comfortable with this being a fix for your problem and it works...
Response.Cache.SetCacheability(HttpCacheability.NoCache);
My setup:
- Windows XP pro
- Pentium 4 3.0GHz HyperThreaded
- VS 2008 Professional Edition
- .NET Framework 3.5 SP1
- SQL Server 2008
- Development language: c#
For me it started working only after cleaning and rebuilding the solution.
You aren't using multiple threads are you? That could cause this behaviour.
And do you have this problem in different projects, or just in a single project?
Line by line debugging is F11 (Step Into), not F10 (Step Over).
Step Over will skip debugging on any methods you call.
Alternative thought - have you tried using step into (F11) instead of step over (F10). If you're finding that method calls appear to be "skipped", it's possible that you're executing over the next line without actually stepping into it...
Make sure your line endings are consistent. Windows likes CR/LF. Sometimes it gets confused about what line it is on if they aren't consistent.
Workaround found here http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193:
1) Open Visual Studio but do not open any projects.
2) Start the Task Manager (Ctrl+Shift+Esc) and navigate to the “Processes” tab.
3) Right-click on devenv.exe and select “Set Affinity…” (this option is only available on multi-processor or multi-core machines).
4) Uncheck every CPU except one and click OK.
5) Open your project and debug as normal.
Silverlight tools are not fixing the problem and the other patch provided in this forum thread either. This is the only working workaround I found yet.