同一版本
可以实例化,但是有一个方法   save方法出错!

解决方案 »

  1.   

    权限问题in Windows Explorer, try to give IUSR_<MachineName> or IWAM_<MachineName> account Read/Execute permissions to your COM DLL, seehttp://www.aspemporium.com/aspEmporium/tutorials/permdenied.asp
      

  2.   

    Handling the "Permission Denied" Error
    Permission denied sucks. You've just written some cool app that needs to write to or read from the file system of the server. You've tested it on your development server and it runs like a champ. Then you put it on your production server and the Permission Denied error hits you like a ton of bricks... Throw the app away? Not for this problem... 
    If you are running your own server, there is a quick and easy way to deal with a permission denied error when trying to open or write to files using the FileSystemObject. This problem is solely related to your permissions and is easily fixable (I would say it takes less than 5 minutes to fix). 
    Here's a common scenario. You create some simple code to write a string to a log file: 
    <% @ Language = VBScript %>
    <%
    Option Explicit
    With Response
    .Buffer = true
    .Expires = 0
    .Clear
    End WithSub AppendToFile(ByVal file, ByVal towrite)
    Dim fso, ofile 'FAILURE HERE
    Set fso = CreateObject("Scripting.FileSystemObject") 'OR FAILURE HERE
    Set ofile = fso.OpenTextFile(file, 8, True) ofile.Write towrite
    ofile.Close Set ofile = Nothing
    Set fso = Nothing
    End SubAppendToFile Server.MapPath("/file.txt"), "my dog has fleas"
    %>It's so easy that it can't not work... But then you run it and you get a permission denied error. This issue is caused by one of two possible problems, and they're both easy to fix. If your code fails on the line where you are trying to create the filesystemobject, as in this line: 
    Set fso = Server.CreateObject("Scripting.FileSystemObject")then you need to adjust the permissions on the SCRRUN.DLL. Here's how you do it: Navigate to your WINNT\SYSTEM32 directory and find the SCRRUN.DLL. Right-click the file and select properties. Then click the security tab and ensure that the IUSR_<machinename> and IWAM_<machinename> accounts have "read" and "read & execute" permissions. That's it. 
    If your code fails when you attempt to open the file, you need to read on: 
    So let's examine the problem line (the line that causes permission denied) and see what's going on... 
    Set file = fso.OpenTextFile(file, 8, True)Basically this line calls the OpenTextFile method of the Scripting.FileSystemObject component. OpenTextFile has four arguments, three of which are optional. The first argument is file and represents the full path to the file to be read or written to. The second argument is the IOMode and can be 1, 2, or 8: read, write, or append respectively. The third argument is toCreate and is a boolean indicating whether or not to create the file specified in file. The fourth and final argument is format and can be -2, -1 or 0: system default, unicode or ASCII respectively. 
    Only the first three arguments are affected by permissions. Here's how it works. If the first argument, file, was d:\inetput\www\file.txt, the directory controlling the permissions will be d:\inetpub\www. The second argument, IOMode, represents the type of permission requirement that will need to be met to successfully use the file without error. The third argument, toCreate, will also be dependent on proper permissions to work correctly. 
    That's what is happening on the ASP end of things... The second part to this system is how Windows NT handles a website visitor internally. Unless your site is on an intranet, anyone on Earth can access it via the Internet (assuming you have an IP address, blah...). Since NT (or 2000 - they're the same) requires everyone to be logged in under a valid account name, IIS and Windows will automatically login any anonymous WWW user on your server under the Internet Guest Account. This guest account is the IUSR_<machinename> account and exists solely for anonymous users accessing your server. 
    Default IUSR_<machinename> account is attached to the Guests group and only has read, read & execute, and List folder contents permissions by default when added to a directory. That is your permission denied problem. 
    Here's how you fix. Open the directory specified in the file argument above. As an example I used d:\inetpub\www so that would be the directory I would need to adjust the permissions for. Right click on the directory and click properties and you see something similar to this: 
     The account you need to change permissions for is the IUSR_<machinename> account. If the IUSR_<machinename> account is not in the list of accounts with access to this directory, it needs to be so click the add button on the right and select IUSR_<machinename> from the list of available accounts on your server. 
    Once the account is added to that directory, select it. When you do, it probably looks like the above example. All you need to do is click the Modify button under the allow column. The write button will automatically be checked when you do this because write permission is needed to modify a file. Click the apply button and then click the advanced button. You will see a screen similar to this one: 
     All you need to do in the above screen is click the second checkbox at the bottom. That will reset all permissions in that directory and any of it's subdirectories, giving the IUSR_<machinename> modify access to those folders and files, solving the permission denied problem. However, if you want the ability to be able to delete folders and files with the FileSystemObject, you may still get a permission denied error. That can be fixed while in the advanced screen as well by selecting the Internet Guest Account and then clicking the view/edit button which will bring up the individual permissions for the IUSR_<machinename> account for this folder and it's subfolders and files: 
     To allow the FSO to delete files and folders inside the www base directory as well, just check the delete subfolders and files button and click okay. Now you can use the fileSystemObject without permission denied errors in your web directory and all of it's sub directories.