none
Interop.Shell32 RRS feed

  • Question

  • Hi,

    I am tring to use Shell32.ShellClass to get the shortcut file's target.
    Firstly, I was using a local shortcut file saved in C drive as a test, it worked fine both in the developement mode and published mode.
    Then I replace the local shortcut file with another one saved in somewhere in the network, it still worked fine in developement, but when I published it, It stopped working.
    I found that the code line
    shell.NameSpace(pathOnly) returned null value on published mode.
    Thanks a million first for any help from you.


    protected
    void Page_Load(object sender, EventArgs e)

    {

    string shortCut = @"\\****\****\****\Shortcut to DRL 01.32.01 LBH Annual Report 2008-pt1.pdf.lnk";

    Response.Write(GetShortTarget(shortCut));

    }

    private string GetShortTarget(string shortCut)

    {

    string pathOnly = System.IO.Path.GetDirectoryName(shortCut);

    string fileNameOnly = System.IO.Path.GetFileName(shortCut);

    Shell32.Shell shell = new Shell32.ShellClass();

    Shell32.Folder folder = shell.NameSpace(pathOnly);

     

    Shell32.FolderItem folderItem = folder.ParseName(fileNameOnly);

    if (folderItem != null)

    {

    Shell32.ShellLinkObject link = (Shell32.ShellLinkObject)folderItem.GetLink;

    return link.Path;

    }

    return "";

    }

    Wednesday, November 19, 2008 10:36 AM

Answers

  • If you run application from VS while it's on filesystem (not IIS), than a very simple server gets created while running "inside" of VS. That's not IIS nor behaves like a real server and it's behaviour is very stupid - don't use that never ever, or you get surprised more often that you could imagine. Always host inside IIS.

    You should put a question into IIS discussion how to access unmanaged dll from inside of IIS process.
    Process inside IIS has a custom application domain with strong restrictions (as nobugz wrote).
    It might be possible to do what you want using e.g. signed libraries or by setting extra permissions.
    However, this is far beyond my knowledge.

    However, allowing IIS process to access local disc sources is not such a deal, you might avoid using Shell32 by calling managed libraries, only, and maybe writing a few pieces of custom code.

    Tomas

     

    • Marked as answer by Zhi-Xin Ye Monday, November 24, 2008 12:11 PM
    Wednesday, November 19, 2008 3:10 PM

All replies

  • The diagnostic here is simply that "shortCut" is a path to a non-existing file.  Tinkering with shell shortcuts in an ASP.NET program is *very* unusual, I hope you're not expecting to be able to modify shortcuts on the desktop of the machine running the browser.  You can't.
    Hans Passant.
    Wednesday, November 19, 2008 11:25 AM
    Moderator
  •  thanks for your reply, but after my double checking, the target file certainly exists, I just used the stars to represent the actual path. 

    As I said, it worked fine in developement, only stopped working when published.
    Also I am not modifying anything.

    As it worked both in development and published for local shortcut files, I am thinking it maybe that the shell32.dll need some permission to access the remote shortcut file, but not sure what it is.

    Wednesday, November 19, 2008 11:31 AM
  • The next diagnostic is that the account under which IIS runs simply doesn't have access to the target file.  It is normally a very restricted account to avoid giving attackers an easy way into a machine.  Ask about IIS accounts at forums.iis.net
    Hans Passant.
    Wednesday, November 19, 2008 11:48 AM
    Moderator
  • But the application has been impersonated to an acount that have access to the file.
    The "pathOnly" prameter does return the correct value, only the "shell.NameSpace(pathOnly)" returns null value.
    Wednesday, November 19, 2008 11:54 AM
  • Path.GetDirectoryName() doesn't tell you anything.  It is a simple string manipulation function, it doesn't actually do anything with the file system.
    Hans Passant.
    Wednesday, November 19, 2008 12:01 PM
    Moderator
  • What about the FileStream ? the following code, which is part of the same application too, does return the correct bytes for the target file. the problem only exists with the shortcut file.

    FileStream fs = new FileStream(filePath, FileMode.Open);

    byte
    [] byteArray = new byte[(int)fs.Length];

    fs.Read(byteArray, 0, (int)byteArray.Length);

    return byteArray;

    Wednesday, November 19, 2008 12:10 PM
  • Hi,

    the problem really seems to be about IIS process rights rather than API calls.
    You've got a shared folder path in your shortcut (starts by //), which also shows on possible rights problem.

    You should
    1) check out if your testing environment has the same settings as production (ASP.NET account might be set as administrator for testing purposes)
    2) check out if your production environment hasn't got a brand different policy settings (e.g. intranet group policies must be taken into account to access shared folders)
    3) as a dirty (and dangerous) trick you might try to set your production ASP.NET account into administrators for a minute - if the code works, you should consult your administrator about proper policies

    Hope this helps,
    Tomas

    Wednesday, November 19, 2008 12:20 PM
  •  Thanks Tomas, I tried your third trick, still not working. as the same application can retrieve the files, folder structures, can check permission for every folder/file, also in the same application I have used the DSOFile.dll to retrieve file summaries, titles, authors, etc.
    So I really think it's still the API permission problem.
    Wednesday, November 19, 2008 12:34 PM
  • also, I published the application to the local machine, it's not working too.
    i don't know what the eviroment has changed when published to the same machine.
    Wednesday, November 19, 2008 12:50 PM
  • It all depends on what means that "it worked in development".

    If you have the testing version deployed into IIS and debugging it, you definitely have switched Windows Integrated Authentication on (otherwise you couldn't debug IIS processes). Using Integrated Authentication the process automatically receives your user rights regardless impersonation in config file.

    Simply try to switch Integration Authentication off and run the application on your local computer.

    Tomas

     

    Wednesday, November 19, 2008 1:08 PM
  • Thanks Tomas,

    Here is the situation:
    it works when I open the project from file system,
    it doesn't work when I open it through local IIS;
    not sure whats the difference between them though

    William

    Wednesday, November 19, 2008 2:41 PM
  • Tomas,

    however it starts making sense to me now. thanks very much for your help, and nobugz.
    It seems the second situation you mentioned above.
    but I still don't know how to configure the intranet policies to enable this, as I mentioned before, the same production application can retrieve the files, folder structures, can check permission for every folder/file, also in the same application I have used the DSOFile.dll to retrieve file summaries, titles, authors, etc. It seems only have problems with shell32.dll.

    William

    Wednesday, November 19, 2008 2:49 PM
  • If you run application from VS while it's on filesystem (not IIS), than a very simple server gets created while running "inside" of VS. That's not IIS nor behaves like a real server and it's behaviour is very stupid - don't use that never ever, or you get surprised more often that you could imagine. Always host inside IIS.

    You should put a question into IIS discussion how to access unmanaged dll from inside of IIS process.
    Process inside IIS has a custom application domain with strong restrictions (as nobugz wrote).
    It might be possible to do what you want using e.g. signed libraries or by setting extra permissions.
    However, this is far beyond my knowledge.

    However, allowing IIS process to access local disc sources is not such a deal, you might avoid using Shell32 by calling managed libraries, only, and maybe writing a few pieces of custom code.

    Tomas

     

    • Marked as answer by Zhi-Xin Ye Monday, November 24, 2008 12:11 PM
    Wednesday, November 19, 2008 3:10 PM