Showing posts with label IIS. Show all posts
Showing posts with label IIS. Show all posts

Tuesday, June 19, 2012

Blank Page when Publishing a Silverlight App

I just deployed a new Silverlight application to a Windows Server 2003 box as a new website and was surprised with a blank page when I launched the application. No error messages or warnings, just a completely blank page.

A quick web search and I realized I had been here before. You have to register the MIME types, .xaml and .xap, in IIS for the website. I added them for a previous website, but I didn’t add them at the server root.

Simple instructions to add the MIME types to IIS can be found on Jacqui’s Dev Blog under Deploying Silverlight Application - Why Blank?! Note the first blog post comment that suggests adding the additional .xap application/x-silverlight-app and .xbap application/x-ms-xbap MIME types. I didn’t need to add the .xbap to get my application working, but I did need the .xap.

Wednesday, September 14, 2011

Using jQuery datepicker with MVC3 textboxes

Pick a dateThis post addresses two issues:

  1. Using the built-in ASP.NET Development Server vs. IIS to render the datepicker. If you are using IIS, skip to the second section.
  2. Dependencies necessary to get the jquery ui datepicker to work in an MVC3 project.

ASP.NET Development Server

I repeatedly have issues with AJAX controls (like the ModalPopup control) rendering with the correct styles using the ASP.NET Development Server vs. IIS. The jquery datepicker is no exception, but this time it surfaces as the following error “Microsoft JScript runtime error: Object doesn't support this property or method” in the jquery-1.5.1.min.js, which isn’t very helpful for troubleshooting.

image

On a hunch, I decided to configure the project as an application in IIS and access it via localhost/appname instead of the dynamically addressed port of the ASP.NET Development Server - giving me a more meaningful error to troubleshoot.

jQuery UI dependencies

Using the IIS served application, I received the tiny warning triangle in the lower left corner of IE that indicates a javascript error, “Message: Object doesn't support this property or method”. The offending line of code was $("#EstDateStarted").datepicker();.

My project was based on the standard Visual Studio 2010 MVC3 project template which included only the jquery-1.5.1.min.js in the _Layout.cshtml file using the Razor rendering engine. The .datepicker function is not located in that javascript file it is in the jquery-ui-1.8.11.min.js file. All I needed do to enable that functionality and resolve the error was to add the following reference to the head of the _Layout.cshtml file, which includes it on all the pages of the app:

<script src="@Url.Content("~/Scripts/jquery-ui-1.8.11.min.js")" type="text/javascript">

jquery ui datepicker

photo credit: augapfel / CC BY-SA 2.0

Thursday, April 7, 2011

IIS is Missing XAP Mime Type for Silverlight Application

lego mimeUpon navigating to the web page hosting a newly deployed Silverlight application, I received the following error:

Error: Unhandled Error in Silverlight Application
Code: 2104   
Category: InitializeError      
Message: Could not download the Silverlight application. Check web server settings  

Thanks, but which server settings? In my case the MIME type for the .xap extension was missing in IIS7. I’m not sure why it was missing since .xaml and .xbap were already defined. I simply added the “.xap” extension and it’s corresponding MIME Type “application/x-silverlight-app” and all was well.
Xap Missing Mime Type In IIS

photo credit: e v a . p é b a r / CC BY 2.0

Monday, December 20, 2010

Visual Studio Cloud Service for Azure Development Requires IIS7

View above the clouds over NevadaLately I am really wondering about the utility of using the Visual Studio built-in web server for development. Last month it was causing inconsistent rendering of AJAX modal popups, this month installing the Visual Studio Cloud Service for Windows Azure development requires IIS7.

Having the built-in web server seemed like a way to minimize the system resources and attack surface of the development workstation, but it doesn’t seem as practical anymore.

Thursday, November 18, 2010

Five Reasons to Use a Staging Server

Concert Stage - Green DayIf you are interested in avoiding common and difficult to reverse issues when deploying new or updated software to a production environment, use a staging server – at a minimum. Your staging server should be configured as closely as possible to the production server. With virtualization, the process of cloning a server becomes a relatively trivial task.

