Problem publishing to IIS 7.5

Jul 3, 2012 at 9:12 PM

Forgive me if this has been answered before, but I am somewhat new to Silverlight.  I am using Silverlight 4, and .Net 4.0, with your HSS_Interlink_v2.2.100.  I have completed your QuickStart while running in debug mode in VS2010 and everything works fine.

My next step was to publish this code to IIS 7.5 on my machine to test in deployed mode.  I followed the documentation which said to add a handler to the <system.webServer> part of the Web.config file as follows:

<handlers>
      <add name="FileUpload" verb="GET,POST" path="FileUpload.ashx" type="HSS.Interlink.Web.FileUpload, HSS.Interlink.Web"/>
    </handlers>

I have rebuilt and published to IIS, but when I hit the website I am getting the following error:

HTTP Error 500.23 - Internal Server Error
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

The documentation listed some more code such as the class UploadHandler, but it was not clear whether I had to add this code to my Quick Start code or not.

Thanks for your help,

Abby

Coordinator
Jul 3, 2012 at 9:20 PM

From it sounds like you just need to comment out the system.web.httphandler section of your production web config. IIS doesn't like it when you have both system.webserver.handlers and system.web.httphandlers.

Thanks for trying Interlink, and let us know if you need any help...

Jul 3, 2012 at 9:59 PM
Edited Jul 3, 2012 at 10:00 PM

Thanks that did fix the 500 error I was getting.  I can now select a file for upload, but when I do, I am getting "Upload completed with errors or some files were canceled".  I suspect that I may still have a problem with the Web.config.  Just as in the QuickStart my handler is called "UploadHandler.cs", so I have replaced the corresponding entries in the web.config, but may still have something wrong.  Below are the contents of my web.config file.

 

<?xml version="1.0"?>

<configuration>
  <appSettings>
    <!-- This value must match the Full TypeName including the namespace of your UploadHandler -->
    <add key="UploadHandler" value="SLFileUploadTest.Web.UploadHandler, SLFileUploadTest.Web"/>
  </appSettings>
 
    <system.web>
      <compilation debug="true" targetFramework="4.0" />
    </system.web>

  <system.webServer>
    <defaultDocument>
      <files>
        <add value="Go.aspx" />
      </files>
    </defaultDocument>
    <handlers>
      <add name="UploadHandler" verb="GET,POST" path="FileUpload.ashx" type="SLFileUploadTest.Web.UploadHandler, SLFileUploadTest.Web"/>
    </handlers>
  </system.webServer>
 
</configuration> Thanks so much for your help,
Abby
Jul 3, 2012 at 10:06 PM

By the way, a bit more information concerning the problem I have described previously.

In the UploadHandler class, I still have the FileStoreFolder = @"Interlink\Uploads"

And I have created the folder Interlink\Uploads in my web folder in IIS and have opened up the permissions to include NETWORK SERVICE.

Hope this helps diagnose the problem.

Thanks,

Abby

Coordinator
Jul 4, 2012 at 1:23 AM

1. Interlink will auto create the folder for you assuming it has write permissions

2. Is the site in IIS, a Root site or a SubSite?

 If it's a sub site you'll need to update your web config handlers Path to match your site url

http://somesite.com/filehandler.ashx versus http://somesite.com/yourapp/filehandler.ashx

path="FileUpload.ashx" versus path="yourapp/FileUpload.ashx"

Plus, on the client you'll need to set the url: UploadClientInstance.UploadUri = "filehandler.ashx" or http://somesite.com/yourapp/filehandler.ashx
The default is "/filehandler.ashx" which assumes your site in IIS is a root application.

 

Jul 5, 2012 at 4:18 PM
Edited Jul 5, 2012 at 4:19 PM

Thanks for the reply.

If Interlink will auto create the folder, does it have to be within the "inetpub\wwwroot" location or can it be anywhere on the drive?  For example, "C:\uploads"

Yes, I am trying to get this running within IIS ver 7.x.  And it is a subsite, the full path is:  C:\inetpub\wwwroot\SLFileUploadTest

As you can see from my Web.config below I did make the change to the Web.config that includes the path of the subsite.  In my UploadHandler, I am trying to upload to a directory within my website such as:  C:\inetpub\wwwroot\SLFileUploadTest\Interlink\Uploads

