I moved a site to another server, it worked fine for a a while, but then crashed. I figured out that System.Web.Extensions.dll was missing, so I copied it again. After a while it was missing again.
Using Process Monitor I figured out that IIS (w3wp.exe) deletes the file soon after I copy it to the bin folder. (CreateFile with "Read Attributes, Delete" access.)
What could cause this behaviour?
This is extremely difficult to diagnose without version or error information, but I can offer a few suggestions.
First of all, it is not recommended to put System.Web.Extensions in the bin folder. If the latest framework is installed, the ajax assemblies are included in the GAC and everything is configured to work properly. By dumping a dll in the bin folder, you are experimenting with version, dependency and trust issues which may cause your application to run slower, different or not at all.
Verify your .net framework installations to ensure the most recent version or service packs are installed on both the server and your development machine. Then double check which versions are actually being referenced by your web project and web.config. There has always been a version problem with ajax between development and deployment (expecially during beta cycles) but as far as why the IIS worker process deletes files in this scenario, you have me stumped.
Related
My question may have already been asked but any of the answers match my case.
I need to do a website (ASP.NET MVC 4) with some features of a software. I have finished to developed my website and wanted to test it in a test environment (Windows server 2008 - 64bits).
It works perfectly fine with my dev computer(windows 7 - 64bits). But after I deployed it on IIS, one of my features doesn't work.
This feature is a bit particular. It need a 32 bits COM written in VB6 (this dll can't be change) that call an other dll. When I test the website deployed on IIS, the first ddl is called fine but the 2nd seemed to be not called at all.
This dll are in the installed file of the software. I have the same version of on both computer.
I authorize my app pool to use 32bits application. I tried to give some access to my dll (the COM and interop) like IUSR, IIS_IUSRS. But nothing seems to work.
I have checked both of my dll are registered properly.
I'm a bit lost. Can someone help me ?
PS: Sorry for my English, I can speak but I'm really weak with syntax.
Some suggestion here:
You need to figure out which managed dll, native dll and lib files are referenced by your application (directly or indirectly).
For managed dll, make sure they are in the web's bin folder.
For native dll and .lib files, check out whether those .dll and .lib files are in the PATH. If not, you can either copy them to there; or, you can put them into a folder and add that folder into the PATH. Then restart VS and IIS (command "iisreset") to make sure the setting is picked up.
By the way, putting all of the files in the web's bin folder won't help. The reason is CLR copies the files into a temporary folder under framework directory and run the web there, but CLR only copies away managed dll (not the native ones), so you still get "module not found" error.
I have reproduced this error using the following sample solution
Web1 references a managed c++ project say "MCpp1.dll". The project further references two unmanaged c++ projects with the output say "Lib1.lib" and "Lib2.lib"
If I copy all of those files into web's bin folder, I get the exception of "module not found error".
I create a folder say "C:\Lib" and copy "Lib1.lib" and "Lib2.lib" into it and add this folder into PATH. I restart VS, and also run "IISReset" since I have a IIS web
Open VS and request a page and it works now
I have also contacted the CLR/Fusion team for suggestion of how to get the related module name when this exception happens, which should be very helpful to make diagnosis.
Hope this helps ,
GODFATHER
We have a problem. We are using IISExpress 8.0 for Asp.net WebForm application(.net 4.0).
Comupter is running under Windows 7 x64.
Sometimes without any reason ApplicationPool restarts. I know that it will restart after 15 aspx\ascx file changes. But in that case it restarts without any changes.
On ApplicationEnd we found a reason of this restart. It's ApplicationShutdownReason.BuildManagerChange.
Search in the Internet won't give anything usefull details. Mostly all recomends to use IIS instead of IISExpress.
Do you know what could be a reason for it?
UPDATE:
Digging deeper into .Net 4 source code give two reasons of this shutdown.
One of them is triggered when someone changed hash.web file from Temporary Asp.net folder. For example - "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\app\a83dcad1\be4aa699\hash\hash.web"
Second reason is when BuildManager built some object and cached BuildResult in HttpCache. And then if it's expired it checks that this BuildResult require ShutdownAppDomainOnChange on cache expiration. And if it's require it, then it triggers BuildManagerChange shutdown.
UPDATE2
In our case restart was caused by hash.web change. Seems IISExpress updates it without any source code change, but why?
UPDATE3
Microsoft has an issue about it - https://connect.microsoft.com/VisualStudio/feedback/details/783440/microsoft-visualstudio-web-host-exe-touches-hash-web-and-should-not-be-running
They say that they fixed it in Visual Studio 2012 Update 2.
This is not a full answer, so take whatever benefit from it you may take.
It seems like two things are happening: the hash.web change is probably because IIS uses the temporary location to store the application DLL that you build. When this file changes, IIS understands that you built a new version of the application, and need to restart it; that may explain the application pool reset.
For the cache expiration, it seems like IIS is trying to unload and reload something in a different app domain. There's no way (in .NET) to unload an assembly without unloading an app domain (I think) once it's been loaded, so this is "the usual" way to achieve this.
Maybe.
My ASP.NET webpage requires some data provided by a C++ .NET DLL. Everything seemed to work fine as far as loading this DLL and calling functions in it at first, but now my project seems to have gotten into a state where it does not actually debug if I reference the DLL in the .cs file.
I commented out all of the code that references the DLL and removed the reference from my project, and it worked fine. I added a reference to the DLL back in, and it worked fine. I uncommented only the using statement for the DLL's namespace (using MDnlnkCmdReader; in this case), leaving no actual code referencing the DLL, and now, when I hit debug, none of my breakpoints hit. Comment out that line again, and the breakpoint hits again.
When it gets into this state where the webpage appears to load correctly but none of the breakpoints hit, if I switch back to the source code and view the breakpoints, they show up as an outline with a caution flag, and if I mouseover them, then it says "The breakpoint will not currently be hit. The source code is different from the original version"
I looked up that error message too and tried the usual solutions to it. If I nuke the entire /bin folder, then I start getting webserver error messages about global.asax. These persist until I build in Any CPU mode (normally building in x64), at which point I get "unable to load" messages about the DLL (built in x64). When I delete the reference to it, then the page works again. Switch back to x64 mode and add the reference back in, and I'm right back where I started. Rebooting doesn't seem to help either.
Any ideas what's going on here, and how to get out of it?
Okay, I think I have this figured out now. What I have been dealing with is actually two different issues.
The first issue is that the ASP.NET development server seems to only be willing to grab its DLLs from the projects's /bin folder. Your project will build there if it is set to Any CPU, but if it is set to x86 or x64, then the default is to build in bin/x86/Debug or bin/x64/Debug. If you are set to x86 or x64 with the default build locations, then the development server will still try to grab DLLs from the root of the /bin folder.
If you have never built your project as Any CPU, or have cleaned out the /bin folder since the last time you have, then it will not find your DLLs at all, and the development server will display an error message like "Could not load type 'WebDownlink.Global'." about your Global.asax file (where WebDownlink is the namespace of your project). This means that it cannot load your namespace, which is because it cannot find your DLLs because it is only looking in the root of the /bin folder.
If you have built your project as Any CPU and then switched to building it in x86 or x64, then your new build will be in the appropriate subdirectory, but the development server will still grab the files from your last Any CPU build. The Visual Studio debugger will be using the files you just built, though, so if you have changed anything since your last Any CPU build, you will get the different source code error and debugging won't work right. If you haven't changed anything, then debugging will work, but the development server will still be running the Any CPU version, which may confuse the heck out of you if you are trying to do anything where bittedness matters.
The correct solution to this seems to be to configure your x86 mode to build in the root of the /bin folder rather than the /bin/x86/Debug folder. Or maybe don't reference any unmanaged DLLs in the first place.
This dovetails into the second issue, which is that the ASP.NET development server runs in 32-bit mode only, while the IIS application pool on a 64-bit system runs in 64-bit mode only (if you know of a way to change either of these, please let me know). If you need to link your code to an unmanaged DLL that can't be built as Any CPU, you will have to account for this. That's why I only reference x86 above - there's no point in changing where your x64 builds because the development server won't run it anyway.
Luckily, I have the source for the DLL that my code references, and it doesn't reference anything else, so I can easily built it in both 32- and 64-bit mode to run it on both the development server and the full IIS. If you are referencing a 32-bit DLL that you can't rebuild, then you will either have to deploy on a 32-bit machine or figure out some way to get the IIS application pool to run in 32 bit, which I couldn't. If your DLL is 64-bit and can't be rebuilt, then you'll just have to do all of your debugging of code related to it on the full IIS.
So my solution is to build my DLL in 32 bit, reset the reference, and then build in 32 bit mode, with the output path set to /bin. When I want to deploy, I rebuild the DLL in 64 bit, reset the reference, build the project in 64 bit, and then deploy to IIS.
Open up the "Modules" window while you are debugging and take a look at the "Path" column - does the path given for you assembly match an assembly which you know matches the source code?
ASP.NET normally puts copies of assemblies in the "Temporary ASP.NET Files" folder and so it may well be that you need to clear this out too.
Note that you can also untick the "Require source files to exactly match the original version" which will allow you to debug as long as the source code isn't that far out. However, it's probably a better idea that you fix the underlying problem (the assemblies don't match the source) instead.
The situation is I made a minor bug fix to a class, so they want to just deploy the dll affected. They stopped IIS, replaced the dll in the /bin folder of the iis directory for the web site with the new one I gave them, and started iis again. There are multiple servers, but they just changed it on one to try it out. They are still seeing the same error in the eventlog of the server in question. Looking at the stack trace I can tell it is running the old dll.
They've checked the GAC and don't see it there.
I've checked the dll with reflector to verify I gave them the correct new dll.
This is an asp.net 2.0 website and the server is 2003. I'm not sure how it was deployed originally but it has a copy of the old dll in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\NAME_services#################\assembly\dl3###################\ and in D:\xxxx\Sites\NAME\Services\obj\Release. Could it be using one of these or building the old one or even just caching it in memory?
Nuke your temporary asp.net folder contents. Not sure why the update didn't automatically get compiled, though.
We had same problem but with minor complications, we have many many sites so a "clearing all temp" and restart IIS is not a good option for us. So we needed to be more selective in what to force a refresh on.
On our QA machine, under ... "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files"
I did a file explorer search for the partial file name of what we are trying to release. The file was found in a folder something like:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\4503212x\ad95664x, so I stopped app pool, deleted the folder, restarted and all was deployed then - great!
But .... We had same trouble deploying to production and the above did not work.
Long story short, the QA app pool was set to "enable 32 bit true", but production was set to "False" so the prod temp files resided in:
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" instead (\Framework64\ instead of \Framework\ ).
If clearing temp files is not working - double check your frameworks, or look for files to refresh at the C:\Windows\Microsoft.NET folder level and below. you may be surprised.
You don't have to stop IIS to deploy your update, you just copy them over.
Also, if they copied only the DLL but your fix was in the .aspx file, then it won't show up. You should really do a full deployment.
We copied the project source code to a new folder and reopened the solution. This somehow tricked Visual Studio into not using the cached version of the DLL. Wish we knew why this worked, but that resolved it for us.
Ok, maybe I'm skipping a step here, but I swear I had Eqatec profiling things just fine in ASP.NET 2.0.
We upgraded our solution to ASP.NET 4, it works fine. Then I went through the typical steps:
Built the solution in VS 2010
Ran Eqatec and pointed it at the apps bin folder
pick my 3 DLLs
Click build, I have the output dir set to $(AppData) so it just adds the files to apps bin dir
ran webdev.webserver40.exe with the port and the path
navigate firefox to the website on my local machine
But now it's throwing weird errors saying that things in the machine level web.config can't be found. I dropped a copy of the web.config into the bin directory, and then it just complains about some of the tags in that file.
Is there an extra step I need to take here to make this work?
EDIT: A guy suggested that it may be a 64-bit issue. We run our app in 64 but, Equatec runs in 32 bit. Could that be a factor?
Ok, turns out I'm just an idiot. When you fire up cassini via the WebDev exe, you're not supposed to point it at the bin folder. You point it at the project folder itself, the root of the web app. I guess this had noting to do with eqatec after all.
#Richard Flamsholt thanks for the help anyway!