November 2005 - Posts
I ran in to something strange today...
The ASP.Net 2.0 Menu control renders differently in a browser and in the W3 validator. Loading the page in a browser results in the usage of the correct attribute 'vertical-align' for the image which is used to indicate a menu has subitems. I checked this in IE and FireFox and both browsers rendered correct XHTML. When you copy the source of the rendered page and paste it in the validator-textbox at W3.org, it validates the XHTML. When you check the page directly by entering a URL, the menu renders using the non-correct attribute 'valign', causing my page to fail validation. But the copied source passes validation!
I'll investigate this strange behaviour and get back at you when I find something. If you know where this is comming from: drop me a line in the comments.
As a follow-up to my
previous post..
Eventually a colleague of mine pointed me in the right direction. The
System.Runtime.Remoting part of a configfile can also contain a <customErrors> tag. Setting it to "Off" made that I got the expected exception. Thanks Jasper!
We are using binary .Net remoting over http for a client-server application. At the server, we have implemented custom error handling which results in the Service Interface (the facade layer) to throw a decent exception, with lots of information. The problem we encounter now is that most of the time the client displays these exceptions as BinaryFormatter exceptions, in stead of the ApplicationException or the normal Exception we throw serverside.
Does anyone have experience with this? How do we keep our rich exception when we travel to our client? Please drop me a line in the comments.
When you use No-touch deployment, reading your config file might cause some problems.
I experienced this when I received a 'No message was deserialized prior to calling the DispatchChannelSink' error last week. It took me quite some time before I found the problem, because of the strange error. After a while I thought about the way my app was starting: I started a separate thread which configured a remoting interface based on the config file: RemotingConfiguration.Configure(). This because of the non-standard binary formatter that was used. The thread didn't throw an exception (I know, bad programming, but it was a proof-of-concept ;) ) and so the app tried to communicate with the remoted object..... which resulted in the error above.
Adding a try..catch to the code in my thread gave me the next error: '.Config file http://domain/app.exe.config can not be read successfully due to exception System.ArgumentException: URI formats are not supported'. This was a decent error and challenged me to solve it. That didn't take too long ;)
The steps I coded to tackle this problem:
1. Try reading the config file from the current location
2. If an exception occurs, download the file to the ApplicationData folder (make an app-specific folder for it)
3. Read the file from the downloadlocation
The code I wrote for this is on my other computer. If someone's interested: let me know.
Last week I played with VS2005 a little. My first overall impression is: sweet! Partial classes, nullable types, generics, master pages, new controls, great extra debug info... they all make our life a little easier.
Still, some things are rather funny. For instance: why can't you see webpage-events any more, but do you have to write them yourself combined with auto event wireup? On one hand, I could imagine that the use of (too many) page events is not the right thing to do, and that's the reason they made it a bit harder. On the other hand: everything is made easier in this VS release, so why not this?
Maybe I overlooked something, maybe there's a good explanation. To be honest: I don't care. I just wanna play with VS2005 
.