I have an ASP.NET MVC web application which integrates a C# managed library of ours that loads unmanaged plugins to do some file processing. These unmanaged plugins in-turn rely on a few 3rd party libraries to do their dirty work; some of which are causing IIS to crash.
We use the exact same library in a desktop application which is able to process the files just fine. The files also process just fine when running under the Cassini web server that comes with Visual Studio 2008 (IIS and Cassini are running off the same folder on my local box).
I've done a Crash Analysis with Debug Diagnostic (img) which I'm not able to extract any useful information from.
I used procexp a bit to see if there where any failed file or registry access attempts that might be causing an issue but came up short. I didn't see any but could have easily missed them considering the number of lines produced in that kind of logging.
I configured the application pool to use a domain account and made that account an Admin on my box thinking it might be a permission issue but no luck. Are there other access restrictions in IIS that I'm not aware of?
Suggestions? Articles? Tools? Voodoo?
EDIT: I was able to debug this down to the 3rd party library's initialization routine. Since the library works fine running under other hosts I suspected either a permissions issue or memory issue. It turned out to be a stack size limitation when running under IIS. See Stack sizes in IIS - affects ASP.NET
Sounds like you should try and enable 32-bit applications in the application pool. Interop doesn't play nicely with binaries compiled for 32-bit if you're running 64-bit.
Related
I wanted to publish the my mvc5 application on IIS server and gone through with some references and finally I was able publish the project (through file system) from visual studio 2017.. After all my efforts I'm able to see the below screen when I browse the URL.
But it is not I expected, my actual running application in localhost is shown below.
I want to run the my actual project in IIS URL. What I can do to achieve this.
EDIT:
For more info..
Initially I got the issue which is shown in below image. For this fix, I've enabled the Directory Browsing in IIS server for my application. After enabling I face the above mentioned issue (shown in first image).
Any kind of suggestions are more helpful.
#Lex Li as you mentioned, the issue is caused the wrong CLR related settings for the application. And its my bad, I had used DefaultAppPool. Fixed the issue by giving the application pool as .Net v4.5. And also turned on the .Net extensibility 4.7 feature (in control panel -> programs and features -> Turn windows features on or off) as shown in below.
Now the application is running as expected in IIS server.
Thank you for all your comments which helped me to dig more into this. :)
I have Visutal Studio 2012, MVC 4 & Razor. I am having trouble getting a website up and running with this technology.
The Web Server is a Windows Server 2008 server. I tried deploying using the Web Deploy method but am consistently getting something like 'set ACL" error.
I tried deploying using the File System. All files got deployed, but when I try and run the website, it fails because of missing ASP.NET MVC infrastruccture files.
Two things:
•If I use Web-Deploy, how do I solve the ACL error, because I assume with this method, everything needed will get deployed.
Note that the Web Deploy 3.0 service is on the server and started.
•If I use File System, where can I find the downloads needed to deploy on the server where MVC WILL work.
◦Note that I downloaded the 4.5 Framework and was successfully installed.
You need to be a bit more precise with what you need help with.
What's the exact error.
Often times you need to give the IIS users group access to at least read from the directory where you've deployed. Did you do this already?
Do you have .NET 4.5 and MVC4 installed on the server? If not, are you expecting those DLLs to be "packaged" with your deployment? They generally are not since they are "standard" assemblies. But if you want them to be included in your deployment you can do that by selecting the references in VS and saying "copy." This is not recommended because when you install patches to .NET and MVC on the server, those updates will not carry through to your app, since it'll use the local (old) copies of your assemblies.
This may be more of an IIS issue, but not sure based on the details in your question.
Check that the application pool that the site is running under is using .net 4.0.
Just a thought I would check.
ASP.NET MVC, Visual Studio 2010, C#/.NET4. I'm using IIS Express as the web server of choice, as it more accurately mirrors our production configurations in IIS7. However, when I go through following process, the libraries used by IIS Express don't seem to be updating.
Run app, find bug
Stop VS2010, fix bug
Build/Run
Testing reveals the new code is not being used
IIS Express continues to run even after stopping the debugger in VS2010, so I'm assuming it's just holding onto the binaries that were used when it was initially launched. Is there a way to get it to use the updated binaries? Or is this the expected behavior? Right now, the only way I can get the new binaries used is to completely exit VS2010 and then reload the project/solution. Even selecting "stop" from the IISExpress systray icon doesn't seem to actually help (it doesn't appear to actually stop the process).
Obviously closing VS2010 and reloading the solution each time is a less-than-ideal workflow.
EDIT: The project is configured to run IIS Express from right click project -> Web. The project URL does not use any virtual directories, it is at root of the local host on port 60830. I thought I remembered seeing IIS Express in the F4 properties listing before, it's not listed there at all right now.
I am currently building an ASP MVC 2 site and I am looking at hooking ELMAH in for my error logging however I'm not sure how to handle the different build environments.
Both my development machine and current test server are 32-Bit and the production server is 64-bit. I can set the MVC site to deploy in x86 and x64 without any problems but is there any way I can get it to use the 32bit and 64bit ELMAH binaries on their respective servers without needing to change the referenced DLL between builds?
The difference between the two editions is due to SQLite since it uses unmanaged code. If you are not using the SQLite provider, it doesn't matter and you can use the same version in both environments. If you are using SQLite then I am not sure how to do this, but I gather most people will use SQL Server in production so won't really run into this issue.
Hope that helps.
I had the same problem, and not using SQLite was not enough to make it work. I tried removing all configuration for SQLite.
I noticed that the SQLite dll was published with my project, so i removed it from the folder containing the Elmah dll. Now my application works in both 32-bit and 64-bit.
I developed a Windows service which is running without any problem in Windows XP service pack 3. When I deployed this service in Windows Server 2008 it is not working. The service started without any problem.
I enabled the option Windows XP service pack 2 from the compatibility property of the .exe which deployed there.
But no more action after the starting the service.
What could be the problem?
One thing I would check it to see if any of your referenced assemblies are 32bit specific. We ran into a similar problem when using Microsoft SQL Server Reporting Services. The .dll we used to get a list of the web service interfaces, was 32bit/64bit specific, so we had to swap it out depending on which envionment we were running on.
Since the error could hide anywhere I would suggest to first discern what exactly is not working under Windows Server 2008.
Implement some logging functionality into your service (if you didn't do so already, I strongly recommend it) and let the result be printed into a log file. See what's working and when it stops to work. Hopefully this will give you a better understanding of what's going on under the hood.
Also, this way we can help you way better than now.
[EDIT]
Maybe these two can help you?
COM Class Factory Error
Running 32 bit app using 32 bit com on a 64 bit Windows machine