Unmanaged dll called by ASP.Net unable to create file under IIS6 - asp.net

I have an ASP.Net Framework 4 web application making an interop call to a 3rd party unmanaged dll written in C++.
The dll is stored in the bin directory of the web application and creates a file in another directory of the same web application.
The call works fine using Visual Studio 2010 (typically), but the individual process falls over when the call is made on IIS6.
The only logs of any problems is an entry in Event Viewer:
Application: w3wp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to stack overflow.
The Application Pool is running under the Network Service account, and this account has also been granted Modify access to the directory in question.

The 3rd Party confirmed that the problem was due to a problem in their memory allocation. The amount allocated on the stack not being sufficient.
The dll was suffering a stack overflow as a result and brought down w3wp.exe temporarily while IIS brought another process back up automatically.

Related

Update an ASP.NET Web Application by dropping the DLL on the web server

Is it possible to update the ASP.NET dll on IIS server in case of a multiple projects web application after I modified and rebuilt it?
I'd expect to follow this workflow:
There is a working ASP.NET application with multiple projects (web, data, utility, etc.)
I modify the web project in Visual Studio and rebuild it.
I replace its dll with the new one in IIS.
I restart IIS.
Would that work?
Yes, this Just Works™. What you want to do is a so-called "bin deploy". You just overwrite (after backing up of course) the (relevant files in the) bin directory of the web application, IIS detects this and restarts your application, so you can even skip step four.
That's all there is to it. So as long as you compile against the same assemblies already present on the web server, meaning you don't call methods or use types not present in the assemblies the server or cause other issues that prevent the DLL from being loaded or executed, you can just drop the newly compiled DLL into the web application and the site will run using your new code.

asp.net references a DLL that runs thread

I am new to ASP.NET and I need to develop an application that communicate with a RFID reader.
In order to do that, I have a DLL project which runs a thread that manages the communication with the reader, while a I have another ASP.NET project which manages the user interface.
Those two projects live in the same solution, so the ASP.NET project references DLL project.
At the beginning of the application, my "Global.asax" file initializes the reader (DLL project), running the thread it has inside, and registering some events such as "CardInside" the DLL fires, when a card is inside the reader.
My doubt is if this thread is really running because it does not do anything. I have placed more than one breakpoints in order to see if that part is being run, but nothing stops there.
I have read something about an issue regarding threads an asp.net, but since this thread is not used in a http request:
-is there any problem running a thread in ISS server at the same time as web page?
-Does an aspx.cs file register events fired by another object normally?As if it were not a web application?
-I am using visual studio 2015, could I use DEBUG object to show messages amongst my DLL lines of code?
Thanks a lot.
Yes, there are issues with running threads inside of IIS that are not requests. When no requests have come in IIS will tear down the AppDomain and that will Thread.Abort() the thread you are running your background work in.
You will need to move your code out of IIS and change it in to a actual windows service if you want it running all the time. You then can have your IIS portion talk to the windows service (or vice-versa) to process whatever the web component is.

Could an ASP.NET web application assembly be replaced during its run

I have an ASP.NET web application (Visual Stuido project type) in which everything is compiled into a single assembly, it is deployed in IIS. My question is if I have a new version of the assembly, is OK to replace it in IIS without bringing down the IIS? Or for a safe consideration, should I firstly shutdown the web server and then replace the assembly and restart? I am looking for a better solution to reduce server down time?
Yes. but it will cause an immediate Application Pool Recycling.
Quoting MSDN Blog:
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
We've reinstalled applications numerous times usnig the Visual Studio installer and it has replaced the assemblies with no problems. The only thing we find is that the first time we open the web page it takes a little while to open - possibly as it reads in the new assembly. We haven't had to to do an IIS reset or anything like that.
In addition on our dev environments (and because I am lazy) I often simply overwrite the assembly on the web server and that exhibits the same behaviour as above.
Taking down IIS is not an option for us, as we have many websites running on the same server.
I can't guarantee this is the best way to do it or that it won't cause problems, but it works for us.

Connecting to a COM interface in an aspx code-behind running on IIS?

I've created a Windows service (an exe based on the Visual Studio ATL wizard) which exposes a COM interface. No problems running as an in-proc server or a Windows service. I need a Windows service since I need some processes to be available outside of IIS access.
I've been creating some web pages (aspx/C#) calling my service and everything has worked fine testing within the Visual Studio .NET Development Server. Now, I'm trying to push the web pages to IIS 7 (running on windows 7) for further testing. But, when the pages are running under IIS the calls to my COM interface all fail with the error
"Retrieving the COM class factory for component failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))."
I've verified the service is:
registered with Windows under HKCR\Clsid\ (note, I registered running "myservice.exe /RegServer" since regsvr32.exe only works with dll's)
myservice.exe has read and execute rights for the IIS_IUSRS user
is a 64bit exe (so should load in the default IIS app-pool space)
Works great in .NET Developement Server debugger (but not IIS)
Any ideas why this would not work? Something to do with the COM interfaces contained in an exe vs dll?
Any possibilites of IIS calling a COM interface exposed in a Windows service?
I believe you need to grant access to your site's app pool process to use your COM object, under DCOM Config.
Go to the Component Services
> Computers > My Computer > DCOM Config branch
Locate the AppID or Name of your service in the list. Right-Click on it and select properties.
Open the Security tab
Pick Launch and Activation Permissions and select Customize.
Grant the app pool process (probably ASPNET, but check the IIS app pool properties for your site) the following: Local Launch and Local Activation.
Please let us know if this solves your problem.
Incidentally:
> is a 64bit exe (so should load in the default IIS app-pool space)
That's not quite true. The app pool is an ISS-controlled process. Your service runs on its own separate process no matter what. So your service has nothing to do with IIS app pools.
It looks very much like a security/permissions problem - so first make sure that whatever user the IIS worker is running under has sufficient rights and in particular check that your ASPNET group has permission to use COM (I think it doesn't by default).
EDIT - after posting that, I did find another post that might help - take a look here too
Thanks Guys. I really appreciate your responses. Your information pointed me in the right direction. The problem was indeed a security\permissions issue. To compound the problem, whenever I rebuilt my service, the rights I set for IIS_IUSRS was purged from the exe so some of the failures I was seeing was due to simple rights on the service.exe. So if you start seeing intermitent errors access your COM object during development then check the rights on your exe after re-builds! I hope that helps others.
For completion, here's how I resolved the issue:
changed the 'identity' of my services application pool to 'LocalSystem' (since my COM was in a Windows service running under the system account - most people will not require this level) (IIS Manager | Application Pools | right-click on your app pool | Advanced Settings | Identity

intermittent 'unable to start debugging on the web server...' in VS2012

There are a number of questions on stackoverflow relating to being 'unable to start debugging on the web server...' but I have variation of this problem: it's intermittent and it goes away if I restart VS2012. This would tend to indicate that some process or other is locking up another process, or a file is locked, etc, etc by devenv.exe (ie VS2012) and closing VS unlocks the file/process/whatever.
The Visual Studio solution contains a number of MVC4 websites that use IIS running on my 64-bit Windows 7 development computer. All the website, domain model and test projects in this VS solution are configured for .NET 4.5. MvcBuildViews is set to true in the CS project file.
I've tried recycling the IIS application pool for the start-up project, stopping and starting the IIS site, resetting IIS completely, to no avail. I have a suspicion the error message may actually be incorrect, but it's only a suspicion. Any ideas anyone?

Resources