YsA.Net

In Asp.Net 4 the request validation model has changed (Yet another breaking change). In short, request validation is a security feature of Asp.Net which meant to prevent a user from XSS or script injection attacks. In Asp.Net the behavior of request validation has changed.  Validation of the input is know performed in the BeginRequest stage in the life-cycle .

When we converted out web application to Asp.Net 4, we found out that one of our pages, which uses a control call FreeTextBox, threw a validation exception each time an input was typed and submitted in that control.

FreeTextBox control is used to allow users to create composite text which can be displayed in html – features like font sizes/types, bold, alignment etc… The control actually creates html from the user input and commands.

Asp.Net 4 interprets the generated input from the control as a XSS attack and prevents the page from running.

Doron posted on this subject, but in Asp.Net 4 there is no page directive for the mode of the request validation.

The immediate solution was to change the request validation model to run in Asp.Net 2.0 runtime. The change is quite simple. Simply add the following line to the web.config, under the system.web node:

   1: <httpRuntime requestValidationMode="2.0" />

If your page is in a folder you can create a web.config file their and put this line so the request validation in 2.0 mode will work only on the pages in that folder (so the other pages in the app can use the 4.0 mode).

In the long run we plan to upgrade the control (which is pretty old) to a newer version (impossible now due to an upgrade to the FreeTextBox site) or to replace it with RadEditor control from the RadControls suite, which from initial tests doesn’t have this problem.

More on that soon…

Last week I found out that one of our admin apps on the server was not installed currently. It is an app that is installed in ArcMap, and the reason it didn’t work is that ArcMap has been installed on “d:\programs files” instead of “c:\program files”. The msi depended on the location in c:\.

I opened the solution to try to fix the installer. I found out that when you install ArcDesktop it adds an environment variable named “ARCGISHOME”. I also found out it is impossible to take a dll from a primary output in an msi and order the msi to put it in another folder.

So I used a custom action in the install phase with a VBScript file.  In order to do that you need to:

1. File –> New –> Text File
2. Save the text file with .vbs suffix under the setup project folder in the file system
3. Right click on the setup project is VS –> View –> Custom Actions
4. Right click on Install –> Add Custom Action
5. Select the vbs file
6. OK

Open the vbs file and write the following script:

To copy the files I needed I used:

   1: Set wsShell = WScript.CreateObject("WScript.Shell")

   2:  

   3: Dim targetDir = Session.Property("CustomActionData")

   4:  

   5: RunScript = "xcopy """ + targetDir + "\somefiles"" ""%ARCGISHOME%bin"""

   6: wshell.run RunScript

In the vbs file properties under “Custom Action Data” enter “[TARGETDIR]” – This tells the msi to set the CustomActionData property the the folder in which the msi deploys it’s main files.

If you run this script under an msi you will see it does not work…

After of couple of frustrating  debug trials, I found out that under an msi host, a VBScript can not used environment variables. In order to use environment variables we can use the WScript method called ExpandEnvironmentStrings .

So know the script will be:

   1: Set wsShell = WScript.CreateObject("WScript.Shell")

   2: Dim targetDir = Session.Property("CustomActionData")

   3:  

   4: arcGisHomeDir = wsShell.ExpandEnvironmentStrings("%ARCGISHOME%")

   5:  

   6: RunScript = "xcopy """ + targetDir + "\somefiles"" """ + arcGisHomeDir + "bin"""

   7:  

   8: wshell.run RunScript

This one works perfectly.

Use it wisely

You’ve upgraded your project to Visual Studio 2010 and .Net framework 4. Good for you! But when you checked in the projects and the build in TeamCity starts to run – alas – Build failed!

In order to run an upgraded project in VS2010 follow these steps:

1. Make sure your TeamCity server can run VS2010 solutions (version 5 and up of TC).
2. Install Visual Studio 2010 and .Net framework 4 on your server.
3. If your project is a web project which uses Web Deployment Project, install web deployment project for VS 2010 on the server.
4. Now you need to configure TeamCity to run your project in VS2010:
   • Enter your TeamCity web access
   • Click “Administration” button
   • Click your project configuration in the list.
   • Click on “Runner” in the right menu (Can show as “Runner: Visual Studio (sln)”)
   • Change the value of “Visual Studio” property to “Visual Studio 2010”
   • If your using nUnit, change the value of “Framework” under the nUnit definitions to 4.0 (if that doesn’t appear select a different version of nUnit).
5. Run the build of the project

Good luck!

This week my team upgraded our solutions to Visual Studio 2010 and .Net framework 4. When we ran the tests of one our projects, one of our tests failed with a weird reason. The code is simple:

   1: public DateTime CreateDateWithGivenTime(string time) 

   2: { 

   3:     var t = TimeSpan.Parse(time); 

   4:     ... 

   5: }

The test was:

   1: [Test] 

   2: [ExpectedException(typeof(OverflowException))] 

   3: public void CreateDateWithGivenTime_HoursNotInRange_ThrowOverflowException() 

   4: { 

   5:     CreateDateWithGivenTime("77:11:00"); 

   6: }

Testing on a branch before the conversion – the test passed.

Debugging the code in both cases showed different behavior of the framework:

Framework 3.5: Throws exception

Framework 4: Code recovers and parses the string as if “77” is days, “11” is hours etc…

Apparently, according to msdn, TimeSpan.Parse behaves differently in framework 4. I was very amused to see how the writer avoids the word Breaking change. The docs indicates that in certain cases where in .Net framework 3.5 Parse throws an exception, in framework 4 all is good  and vice versa.

Lucky we have tests…