4

We are working on migrating an older ASP.Net application to the cloud and for that we did several things also updated the application to use a newer .net framework.

Now we face a strange problem, in the application a link is created from data in the database. The html:

 <asp:HyperLink ID="linkProjectFolder" CssClass="imageLink" runat="server" ToolTip="Open de folder in de Windows Explorer">
     <asp:Image ID="Image1" runat="server" ImageUrl="~/pages/img/openHS.png" />
 </asp:HyperLink>

The code behind:

string url = string.Concat(((TextBox)viewINFO.FindControl("txtProjectmapBasePath")).Text, ((TextBox)viewINFO.FindControl("txtProjectmapPath")).Text);
HyperLink hl = (HyperLink)viewINFO.FindControl("linkProjectFolder");
if (hl != null)
{
   hl.NavigateUrl = Uri.EscapeUriString(@"file:///" + url);
}

Nothing special and this code has not changed between the old version and the new version. I know that this code does not work in firefox and chrome, but the old version does work in IE11.

Now from the enduser the old version in IE just works, if you click the link a windows explorer window is opened to the file path. For the same end user, from the same workstation with the same browser the new version does not work. When you click the link nothing happens.

Now the strange part, on my development machine, I simulate a network drive by mapping a folder to a drive letter (susbst N: c:\temp\Ndrive) when I try the link I see the same behavior as the end user, just nothing happens. Now if I unmap the drive, start the application and click the link, the link opens in the browser and I get a "page cannot be displayed". If I remap the drive at that moment, go back in the browser and retry the link it works.....

There are of course differences, the .net framework, IIS vs IISExpress vs IIS on azure, but as it is just a simple href I would say it must be client side. Also that the code sometimes works suggests that the urlencoding at least is correct (it does exactly the same as in the old version for the tested url's)

In the database the links are a path to a mapped drive so something like "N:\folder\folder 2\folder & folder\", that is correctly urlencoded and that only works half the time as described above. If I use a link to my C drive "C:\Temp" it never works, if I use "127.0.0.1/C$/Temp/" as link it always works but changing all the links in the database to use an IP address is not really the way we want to go.

After eliminating all the things above I have no clue on what could cause this behavior. Can anybody point me in the right direction ?

KeesDijk
  • 2,299
  • 1
  • 24
  • 37
  • My guess is the newer version of .NET is generating different control names in the HTML. This means the variable url is coming back with a blank value. There is a web.config setting to use old control names: – Robert Paulsen 2 mins ago edit – Robert Paulsen Apr 03 '18 at 19:45
  • My second guess is that the HTML is being rendered differently by the browser based on the HTML being generated by .NET -- doing something like adding may help. – Robert Paulsen Apr 03 '18 at 19:45
  • have you looked at the resulting markup in the different environments (namely: 'href:' property ). what are th edifferences if any between the one that works and the one that doersn't? – DaniDev Apr 03 '18 at 21:45
  • From what I understand, you are trying to access local file on client system from IE11. For this, your site needs to be a trusted site on the browser. file:// URLs are not enabled by default. – danish Apr 04 '18 at 05:45
  • @RobertPaulsen, thanks for the comment. output is the same on different environments if you just look at the HTML. – KeesDijk Apr 04 '18 at 09:13
  • @DaniDev, thanks for the comment, markup is the same. – KeesDijk Apr 04 '18 at 09:13
  • @danish, thanks, yes that is correct and both the new and the old version are added to the trusted sites, there is a bit of strange behavior here depending on the order of things it now sometimes works and sometimes it doesn't. – KeesDijk Apr 04 '18 at 09:16
  • @KeesDijk are you referring to order of sites in the list? Also make sure all URL variations are covered in the list – danish Apr 04 '18 at 10:05
  • Another thing the check would the file path itself. For local system, there should be 3 / after file and then the drive. For network paths, you will need 5 of them. There might also be some limitation at the network level which might be blocking files from opening. Take a look at browser console or event viewer. – danish Apr 04 '18 at 10:11
  • @danish, thanks for you input. I mean the order in which things happen, like changing if the site is trusted and or changing the existence of the path. We always have three / after file, but since that sometimes works, I don't expect that to be the problem. Browser console or event viewer don't show anything, just nothing happens :( – KeesDijk Apr 04 '18 at 13:36
  • @KeesDijk there are some registry entries too that you might need to take a look at. If you haven't yet, try checking with network admins if they can help. I don't think I can help apart from speculating. This has almost nothing to do with application code since the process is completely happening on the client computer. And I don't know how the set up is. – danish Apr 05 '18 at 03:20

1 Answers1

3

Consider revising the asp:HyperLink tag with a nested asp:Image tag with one of these two (2) options:

1) Use an asp:HyperLink tag with ImageUrl property and remove the nested image tag. See this Microsoft Hyperlink.ImageUrl Property page for more information.

2) Use an asp:ImageButton tag with the ImageUrl property. See this SO question titled: how to link imagebutton to url visual developer for more information.

If none of these options resolves your problem, then you may have a file resource access issue rather than an ASP.NET syntax issue.

JohnH
  • 1,920
  • 4
  • 25
  • 32
  • Thank you for your answer, sorry it took me some time to verify. But this didn't help, there are slight differences in the behavior but the end result is the same. And yes it probably is some kind of file resource access problem. – KeesDijk Mar 30 '18 at 09:50