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.
Related
I have inherited an ExtJS project that uses ASP.NET Web Handlers (ashx files) to access a database.
I'm trying to debug the connection to the database which is in the C# portion of the code.
I've tried adding a break point just before the connection to my database is made, but I can't seem to get the application to stop there. They only briefly turn white during debug-execution. Hovering the mouse over the breakpoint when it's in that state shows:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
I've been all over this question, with no better results
In the modules window, the Symbol Status of the DLL does indeed show Symbols Loaded.
The dll/pdb both seem to be copied over to C:\Users\myid\AppData\LocalTempTemporary ASP.Net Files\etc.
(this seems odd, because I would expect it to attach to the .dll in my work folder) Is there a way to tell the debugger to look there instead?
There of course is no exe since this is a web app.
I've:
tried cleaning the solution and rebuilding fresh including a fresh pull from the repository.
verified the build has the "Define Debug Constant" and "Define Trace Constant" are checked
deleted the contents of Temporary ASP.NET
checked the the project was set as Debug
checked that "Just My Code" was disabled in Debug / General
restarted the workstation completely
checked that the Solution has the right project starting (there's only one in it)
checked I'm building in debug (not release)
made small changes to the code to force a recompile
checked that "Automatically determine the type of code to debug " is selected in Attach to Process
run as administrator
checked Optimize Code is not turned on in the project properties
checked that "Use Managed Compatibility Mode" is turned off
There is no aspx involved so the CodeBehind/CodeFile issue is moot.
Beyond that, that answers are very much repetitive or I tried something at random and it worked.
What have I missed? Is there something basic that you are supposed to do with the project so it will let you debug the DLL that perhaps the original developer didn't do (no they aren't available to me)?
Problem resolved...
Ultimately there were two issues.
Originally, the DLL had been compiled as 32bit DLL which didn't play nice with the database (Oracle 64bit). Switching the platform target should have resolved the issue except, IE's cache of the web page hid the fact that I was now getting a classic "Could not load file or assembly xxx or one of its dependencies." error. [incidentally, I've now sett he cache to clear on exit]
This error was caused by IIS Express running in the 32 bit version instead of the 64 bit version. Which means the DLL never really run, and explains the "No symbols have been loaded for this document." warning.
That was then resolved by going to Tools -> Options -> Projects and Solutions -> Web Projects and turning on Make sure that Use the 64 bit version of IIS Express for web sites and projects.
Clean and rebuild, and everything works tickety-boo
I am a C# winforms programmer, not used to ASP.Net.
As a winforms programmer I build regularly to detect syntax errors.
Recently I opened a Kentico website in Visual Studio and to my surprise found that there were build errors.
Does this matter?
My instinct is to go about correcting the site until it builds. This is a side track from what I set out to do.
If you are attempting to build any kind of quality into your project/software, then yes, it does matter if it builds.
Regarding Kentico and build times, if you're using a website vs. a web project, yes the build times are typically longer and range anywhere from a few minutes to I've seen upwards of an hour. The build times depend greatly on the machine building it as well. So if your machine has a Celeron processor, with 1GB of RAM and a 5400 RPM drive, you're going to take longer to build than a machine with an i7 processor, 16GB of RAM and a solid state hard drive that can read/write 500+ MB/s. Also keep in mind Kentico out of the box has over 9000 system files in it so as a website, it will take some time to build.
One of the first things I check when a site doesn't build is to ensure all the referenced DLLs are in the website/project. If not, this will cause several errors and is usually a very simple fix. If you have any kind of errors from code which resides in the /App_Code directory, your site will NOT run at all when you publish it. If you have errors within any other directory, the site will run BUT wherever those code files are referenced on the website, will display errors. So in your instance if you have webpart files in the /CMSWebparts/OurCompany folder, if those webparts are placed on pages within the website, those pages will error out even though the rest of the site is running.
In my opinion, just fix the errors and be done with them. Then check the code into a version control system to keep track of the changes.
Does this matter?
It depends on what you are trying to achieve with your website. If you want to make it available to the public then building is definitely something you should consider as top priority. If on the other hand you want to have the source code open in Visual Studio on your local machine, just for reading purposes, then building is not necessary.
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'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 have a solution with 2 projects in Visual Studio 2008 SP1, .NET Framework 3.5 SP1.
a ASP Web site.
a Class Library (dll) project.
I have a reference from the Web Site to the Class Library, as the Class Library is my data layer. But anyway, the thing happens only with this basic setup, a solution with these 2 types of projects and a reference from the Web Site to the Class Library.
Now, each time I modify something in the Class Library and I build it, Visual Studio creates a file called app_offline.htm and then deletes it (it sends it to the Recycle Bin).
This is really annoying because at the end of the day I end up with a full Recycle Bin and me, being the perfectionist I am, I want to keep it clean. I'm not the only one with this problem: here and here.
I know now the cause of the problem, but still not how to fix it. If you didn't hear about app_offline.htm before, here's ScottGu's article on app_offline.:
Does anyone know a solution to the problem? Some setting in VS to delete the file forever after the Build process? (I really don't want to set my Recycle Bin to do that, as I do delete things unintentionally from time to time and I'd like to be able to recover those.)
This file does not go into the Recycle Bin for me. Perhaps you have some draconian utilities installed, which do this? Many anti-virus tools and general system utility suites used to do this back in 2000 but I do not have experience with later versions.
Update: You can use Process monitor to find out which process moves this file to the recycle bin.
[Disclaimer: I'm adding an answer firstly because I hope it will get the question seen by more people (I admit it) and secondly because I have no characters limit on an answer, as oposed to a comment.]
I followed Sander's suggestion and used Process Monitor to track which process moves this file to the Recycle Bin.
It was indeed devenv.exe.
There are several events where it makes operations like: QueryDirectory, QueryOpen, CreateFile and CloseFile. And devenv.exe is the only process that has anything to do with app_offline.htm
Still... How could I make Visual Studio stop filing up my Recycle Bin? (way to go, Dan, putting a question in the 'answer' (: )
I started seeing the same problem shortly after we suffered a VSTS server problem. The VSTS server went down for a day so I had to open the solution in offline mode. After the VSTS server came back online, I had to reopen the solution under source control, and the app_offline.htm files start occurring non-stop every time I recompile my web projects.
THIS IS REALLY ANNOYING!
I am not sure how to stop it yet, but I know how to reliably recreate the problem on my environment:
Windows XP Pro, VS2008, SourceGear (Source Control System).
Whenever I perform a checkout, the app_offline.htm file is instantly created and deleted in/from the root folder. The source control system is using SQL Enterprise, so I am not sure it is related to some references from posts people are making about SQL Express.
Again, still don't know how to stop it, but maybe this will help other figure out how/when the file is generated and deleted.
Use Web Application projects, not the Web Site templates, those are for 'dummies'. :)
I had this problem because I published directly to Azure Web Service from the dev machine.
The answer here with another possible workaround here.
This is all I could find on the subject. Unfortunately it's also speculation.
http://petermcg.wordpress.com/2008/05/12/silverlight-app-offline/