Here is the corresponding line in my UploadHandler:  public static string FileStoreFolder = @"Interlink\Uploads";

Other than that everything is just as stated in the QuickStart.

Thanks for your help,

Abby

 

<?xml version="1.0"?>

<configuration>
  <appSettings>
    <!-- This value must match the Full TypeName including the namespace of your UploadHandler -->
    <add key="UploadHandler" value="SLFileUploadTest.Web.UploadHandler, SLFileUploadTest.Web"/>
  </appSettings>
 
    <system.web>
      <compilation debug="true" targetFramework="4.0" />
    </system.web>

  <system.webServer>
    <defaultDocument>
      <files>
        <add value="Go.aspx" />
      </files>
    </defaultDocument>
    <handlers>
      <add name="UploadHandler" verb="GET,POST" path="SLFileUploadTest/FileUpload.ashx"
type="SLFileUploadTest.Web.UploadHandler, SLFileUploadTest.Web"/>
    </handlers>
  </system.webServer>
 
</configuration>
Coordinator
Jul 5, 2012 at 7:22 PM

Assuming the URL of your application is http://somesite.com/slfileuploadtest/page.html

You have to do two things...

1. Update your config file to be "/slfileuploadtest/fileupload.ashx"
2. On the client, set the UploadUri property to "filehandler.ashx" or http://domain.com/slfileuploadtest/filehandler.ashx (the latter is for OOB)

IIS Web Configs can be a pain sometime. Be sure and use the backslashes properly. That is usually what hangs people up.

A URI of "/" is the relative base so "/filehandler.ashx" is essentially saying "base/FileHandler.ashx" where base is your app which is root/app, and so if you do "appname/filehandler.ashx" it gets turned into "base/appname/filehandler.ashx" and since base is already root/app it turns into "/appname/appname/fileupload.ashx". so you have to be sure and include the first "/" so "/appname/fileupload.ashx" turns into "/base/fileupload.ashx" where base equals root/appname which then finally resolves to "root/appname/filehandler.ashx".

This is all an IIS and System.Uri mapping challenge, has nothing to do with Interlink in and of itself. The issues are to do with HttpHandler mapping. The only nuance that is Interlink related is the Auto URL Resolution on the client. On the client the default UploadUri is "/fileupload.ashx" which assumes the handler has been mapped to "root/filehandler.ashx". So when you run your app as a sub site, the full url of your SL App is http://somesite.com/appname/slapp.html so when it tries to auto resolve the server side url "/fileupload.ashx" becomes http://somesite.com/fileupload.ashx, so for sub sites, you have to drop the first backslash so "fileupload.ashx" on the client will resolve to http://somesite.com/appname/fileupload.ashx

Hope this helps explain mapping and uri resolution and didn't make it more confusing.

 

Coordinator
Jul 5, 2012 at 7:24 PM

As far as auto directory creation, Interlink will auto create folders relative to your app folder. If you want to store the uploads files somewhere else, you just need to modify your file handler to not use the default "this.GetFolder" method, and instead use your own.

Jul 9, 2012 at 10:49 PM

Thanks, your explanation was great.  I got it working.

One quick question though.  It works fine for text and image files, but does not like zip files.  They end up with 0 bytes.  Is there something special needed to upload zip files?

Thanks,

Abby

Coordinator
Jul 9, 2012 at 11:04 PM
Edited Jul 9, 2012 at 11:05 PM
No, they should work like any other file.
Jul 22, 2012 at 7:58 PM
Edited Jul 22, 2012 at 8:58 PM

Regarding URLs, I've found out that Uri's constructor, when combining a Uri with another part), eats up the last part of the first Uri if it doesn't end with "/", that is if you combine http://test.com/a with b.doc you get http://test.com/b.doc instead of http://test.com/a/b.doc that one might expect having used the Path.Combine (if hope I do remember well how that one behaves). So you have to make sure the first part of the path you combine has / at the end (e.g. http://test.com/a/ in this case)

Personally I feel this is a bug at Uri class (since it breaks the least surprise principle [for developers with desktop experience at least]), but it may have been made so to follow some W3C suggestions or Javascript standard behaviour or whatever

see example at http://zoomicon.wordpress.com/2012/07/22/gotcha-silverlights-uri-class-constructor-eats-up-part-after-last-slash/