Hugo Estrada's House of Wonder

I have been working on a silverlight project recently, so I got a lot of little nibbles of wisdom on this technology. Unfortunately I am very busy for the next few weeks, so I won't get to share them with readership, which mainly consists of myself (and as a reader, I just love the good quantities of great tips and information this blog provides to me.).

In any case, the weird silverlight issue of the moment:

I am working on a custom control, and then, after I did something to it, the design mode breaks. The behavior of the control if fine while I am running it; it just messes design mode big time. And it gives me an error about how the instance couldn't be created. Searching for the error message is fruitless since it seems that many things can happen to make xaml choke.

Then the message told me about how I should search at some Key Value stuff. I look towards the end of the main error, and this is what I get:

HtmlPage_NotEnabled

Which happens when you are calling on the Browser object, such as when you need to get the root url of the site.

The solution is to use the following check:


using System.ComponentModel;

if (!DesignerProperties.GetIsInDesignMode(this))
PopulateTree();

For the full explanation, go to the site below. Thanks, Andy :)
http://www.andybeaulieu.com/Home/tabid/67/BlogDate/2009-06-30/Default.aspx

Yesterday I walked into an interesting problem. After I finished cleaning up an SVN debug folder, my MVC app stop working, specifically calls to JSON. That were working previously.

I thought it must have something to do with silverlight since it was there where I found the exception. I did a series of searches looking for an answer, but I didn't find one since I looking at the wrong thing.

The actual problem had to do with MVC. I was getting the following response:


This request has been blocked because sensitive information could be disclosed to third party web sites when this is used in a GET request. To allow GET requests, set JsonRequestBehavior to AllowGet.


I did a search on this error. Behold! The issue was a change in how JSON is handled in .NET MVC. Adding a simple line took care of the issue.

return Json(result, JsonRequestBehavior.AllowGet);

http://forums.asp.net/t/1483387.aspx

So I want to use the .Net DataContractJsonSerializer object. I check on msdn for what are the references that are needed:

http://msdn.microsoft.com/en-us/library/system.runtime.serialization.jso...

But it didn't work. I wasted about 20 minutes trying to troubleshoot what it was. I did a search on it, and I got the following answer:

using System.Runtime.Serialization;
using System.ServiceModel;

System.Runtime.Serialization.dll
System.ServiceModel.dll
System.ServiceModel.Web.dll

http://forums.silverlight.net/forums/p/14304/367154.aspx

Grrr. What is wrong with that .Net documentation? So I go back, and scroll to the comments:

Regarding the problem mentioned earlier, i want to say this article is right: this class resides in System.Runtime.Serialization dll for the .NET Framework 4. The problem lies in the assembly version: although the class is contained in the version 4.0.0.0 assembly, you won't find it in earlier versions. This class was migrated from System.ServiceModel.Web to System.Runtime.Serialization in .NET 4.

Thus, if you are using .NET 3.5 SP1 or earlier, you should look for this class in System.ServiceModel.Web dll.

Ah! So that was the problem! Maybe this is a false memory, but wasn't there an easy way to toggle between the different versions of a page on the msdn site? That was useful.

Learning testing from dynamic languages such as javascript and php, my experience with testing uploads or file creation was via actually creating a file during test, verifying its existence, and then erasing this file. When I tried this in C# using Moq, the tests wouldn't fail, but the file wasn't created.

I was missing something, so I found this excellent link on testing file uploads in asp.net http://www.hanselman.com/blog/ABackToBasicsCaseStudyImplementingHTTPFile...

After reading it over, I realized that:
1. The problem was that I was calling SaveAs() from HttpPostedFileBase class, not HttpPostedFile. As an abstract class, this method is not implemented. Moq must implement this method for one. Nice, nice Moq.

2. There is a nice couple of method called Verifiable() and Verify(), and they belong to the Mock object. My using it in the following manner

file1.Setup(f => f.SaveAs(It.IsAny())).Verifiable();

We can later called

file1.Verify();

And this will verify that the method got called. So there is no need for me to implement SaveAs() to test that it is being called.

Bonus aside:
Thinking back, it seems that I have learned many new concepts via scripting languages. I believe it is because the simpler language interface allows one to exercise the features more seemly by not having to think of elaborate setups.

