As I posted
earlier we had some trouble with upgrading the UIPAB to be used in a ASP.Net 2.0 Web Application Project. Eventually, we solved the problem and life was good. Almost a week ago I received a mail through my blog from someone looking for the solution. So here we go...
We changed a few lines in the UIPAB WebFormViewManager. The problem was in determining the application path in the method 'RedirectToNextView'. Here the applicationpath was all garbled up, which caused the redirect not to work. We implemented a property to return the right applicationpath:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27 |
private string applicationPath = null; /// <summary>
/// Property returning the entire URL to the current request,
/// excluding the page name but including the last slash ("/")
/// </summary>
private string ApplicationPath
{
get
{
if (applicationPath == null)
{
if (HttpContext.Current.Request.UrlReferrer == null)
{
applicationPath = HttpContext.Current.Request.Url.ToString().Substring(0, HttpContext.Current.Request.Url.ToString().LastIndexOf("/") + 1);
applicationPath += "(S(" + HttpContext.Current.Session.SessionID + "))/";
}
else
{
applicationPath = HttpContext.Current.Request.UrlReferrer.AbsoluteUri;
applicationPath = applicationPath.Substring(0, applicationPath.LastIndexOf(")/") + 2);
}
}
return applicationPath;
}
} |
The above returns the path we need. It's not a perfect example of
defensive programming, but that's not the intention of this post ;). We added the sessionstring because the application in which we used the UIPAB kept the session id in the URL. The RedirectToNextView method now looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
private void RedirectToNextView(string previousView, ViewSettings viewSettings)
{
try
{
if (previousView == null)
{
HttpContext.Current.Response.Redirect(ApplicationPath + viewSettings.Type, true);
}
else
{
HttpContext.Current.Response.Redirect(ApplicationPath + viewSettings.Type, false);
}
}
catch (System.Threading.ThreadAbortException)
{
}
} |
And that's it! Looking back the problem seemed so big, but the solution seems/is so simple... ;)
I encountered his error for the first time today. A Web Application Project I've been working on for the last months started throwing this error today almost every time I wanted to debug the project. The assembly info changed from time to time, but the error was the same. Most of the time I could 'repair' it by closing the ASP.Net development server. But sometimes, even that didn't work.
After the first time it hit me today, I kept encountering this until I was fed up. I searched the internet, but there's not much documented about this little bug. There are more people with the same problem but I didn't find a solution at first. Then I found this page. That's the exact error I'm getting! And now I think of it, I too always build my solution before I press F5 to debug. After searching based on that page, I found this post here. It seems there's a web.config solution for this problem: adding <hostingEnvironment shadowCopyBinAssemblies="false" /> to the system.web element of your web.config file. The 'shadowCopyBinAssemblies' property is described as follows: Sets a Boolean value indicating whether the assemblies of an application in the Bin directory are shadow copied to the application's ASP.NET Temporary Files directory.
Hope this helps.
I signed up at technorati recently. Technorati uses ping to get the info from blogs. And BloggingAbout.Net (Community Server) supports that. Or it should... Some posts just don't show up over there! I've searched a little, and saw other people were having trouble with this too. I'll see if I can find anything and if I do, I'll forward it to our community administrator.
We all encountered them in the field somewhere along the way: pieces of code that are based on assumptions. There's something fundamentally wrong in assuming when writing code. I can understand that, looking at the big picture, you sometimes have to make an assumption when developing software. Some things you just can't know for sure. This might concern something simple like the resolution of the targeted audience. But most of the time these kinds of assumptions are based on experience or plain old common sense. When these assumptions fail to be true, most of the time a mitigation strategy is at hand. And the software usually keeps running.
When it comes to actually writing lines of code, I think you should always check and never assume. I tend to compare it to riding on a motorcycle. My instructor teached me to drive defensively. To 'Expect the unexpected'. Sure, you can assume there won't come a kid running from inbetween the two parked cars, but why take the risk? It's better to anticipate a kid running across the street, so you can react accordingly when it does. And if it doesn't? You at least didn't take a chance ...
Sometimes, an assumption is obvious:
1
2
3
4
|
public string ConvertObjectToString(object objectToConvert)
{
return objectToConvert.ToString();
} |
Here, you assume the object which is passed in will always contain an actual object. But when a null reference is passed in, this method will throw an exception because objectToConvert is not set to an instance of an object and therefore you can't invoke ToString(). When this method is written 'defensively', it looks something like this*:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public string ConvertObjectToString(object objectToConvert)
{
string returnValue;
if (null == objectToConvert)
{
returnValue = string.Empty;
}
else
{
returnValue = objectToConvert.ToString();
}
return returnValue;
} |
That was an easy one. Sometimes, assumptions in code aren't very transparent. Let's take a look at this sample:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/// <summary>
/// Method that 'does something' to a Control.
/// </summary>
/// <param name="controlToWorkOn">Control on which 'someting will be done'</param>
/// <returns>A Control on which 'something has been done'</returns>
public Control DoSomething(Control controlToWorkOn)
{
if (null != controlToWorkOn)
{
if (controlToWorkOn is TextBox)
{
//Do something important to a TextBox
}
else if (controlToWorkOn is Button)
{
//Do something important to a Button
}
}
return controlToWorkOn;
} |
We will leave the 'do something important to...' parts out of this. The Control is checked for being null. The Control is typechecked so no wrong casts will be made. So nothing seems wrong, right? The problem here is the fact that you
know this method only does something for a TextBox or a Button. But what happens if a year from now somebody gets the assignment to change the application, and he or she
doesn't know about the method only working for TextBoxes or Buttons? The method will return the Control unchanged, but the caller might think everything is OK. Often we write methods with certain constraints about the calls made to that method in the backs of our heads. And often without realy realizing it. But there might come a time that somebody who doesn't know the constraints has to jump in.
To be sure passing in another type of Control will not give any problems, you might consider a solution like this one:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
/// <summary>
/// Method that 'does something' to a Control.
/// </summary>
/// <param name="controlToWorkOn">Control on which 'someting will be done'</param>
/// <returns>A Control on which 'something has been done'</returns>
public Control DoSomething(Control controlToWorkOn)
{
if (null != controlToWorkOn)
{
if (controlToWorkOn is TextBox)
{
//Do something important to a TextBox
}
else if (controlToWorkOn is Button)
{
//Do something important to a Button
}
else
{
throw new NotSupportedException("Control-type not supported in this method");
}
}
return controlToWorkOn;
} |
Another way to solve this problem is to make the DoSomething method private and generate two public methods. One that takes a TextBox and one that takes a Button, both eventually calling the private DoSomething method. This would actually be the solution I would choose, because then the problem pops up compile time in stead of runtime. And I think it aids future developers better.
'Defensive programming'. Writing software anticipating as many problems as possible to ensure correct functioning of the software. Even when the software is edited later by someone who doesn't have your mindset.
Edit: Wikipedia has an
article on defensive programming.
Edit2: Thanks Geraldo Hockx for your sharp eye! I changed the code samples: I made a few typo's.
* Yes, you could initialize the local parameter to string.Empty and only have an if-statement. And yes, you could use the conditional operator. And of course you could use two return statements. But this is my coding style (at the moment) so this is how I would do it right now ;).
Today I changed the appearance of my blog. The header has changed, and the content part is much wider. Because of the self-made banner I think this is a little more personal. Or a little less ordinary, whichever you prefer. If you have any feedback, please let me know. I think it's pretty sweet, although this won't show up pretty in a resolution below 1280 x 1024... Ah well, I think most people in our line of work will meet this requirement.
Following soon: a post on developing software as if you were riding a motorcycle...