I wanted to debug some .NET code from an oldfashioned ASP page. the ASP page called a COM enabled .NET component using Server.CreateObject().
The ASP page received a form posting before the call to the component.
If I replaced that serverside code with ASPX, then I instead could instanciate the .NET component through a “new MyNamespace.MyComponent()” instead of the “Server.CreateObject()”. By setting the posing ASP form as the startup url like http://mysite/myform.asp, I was then able to set a breakpoint in the new aspx page that received the form posting (myform_actions.aspx). The debugging could nicely continue in the .NET component.
When you do this trick of upgrading the code for the received form post, there is a few things to consider:
- You need to reauthenticate in some way
- The Session state from ASP is not shared with you ASPX session. You need to recreate any session variables in your ASPX session, if you need to use them in your migrated code.
- Encoding of the form post needs to be done.
The migration worked fine and the debugging was a releave.
But initially I haven’t set the encoding.
When the form post entered the myform_actions.aspx I could see (using Fiddler) that a posted “ø” was sent correctly as “%F8″, but it was tranlated to “?”, when read from Request(“MyTextInputCtrl”).
There were some links telling me about the problem:
http://bytes.com/topic/asp-net/answers/491522-encoding-problem-when-posting-text-between-classic-asp-asp-net
http://www.w3.org/TR/html4/interact/forms.html#adef-accept-charset
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfGlobalizationSection.asp
The latter link fixed the problem:
<configuration> <system.web> <globalization requestEncoding="iso-8859-1" responseEncoding="iso-8859-1"/> </system.web> </configuration>
The accept-charset I did not use. It probably is not understood in a HTTP/1.0 post.
The End.
