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 have a COM component that I would like to use from Classic ASP. It is registered correctly using both the 64 and 32 bit version of regasm, using the /codebase switch.
All assemblies are signed with a strong name (although the key is not protected with a password). When I register the types, I get a confirmation that they were registered successfully.
If I make a VBScript file that attempts to create the COM component, it succeeds without issues when I run it with both the 64 and the 32 bit version of cscript.exe.
However, when I try to do a Server.CreateObject on the exact same COM component, I get the following error:
Server object error 'ASP 0177 : 80070002'
Server.CreateObject Failed
somefile.asp, line 2
80070002
The line provided by the excepton just contains the Server.CreateObject statement.
The assembly is AnyCPU, and the type I am trying to expose has a [ComVisible(true)] attribute set on it. The rest of the assembly is not COM visible.
Any clue on what I am experiencing here? I tried giving full permission to Everyone for the DLL files because I originally thought it was an IIS issue. However, that simply doesn't seem to be the case.
I have Googled this for many hours and seen countless similar questions, but this is not related, since none of the proposed solutions work.
If it works correctly with cscript.exe and failed in ASP, almost all the time that is due to the security context or file/register permission issue. ASP runs under the IIS user realm, and you will need to ensure that user ID has access to all the resources (including temp file/folder) needed for your COM object.
I solved it, but as I suspected, it wasn't the same cause as seen in other questions.
Apparently if you try to register a DLL from a network share, it will provide those symptoms, although the message is "Types registered successfully".
Very scary.
When moving all my DLLs to a local folder on the machine, they registered and ran successfully without issues.
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.
I deployed an ASP.NET web application last night and I when I woke up this morning it was very slow and would occasionally just throw a 'Service Unavailable' error.
I checked the Event Viewer and it was filled up with these errors:
An unhandled exception occurred and the process was terminated.
Exception: System.Runtime.Serialization.SerializationException
Message: Unable to find assembly 'MonoTorrent, Version=0.80.0.0, Culture=neutral, PublicKeyToken=null'
I'm puzzled as it was working perfectly when I deployed it (MonoTorrent is required to retrieve the number of seeders/leechers for a certain torrent off the tracker - this was working fine), but it's no longer working and whenever code that uses MonoTorrent gets involved, the worker process just crashes.
MonoTorrent.dll is in the /bin/ directory.
UPDATE 6/4/10: I compiled the MonoTorrent source code in with the rest of my web application, but it still crashes whenever it uses MonoTorrent. However, it now says that it is Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. Here, OpenPeer is the name of the web application's assembly.
This can happen in these circumstances:
The ASP.NET app creates a background thread, which throws an uncaught exception. It looks like ASP.NET catches the exception and wants to log it to the Event Log. To do this, it sends this exception from the Web app's app domain to its own app domain (the default one of the w3wp process). This needs a serialization/deserialization of the exception.
If the exception is a custom one (i.e. defined by the Web app), it cannot be deserialized in the main app domain of ASP.NET because the assembly defining the exception is typically in the Web app's bin directory, not where w3wp.exe is (c:\windows\system32\inetsrv). This causes a serialization exception and w3wp crashes.
There are possible ways to fix the issue (in a - very subjective - order of preference):
Copy the missing DLL in c:\windows\system32\inetsrv
Install the missing DLL in the GAC
Remove the cause of the exception (harder to do than to say, as we say in French)
Catch all exceptions from the background thread yourself and do the logging yourself.
Notes:
If WCF is used and the uncaught exception is FaultException, WCF swallows it and there is no crash
If the uncaught exception is in the thread of the Web request, there is a yellow screen of death, not this serialization exception
It really seems like a bug in ASP.NET
The above is actually a summary of my investigations of this issue yesterday and are only a theory. I tested fixes 1 and 4, as well as using FaultException.
Here are some things you can try..
1.) Flush ASP.Net Temp directory. Restart IIS and recycle Application pool.
2.) Make sure your web-application is running in FULL-TRUST if it really needs FULL-TRUST.
3.) Take the Assembly, try to use it in other asp.net application and run the test application on a seperate server. This might help you diagnose the problem. Also try to run the test asp.net app on the same server but in seperate application pool.
4.) Make sure the IIS website of your application is running under the user account with necessary security priviliges. Try running the application under Administratotr as user.
EDIT-1
5.) Also check if the assembly version is the same as mentioned in web.config. If there's a version mismatch then you can do AssemblyBinding Redirection in web.config.
6.) Also try registaering the Assembly in GAC and see if it loads properly.
EDIT-2
7.) Try reconfigring ASP.NET support on the server or maybe framework runtime re-setup may help. This may not be a sure-shot solution but looking at the problem condition we may want to try various solutions.
8.) Make sure you're not missing any critical update of your windows server platform.
I try to give you some ideas - what I do if I was on your position.
First of all I take a long look of the MonoTorrent.dll before some days that you make your question, and I look it again today. I found and the function that load the dll. My first opinion is that something have to do with the permissions.
I hope that you have access to the server - right ?
My first steps is that:
Ensure that your monotorrent.dll actuall have the right permissions to the bin directory, for Read, and execute by your asp.net app. Some times the copy of one dll, did not get the directory permissions buts carriage out his own permissions. To check if your dll have different permissions from the rest, just right click and see Properties | Security, then go to bin directory and do the same, and compare the Security permissions. If they are different then apply again the Directory permissions and make sure that the dll inherited by the directory.
My second step
Download the ProcessMonitor from sysinternals
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Run ProcessMonitor and try to recreate the error, stop it and analyse to see where and why the dll gets the denied permissions to run.
With the ProcessMonitor you can even see if there is any dll that can not found !
I have check the MonoTorrent dlls and I do not found anything unusual. He have kerner32.dll calls, and use unsafe code to run, ok nothing so special about.
So if you do that 2 steps and give me some feedback, maybe I can go further. (if not solve by you and what you find)
I would advice to setup Regular maintanence probably once in a week at sunday night etc for following,
Delete all temporary files
Delete all ASP.NET IIS temporary files
Restart Server
Problem is, ASP.NET web apps cause lot of temp files to be left in the disk, because of dynamic compilation of regex, seriliazation assemblies etc, such temp stuff never gets deleted, and more and more junk starts getting collected in temp locations, ASP.NET goes slower and slower, and a point comes in where disk as well as memory defragmentation reaches very high point, things start to fail.
No body likes to restart server once a week, but I remember we had no choice, in ASP.NET 1.1 we had stable system after restarting every day, in ASP.NET 2.0 onwards, we are good to have restarting scheduled at once a week.
I have found this problem and I have do all of thing as I can, such as clear temp file, restart server, delete and add reference and I also rebuild the solution. However I can't solving this problem. Finally I move my entity class (almost of them need to serialize) to new folder that I have added to the project and then this problem solved.
This method is work for me.
Try clearing the ASP.NET temp files. It's solved some odd issues before for me.
Otherwise, Fusion-logging may shed some light.
UPDATE: #Charlie - I'm not sure what to make of those logs...it looks like the failed log is from a different AppDomain. Notice the AppBase is set to "file:///c:/windows/system32/inetsrv/" and AppName is w3wp.exe.
I'm pretty sure the Event Viewer should show Application Id: LM/W3SVC/#/ROOT if it was the default AppDomain, too. At this point, all I've got is random guesses.
I notice you're running x64...does MonoTorrent perhaps require x86?
Have you double checked that the directory is an IIS application, and is configured for the correct version of ASP.NET?
Is there some other application that uses MonoTorrent on this server? Maybe a WCF service or something? I'm not sure where the Serialization is happening....
Try hooking the AssemblyResolve event and loading it manually.
Can you repro on a development machine? If not, maybe it's a borked FX install. Uninstall and reinstall.
Does restarting, recycling or stopping/starting the AppPool fix the issue temporarily, or cause the issue to appear?
You may want to type out your screenshot text too so you'll get some Google love....
Is the server timezone different than your timezone? I've had this issue when deploying resource files, the compile time was in the future so they would fail to load.
My guess that you have plenty of open but not closed connections. I mean the connections are not returned to the pool. It looks okay, when you start the application, but after some time there are only several sockets available in the pool and it goes slow. Another thing - non-closed connection may keep DLL in memory, not allowing to release the handler. Try to debug object destruction.
I know it's simple but I had this problem once and itwas because I had a Web Application project which contains
References
Folder and I just copied my files into a
Bin
folder, in any .net web application in the Project Properties windows, a Reference Path tab is available which by default should nothing be include on it. check this option and also Build tab in Project Properties window which Output path be as the same as bin\
I have been trying to work on integrating a NewsLetter for a companies local intranet and I keep running into the same error that everyone seems to be getting. I am running this on IIS 5.1 and on error exists at Server.CreateObject(ADODB.Connection), also the purpose of the ASP code is to read an Excel file
Error Type:
Server object, ASP 0196 (0x80040154)
Only InProc server components should be used. If you want to use LocalServer components, you must set the AspAllowOutOfProcComponents metabase setting. Please consult the help file for important considerations.
I have tried the solution to locate to my AdminScripts directory and setting the boolean value to True with cscript adsutil.vbs set /w3svc/aspallowoutofproccomponents True and then verified by cscript adsutil.vbs enum /w3svc > verified.txt
Opening up the textfile, it does show that the value is set to true but I run into the same error again when trying to access the ASP page. I am at a loss, I figured after reading all those people post questions that I'd ask the question myself.
I cringe at the sight of that error messages, please make my nightmare end.
Its a bizare error to be getting in the first place. Why would the simple ADODB.Connection object be considered an out-of-process component?
The only thing I can think of that might cause this is if someone has accidently dragged the ADO dll into a COM+ Service. Check the set of COM+ Services anything unusual installed there?
In an attempt to repair you could download the latest MDAC from Microsoft's download area and re-install it on your machine.
Enabling out-of-proc components to is not the answer ADODB.Connection should not be out-of-proc.
Next Step
Fire up Regedit, find in Keys the key value of {00000514-0000-0010-8000-00AA006D2EA4} under
HKEY_CLASSES_ROOT
You should find an InprocServer32 key with a default value: C:\Program Files\Common Files\system\ado\msado15.dll
The ProgID should ADODB.Connection.2.8.
I had to use:
Regsvr32.exe "C:\Program Files\Common Files\system\ado\Msado15.dll"
in the command window to have the InProcServer32 key appear, thank you Anthony.
Everything is up and working now. My nightmares are over!