Lately I’ve been doing a lot of ASP.Net code developed on VS.Net and IIS and deployed (via a cool subversion hook I might add) to my server running mod_mono on Fedora. Usually there aren’t many issue except for the occasional OS specific thing. But today I’ve hit not 1 but 2 hard to figure problems. First I couldn’t download content over SSL, after couple hours I figured it out (mozroots –import –machine & copy pasting a lot of “yes”). Surprisingly after that my code still didn’t work…
Debugging code on mod_mono (at least interactive debugging) is a mystery I’ve yet to uncover, but a couple of “vim” and “gmcs” magic allowed me to find the source of the problems as the source isn’t that complex or hard to split in manageable bits. When I found the problem I couldn’t (and still can’t) believe it. I even tested it on Windows and again on my box using the very same binary… still Mono fails to override that dam method! Here’s my test case:
using System;
using System.Net;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
TestWebClient t = new TestWebClient();
t.DownloadData("http://www.mono-project.com");
}
}
class TestWebClient : WebClient
{
protected override WebRequest GetWebRequest(Uri address)
{
Console.WriteLine("Override Called");
return base.GetWebRequest(address);
}
}
}
On windows the message gets printed, but not on mono. I’ve even looked at the source code for the WebClient class here, and another odd thing is that Mono 2.4.3.2 tarball doesn’t reassemble that file at all, its in fact about 10 months old. Anyway, I was using that WebClient override to manage cookies automatically but I guess that I’ll need to find another way.
If anyone has a clue of the problem or produces a patch please let me know!
It’s a trivial one 😉
In the WebRequest class, replace the call to “WebRequest.Create (uri)” with “GetWebRequest (uri)” and make “GetWebRequest” call “return WebRequest.Create (uri); ” instead of ‘SetupRequest’ and you’re done.
You shouldn’t have to change anything else, but this approach is at least 90% of the issue anyway. If you can test that fix and let us know if it works or not that’d be great. Either way, filing it on bugzilla makes it easier for us to track and fix it. If you can attach a patch which fixes the bug along with additional NUnit tests covering the change, it’s likely to get fixed faster
Switch the first mention of ‘WebRequest’ with ‘WebClient’. Thats where you need to do the method switching. My bad!
Finally, this is the actual WebClient class. You were looking at the Silverlight one.
http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/System/System.Net/WebClient.cs?view=log
The class is in the ‘System’ assembly in the ‘System.Net’ namespace.
Hi,
Thanks for the help, it was kinda obvious I guess… just didn’t look on the right places. Anyway, currently I don’t have a devel Linux box and making a patch/unit test would be kinda difficult. All my debugging was done directly on the server and thats far from recommended 😀
Well, if you can get a patch in very soon and let me know, i can try my best to make sure it gets into 2.6.
Lol love how much developers don’t like filing bugs… even those responsible for projects!
Lol, personally I don’t mind filling bug reports except that with Mono I’m a bit frustated due to past experiences. I did a lot of patches to fix SqlServer bugs, Dns Bugs and even did autocompletion on MonoDevelop 2 years before they implemented it – sad thing is that my work tends to go into a dark hole for years, even with my stalking on irc, personal mail and even blog posts lol. http://www.alexandre-gomes.com/?p=126
Anyway @Alan I’ve downloaded a Ubuntu VM and although I din’t touch Mono’s code for a long time I’m going to give it a shot, if nothing else its a nice test to check if my commit access is still up 😉
It’s not laziness or hatred of filing bugs, the reason I won’t file this is because I have no way of verifying the fix works. Therefore how could I possibly mark the bug as fixed? If alex files it, I can notify him (by updating the bug) that a fix is in SVN. He can then test it and notify us (by updating the bug) if it resolved his issue or not. It’s a paper trail which makes it much easier to ensure things get fixed
Secondly, if there are 100 bugs in my area, pretty much everything with an attached testcase will be prioritised. If I have to 1) Find the bug, 2) Write a testcase, 3) Write a patch, 4) Check back with the original dev as to whether it fixed their issue or not, 5) Go back to 1 if it didn’t, i waste a lot of time
Hiya, don’t suppose you fancy sharing the subversion hook, would be dead handy?
It was a bit of an ugly hack really. I can’t recall but at the time it was the best or fastest solution. Anyway, what I’ve done was create a small C app with this code:
#include
#include
#include
int main(void) { execl(“/usr/bin/svn”, “svn”, “update”, “/var/www/whotouchesnet”, (const char *) NULL); return(EXIT_FAILURE); }
Compile it with “gcc -o binname filename.c” and then “chmod a+x binname”. After that you just might need to fine tune the permissions on the working copy a bit, just remember that the executable and the svn up command will be run with the apache’s user credentials.
Might not be the best solution but it is simple enough and works like a charm! Never fails, I commit and my sites are updated. Just a word of caution though, make sure you’re using branches to manage the production/test versions of the site or service. Personally I’ve a production branch which goes life on http://www.domain.com and then I’ve the trunk/main branch going to a test.domain.com – that way I can test/debug freely without concerns about bugs.
@Alan
I’ve done it all. Patch, test case and bug report. https://bugzilla.novell.com/show_bug.cgi?id=549580
Please take a look at it, I’ve tested it to make sure the test is accurate and no regressions on the other tests were detected. I did a similar fix on my mono 2.4.3.2 sources on the production server (this machine) and everything started to work like it was supposed to.
If you think its OK to commit to the Mono’s trunk, let me know. I haven’t done a Mono commit in a while and its kinda like candy for hackers 😛 I just love it.
[…] requests. Luckily, Mono behaved quite well after that last little problem I blogged about – Mono Strange Behaviour (Bug!). I also had to implement several security checks and encryption to make sure no data can be stolen […]