A staging server provides a safe vehicle to “discover” and prevent commonly overlooked deployment issues:

  1. missing assembly references or resources. This is a frequent occurrence if you use third party tools like Infragistics, Telerik, or another. When you install the development tools, they often add the assemblies to the GAC on your development box and scripts and images to “special” virtual directories. If you blindly deploy an application to production without making sure you have the assemblies either in the GAC or referenced properly in your application, it can frequently lead to run time errors and the yellow screen of death. Even items you might think are part of the .Net Framework that are pre-loaded in your Visual Studio toolbox, such as the ReportViewer control require the installation of a ReportViewer Redistributable executable.
  2. dependencies on physical hardware. Depending on how the application is configured, your application may unwittingly be relying on a writeable F drive where on the server the F drive may not exist or may be a CD-ROM drive. Or require a 64 bit processor on a 32 bit server. It is better to catch these issues before deploying to production.
  3. require elevated file system permissions. If your application is writing XML files or storing media, the application upload path will require Write permissions for the accessing account. Permissions requirements should be part of the installation/upgrade process, not left to post installation troubleshooting.
  4. require least privileges on database permissions. You may be using the sa account (not recommended)on your development box, but your production DBA and/or company policies won’t appreciate that in production. This is an opportunity to make sure your application is running under an account or group with the least privileges necessary to run the application and make sure if your installation process is dropping/re-adding stored procedures or tables, you are also adding the appropriate grant select, insert, update, delete, execute, bulk insert, or truncate permissions to avoid unexpected SQL errors.
  5. require configuration changes to interface with other services, such as IIS version differences, SMTP, or Message Queues. On your development box, for simplicity, you might be using a local IIS SMTP service, or file system implementation to test emailing functionality, but if the production environment only allows mail to relay through a Microsoft Exchange endpoint, you have some additional configuration to do. Making sure all the appropriate accounts are understood and configured properly often takes coordination with other IT specialists. They’ll appreciate it if you coordinate it at their convenience on a staging server instead of elevating the issue to a production emergency.

This isn’t intended to be an all inclusive list, but hopefully if you are not using one today, it will inspire you to consider using one in the future. Prevention is the best medicine for software implementation.

The staging process provides an opportunity to perfect the installation process for a problem free installation. Additionally, having the installation process consolidated to a single series of installation and configurations steps in a single package with all the necessary files and scripts can simplify recreating software versions for disaster recovery purposes or for replicating to additional installation deployments, such as for different customers or at a different site.

Photo credit: Anirudh Koul / CC BY 2.0

Friday, November 5, 2010

Ajax Control Toolkit Modal Popup CSS Styling issue

I found an interesting (and aggravating) difference between running a web application in the built-in Visual Studio 2010 development server vs. IIS 7 when using the Asp.Net 3.5 Ajax Control Toolkit ModalPopupExtender control. In the built-in web server (screenshot 1), the CSS formatting did not render correctly as it did in the application hosted in IIS7 (screenshot 2). Initially I used the standard styles you will find on the toolkit sample code.

Hopefully this will help some of the many other people that had the same problem.

Click the screenshots for enlarged views. The code used follows the screenshots.

ModalPopup Visual Studio Development Server

ModalPopup hosted in IIS

ManagePeople.aspx

<asp:ModalPopupExtender ID="pnlModalNew_ModalPopupExtender" runat="server" 
    DynamicServicePath="" Enabled="True" TargetControlID="btnNew"  PopupControlID="pnlModalNew"
    BackgroundCssClass="modalBackground" DropShadow="true" 
    CancelControlID="btnCancel" >
</asp:ModalPopupExtender>

Styles.css



/* Modal Popup */
.modalBackground {
    background-color:Gray;
    filter:alpha(opacity=70);
    opacity:0.7;
}
 
.modalPopup {
    background-color:#ffffdd;
    border-width:3px;
    border-style:solid;
    border-color:Gray;
    padding:3px;
    width:250px;
}

The Panel pnlModalNew referenced by the ModalPopupExtender that contains the data entry form fields had the CssClass style set to .modalPopup.

Wednesday, September 29, 2010

Blocked and Encrypted Javascript Files and IIS Windows Authentication

lockout tagout I ran into an interesting issue with an application using a couple of javascript files I downloaded from the internet to modify and use in a web application for drop-down navigation. As long as I was accessing them using http://localhost, the javascript cascading menu functionality worked fine.

Windows Authentication

As soon as I started testing using http://machinename instead of localhost, I was prompted for my PC’s username and password. No problem, I realized I hadn’t disabled Windows Authentication in IIS 7 (since I was using Anonymous Authentication). When I disabled Windows Auth, the javascript didn’t work any more – even from running on the same physical PC. I turned Windows Auth back on and the javascript worked again.

Blocked

I figured there was probably some kind of trust issue, so I looked at the javascript filenames in Windows Explorer and found the names were colored green. I right clicked the properties and realized they were flagged as “Blocked” because they were downloaded in a zip file from the internet. I’ve run across that before so I clicked the “Unblock” button.

Encrypted

The files were still colored green and the javascript still didn’t work. I found that if I right clicked the filename, clicked on properties and “advanced”, the files were also encrypted. I unchecked the “Encrypt contents to secure data” checkbox and the javascript started working.

Problem solved.

photo credit: OhlieVher A. Arango / CC BY-ND 2.0