If you can, try to test it on Windows Server 2003 and set the app pool identity for the application to SYSTEM (not the default NETWORK SERVICE). If this works (you can do this on W2K as well using the processModel section in the machine.config file) you're sure it's a rights-problem. However, there are plenty of other things to be checked first. If it's a non-.NET component, you should register it first (remember the COM DLL hell? ;-) ) so ASP.NET can find it. If it's a security problem, it's unlikely that the problem is an ACL (all right, the ASP.NET process needs to have read-rights at least to locate the dll). Rather, the problem will be the .NET Framework Security configuration on the server that does not allow the unprivileged account (as ASPNET is one) to load this particular component.
But first things first. Try to find out whether it has to do with the ASP.NET application pool (W2K3) or worker process (W2K) identity the way I described before. If this works, don't leavy the SYSTEM account there but start to find a way to get it to work with the limited account the ASP.NET is using in order to get security right.
Bart De Smet [MVP]
Visit
www.msdn.be,
www.bartdesmet.net