Posts Tagged IIS
IIS 7.x and HttpResponse.Headers
Posted by suddenelfilio in .net, Asp.net, Programming, Web Services on 15/07/2011
Today I was debugging some application I wrote that was written with an application pool’s mode set to Integrated mode in mind. One of my colleagues told me I needed to test it running in an application pool with its mode set to Classic.
And guess what? Boom… it blew up in my face! After cursing around a bit I discovered in my log files the following message:
ERROR An Exception was thrown:System.PlatformNotSupportedException: This operation requires IIS integrated pipeline mode.
at System.Web.HttpResponse.get_Headers()
The defect piece of code was this:
HttpContext.Current.Response.Headers.Add("Some-Header","Some-Value");
Apparently to do that you need the IIS integrated pipeline mode. Well if you really need to run your app pool in Classic mode just replace your code with the following and all is well:
HttpContext.Current.Response.AppendHeader("Some-Header","Some-Value");
I know it’s kind of silly from Microsoft to not make this both ways compatible.
Increase Kooboo performance in IIS 7
Posted by suddenelfilio in Asp.net, Visual Studio .Net, Web & Design on 10/08/2010
Lately I’ve been working with the Kooboo CMS which is built using ASP.NET MVC. I really like the speed Kooboo allows you to build a website with dynamic content. All that fancy footwork comes with a downside. The first time you call a Kooboo application it is really and do mean REALLY slow to start. Cause? Well the Asp.net MVC framework, Microsoft Entity framework and most of all I think the extensive caching mechanism.
I’ve experienced waiting times up till 30 seconds for the first page to appear, now this is not really acceptable for any site I admit. I remembered that there is IIS 7 extension called application warm-up tool that you can configure to call a certain url when the worker process recycles. This will trigger the site to startup again and load up all the caching and stuff. I’m not saying that the next call will be blazingly fast but at least your request will be served much faster.
I’m currently developing several sites using the Kooboo platform and I’m pleasently surprised of the possibilities of the platform. Thumbs up for the creators!
IIS 7: HTTP POST, DefaultDocumentModule and a forgotten '/'
Posted by suddenelfilio in Uncategorized on 06/02/2009
Yesterday I experienced some issues when I was trying to access a generic http handler (*.ashx) file using only the path without the filename e.g.: http://localhost/somefolder
The default document was set to uploadhandler.ashx. So i expected that if I connected to http://localhost/somefolder it would sent me to http://localhost/somefolder/uploadhandler.ashx but it didn’t. Appareantly it has got something to do with not adding a ‘/’ at the end. For the exact problem and also the reason why it didn’t work as well as the solution have a look at post of mine put up at the iis.net fourms http://forums.iis.net/t/1155013.aspx
Compact framework WCF, Disco files, netcfsvcutil
Posted by suddenelfilio in Uncategorized on 06/11/2008
When using the 3.5 version of the compact framework it is possible to connect with wcf services. This is because the CF 3.5 contains a limited subset of the wcf technology. There are several blog posts listing the wcf capabilities in CF e.g.: http://blogs.msdn.com/andrewarnottms/archive/2007/08/21/the-wcf-subset-supported-by-netcf.aspx
We were researching for a mobile client to connect to a wcf service running at one of our servers. The requirement is that transport is secured by using HTTPS protocol.
The first problem was creating a client side proxy. Since the SvcUtil doesn’t work for the CF we had to look for an alternative. After some googling we found the netCFSvcUtil which is basically the same as the svcutil, but it generates a proxy specifically for CF. You can find it as part of the Power Toys for .NET Compact Framework 3.5. For more on this you can read this excellent blog post by Andrew Arnott
When you get this generated client proxy there is another problem. It expects that you are using HTTP. Since we need HTTPS that’s a problem. Thanks to Damir Dobric we found how to make the proxy use https instead of http.
System.ServiceModel.Channels.CustomBinding binding = new System.ServiceModel.Channels.CustomBinding(); binding.Elements.Add(new System.ServiceModel.Channels.TextMessageEncodingBindingElement (System.ServiceModel.Channels.MessageVersion.Soap11, System.Text.Encoding.UTF8)); System.ServiceModel.Channels.HttpsTransportBindingElement https = new System.ServiceModel.Channels.HttpsTransportBindingElement();
https.RequireClientCertificate = false;
binding.Elements.Add(https);
This way your client proxy is now HTTPS enabled.
Another problem we had was that the disco file was downloaded from the “wrong” location. We have a wildcard certificate in place for our HTTPS like *.domain.com. We were accessing the service using https://laptop1.domain.com/wcf/service.svc. Although this url works fine when we browsed to it, there was an issue when we tried to generate a client proxy. It seemed that both svcutil as netcfsvcutil were trying to download the DISCO file from https://laptop1/wcf/service.svc?Disco. When we browsed to this link it worked just fine. The problem is in the url and the wildcard certificate. Since the disco url didn’t include the domain.com part in its url the utils were not able to establish a trust relationship over ssl with the web server. This is perfectly normal since it does not correspond with our wildcard certificate.
The solution is to update the https binding in IIS by giving it a host header. Now this is something you can’t do in the IIS control panel. There are 2 ways of doing this: Using scripting or using the metabase explorer that can be found in the IIS 6.0 resource toolkithttp://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36-5761-448f-889e-9ae58d072c09.mspx?mfr=true
A last advice don’t fall into the same trap by thinking that a wshttpbinding is required to do HTTPS, it’s perfectly possible by using a basichttpbinding where the security mode is set to transport.
It’s here to stay: Frontpage Server Extensions
Posted by suddenelfilio in .net on 02/07/2007
Although nobody really uses the program for which this technology was initialy created – Microsoft Frontpage – there are still programs that use the FPSE. Like Visual Studio .Net uses it to publish a website/webservice.
With the new IIS 7.0 most developers will know about the “publish problem” from vs.net to an IIS 7.0 web server, because of the different meta system that come with IIS 7.0 this vs.net feature stopped working “properly”. You could choose for the traditional XCopy and in vs.net 2005 for publishing through FTP. There is also an option to turn on backward IIS 6.0 compatibility in IIS 7.0 for legacy systems.
Now the IIS 7.0 team is releasing the first beta of the FrontPage Server Extensions for IIS7:
Overview
Microsoft and Ready to Run Software have released a beta version of the FrontPage 2002 Server Extensions (FPSE 2002) for Windows Server Code Name “Longhorn” and Windows Vista.
Features
This version of FPSE 2002 introduces no new functionality, and is essentially the same version that was created for Windows Server 2003 that has been updated to work on Windows Server Code Name “Longhorn” and Windows Vista.
Benefits
FPSE 2002 enables web hosters and developers to author their web content on servers or workstations that are running IIS 7.0 on Windows Server Code Name “Longhorn” and Windows Vista.

