Showing posts with label filename. Show all posts
Showing posts with label filename. Show all posts

Thursday, March 31, 2011

Issues When Migrating to IIS7: Default Documents and Images

I recently migrated all of my company's websites to a new server, upgrading from IIS6 to IIS7 in the process. There were several hurdles we had to jump in making the version change and I thought it may help others to learn from our experiences.

Default Documents can not include Query Strings


IIS7 Default Documents

The Issue


On our older server, we had many domains feeding into the same web application, yet each domain would set certain variables through the query strings of the default document of the site.

For instance, a domain "myExample.com" a default page "DefaultPage.aspx?e=29" would set all the variables necessary for portal #29.

With IIS7, we no longer have this luxury, and must only feed in a single filename, i.e. "DefaultPage.aspx"

Issues for Multiple Websites with the Same Home Directory


One of my first thoughts was, ugh, am I really going to have to create a seperate landing page for EVERY domain linking into the site? As you'll read in the work-around, no. That's not the best way to do it. And as it turns out, it's not even possible. For every Home Directory you route to in IIS7, you have to use the same landing page for all websites pointing to that folder. So, if I have myExampleA.com and myExampleB.com both pointing to c:\inetpub\wwwroot\myExamples\ and I define myExampleA.com's default document to be WelcomeToA.aspx, then myExampleB.com will inherit the same default document. They have to be the same. Another big change for default documents when migrating from IIS6 to IIS7.


The Solution


I've noted several people using URL Rewrites to solve this, but with an application as large as ours, it would take days to test everything to ensure implementing an application wide URL Rewrite wouldn't cause any problems elsewhere.

But, since every domain sets a different set of variables, I was able to find a simple solution.

I feed every domain into the same default document, i.e. RerouterPage.aspx that then looks at the domain of the request, compares it to my database to determine the portal ID (the ?e=##) of the request and then set all the variables accordingly. Afterwards it redirects the user to the correct landing page.

Here's a little sample of what my code looked like for the RerouterPage.aspx
Public Sub Form_Load() Handles Me.Load

If Session("portal") Is Nothing Then

If Request("e") = "" Then

Session("portal") = PullPortalBasedOnDomain()

Else

If IsNumeric(Request("e")) Then

Session("portal") = New Portal(Request("e"))

Else

Response.Redirect("~/NoPortal.aspx")

End If

End If

End If

If CType(Session("portal"), Portal).PortalID = 0 Then

Response.Redirect("~/NoPortal.aspx")

End If



Response.Redirect("~/" & CType(Session("portal"), Portal).LandingPage)

End Sub


Private Function PullPortalBasedOnDomain() As Portal

Dim thisDomain As String = "http://" & Request.ServerVariables("SERVER_NAME").ToString

thisDomain = thisDomain.Replace("www.", "")

Return Portal.GetPortalBasedOnDomain(thisDomain)

End Function



IIS7 Blocks Images in Bin Folders


IIS7 Blocks Images in Bin Folders

The Issue


I got into kind of a stupid habit left over from when I used to develop in PHP, but when I make an images folder, I usually divide my images up into several different subfolders related to their purpose and for all general images, I just toss them into a subfolder named "bin". You can probably guess where this is going. IIS7 blocks view access to all folders in your solution named bin. Unfortunately, the images/bin/ folder is referenced throughout the entire site and would be a monsterous task to go through and replace.

The Solution


Luckily, through some research I found this work around that seems to work great:
    </system.webServer>
<location path="images/bin">
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</location>

Now the bin subfolder within the images folder has view access.

Thursday, January 13, 2011

Given Path Not Supported on Uploads with PostedFile.FileName

Have you intermittently been experiencing issues with uploads on your ASP.NET site?
Seeing errors thrown like "The given path is not supported"?

I recently stumbled across this issue with a couple of pages. I was able to dig down and fix all of my code to handle uploads again.

It looks like the code I was formerly using to save files to my web server is no longer functioning the way it used to. Previously, I saved files something to the style of:
myFileUpload.SaveAs("C:\uploads\" & myFileUpload.PostedFile.FileName)

When I started exploring the error, I discovered that the file path being generated was:
C:\uploads\C:\Users\robfine\Desktop\myFileToUpload.txt

It seems that the function .PostedFile.FileName no longer returns just the name of the file being uploaded, but rather the entire path the file was located at on the uploader's computer.

It's an easy solution to the issue; all you need to do is use the IO.FileInfo class to extract the name of the file:
Dim myFileName as String = New IO.FileInfo(myFileUpload.PostedFile.FileName).Name
myFileUpload.SaveAs("C:\uploads\" & myFileName)


I've done a little of research and it looks like this may be linked to the browser the end user is using. Some version of IE7 and a couple other browsers throw the entire path of the file out there, while other browsers may only give the filename.

Since you never know what browser your user will be using, it's best to cast the .PostedFile.FileName result into the FileInfo class just to be on the safe side.