Today I spent many hours troubleshooting the unable to cast Object type X to X . As I said in the previous blog entry, I am starting an asp.net mvc project because I want to TDD this project. So I finished translating the existing project from web forms to asp.net mvc, and now the only thing I have to confirm is that the unit test that I adapted for testing file uploads pass. (By the way, the wonderful page is found here: http://csainty.blogspot.com/2009/01/aspnet-mvc-unit-test-file-upload-wit...)

And it won't work.

I repeated the steps on how to create the mocks and how to test the entry, and it doesn't work. It give me this weird error

unable to cast Object type System.Web.Mvc.Content to System.Web.Mvc.Content

I rubbed my eyes a few times. It looks to me that it is the same. So I try it again. Same result. I recreated, step by step, the test. Same result. I researched a possible bug in NUnit. Nothing. Just in case, I repeated the test using Microsoft's test framework. Same error.

I research the specific bug connecting it to mvc. Nothing relevant. I try just the bug. This time I got a page that said that this error could be triggered by having some repeated URI references. This is potentially possible, so I decide to repeat the experiment in a new project. This time, it works using visual studio's framework. I try it again using Nunit, and it fails. I start to suspect that it is Nunit or that there is something in visual studio's framework that can make it pass. I try a third project, and this time visual studio's frameworks fails too.

So I research this error again. This time, I got this excellent link:
http://www.hanselman.com/blog/FusionLoaderContextsUnableToCastObjectOfTy...

Where Scott Hanselman explains how this error can happen from using two different DLLs. Let me quote(quote()) here:

Suzanne Cook puts it best, emphasis mine:

For example, path matters when determining whether a type is castable to another type. Even if the assemblies containing the types are identical, if they're loaded from different paths, they're considered different assemblies and therefore their types are different. This is one reason why using contexts other than the Load context is risky. You can get into situations where the same assembly is loaded multiple times in the same appdomain (once in the Load context, once in the LoadFrom context, and even several times in neither context), and their corresponding types won't be castable.

So I checked in my project, and yes, this was the problem. Those test passed right away.

I just started working on a new project. As you know, I got agile religion earlier this month, and I am a born-again coder, who wants to test his code as he goes. Also, after doing a few TDD projects, not doing it seems wrong, and it is just not as fun.

So I got a new .Net project, and this time I actually can do it right. I am going to do it right. I set up Moq and NUnit, and off I go to test land. Now All what I have to figure out is how to mock HttpRequest to test an upload method. I research the question. And in most cases, most of the solutions involved Asp.net mvc. I kept trying to find something specific to just plain asp.net, but the information that I got was either very old, or was a tangential mention that in an mvc page about how the solution could also work with regular asp.net pages.

So the pragmatic solution was to move the back end of the project to mvc. Fortunately for me the project only has a couple of pages of code, and translating the behavior from asp.net to mvc was quick. In fact, it seems that it takes a lot less work code to do the same work.

I am not saying that it is not possible to TDD regular asp.net. I am sure it is. But most of the information and resources exist for asp.net mvc, so, if it is possible, it makes a lot more sense to adopt it if one wants to TDD a asp.net project.

After doing some research, it seems that there is no clear way to unit test asp .net WebForms.

ASP .Net web forms behavior collides with the current testing principles. The big one being that you only test public methods. Well, it seems that most Web Form pages don't have ANY public methods, making it impossible to test following the unit test principle. For those developers that want to do testing, it means that they have to expose the different private methods that they are using as public methods, breaking a big principle in OOD, which is that public methods are the interface to the object. So the developer who wants to unit test their code either breaks the principle of not testing privates or breaks the OOD principle of exposing as little interface as possible.

So the solutions that I have found either involves some complex code bending to allow for the testing of private methods, doing weird practices such as exposing private methods as public.

The other big solution seems to be to move to the MVC framework. Ideal solution for new projects if one has the time to learn the framework, but won't help that much if one has to work with legacy code.

The one idea that popped into my mind as I was writing this is that maybe it is possible to mvc-ize a bit the code. If every interaction of the page has to rely on objects, then we can test those objects. This seems to have some limitation in that separating database interactions may be difficult, impossible, or create greater problems that it attempts to solve. But at least it, if used properly, allow for testing of potentially breakable parts of the code.

I will experiment with this idea and see what happens.

You initialize it like this:

var membership = Membership.Providers["orclmembershipProvider"];
var validated = membership.ValidateUser(user, password);

A bit different than MS's provider. The name of the provider that you give is the one that you put in the web.config tags.

When trying to install SQL Server 2008, I was running in an error message saying that .NET 3.5 wasn't installed and the installation couldn't go on. Of course, .NET 3.5 WAS installed.

I had run into this problem before, I was going blog about it, but I forgot. :S

So here I am, blogging about it now. I remembered that a file was erased or overwritten. But I couldn't remember exactly what.

The solution is to download dotnetfx35.exe and replace this file with the one that SQL Server 2008 ships with. I couldn't find the original post where I saw this solution, but I found this link that talks about it:

http://www.eggheadcafe.com/software/aspnet/33935610/net-35-installation-...

Answer from stackoverflow

It's a lot easier if you can upgrade to standard/pro and install ReSharper - it's got a really nice integrated test runner. However, if you can't do that...

* Launch the NUnit GUI
* Load the relevant tests, from debug builds
* In Visual Studio, attach to the NUnit GUI process
* Set your breakpoints
* Launch the relevant test

It's a bit of a pain, but when you've got the shortcut keys memorised (Alt-P is attach to process, IIRC - but check) it's not too bad