Visual Studio 2010 installation options

According to www.dictionary.com:

Option: the power or right of choosing.

According to Visual Studio 2010 installer:

I think someone missed something, besides me and the “restart later” option

Why they don’t want us to do unit testing over Sharepoint?

I don’t understand what’s happening. Besides the aberrant idea of havig such a monster without a way to mock it by design (I know, TypeMock supports Sharepoint isolation, but it’s not by design and it’s not free), they just disabled the possibility of doing unit tests over it.

Basically, it seems like Sharepoint runs in .NET framework 3.5 and you can’t change the target of a Visual Studio Test Project to 3.5, it has to be 4.0. So, you are not able to test it.

One more time, I’m moving to NUnit.

Powershell version wtf

In Microsoft’s site, it says:

Windows PowerShell 2.0 is a pre-requisite for installing SharePoint 2010 Products. It will be installed, if necessary, when you run the Microsoft SharePoint Products Preparation Tool. By default, Windows PowerShell is located at the following path: \System32\WindowsPowerShell\v1.0\PowerShell.exe.

Could anyone explain me why 2.0 version is in 1.0 folder?

Why I hate Internet Explorer or the story of the asynchronous combo box that couldn’t fly

I’m working on a project that has some performance issues. One them is one single page that takes more than a minute to show. I analyzed what was going on and the truth was that the page’s size was about 3.5 mb. So, what was making the markup so large? comboboxes. Seventeen comboboxes with about 600 options average (but there was some with 2000 options!).
My first reaction was “Why in the hell they need a combobox with 2000 options? this is a functional failure”. But you know, “it’s what the client wants, it’s too late for chaning it now”.

The first solution we came with was to render only the selected value in the markup and to populate the entire list using ajax when the user clicks/focuses on the combo. The great about it is that the ajax responses could be cached by the server side for reducing the server processing and by the browser, so there’s no need to go find the same items again. Just lovely.
And it worked, and worked fine. Except for Internet Explorer. For some reason, if you change the options collection, the select will close, so the user have to click it again.

Our second approach was to call the populate method when the page loading is complete (aka document.ready). The idea was to have the user filling the form while the combos where loading. And, of course, we could make use of the sweet cache I told before. Well, loading about 9000 options will crash your browser. In this way, it takes more time than the 3.5 mb page! So we moved from adding options using the DOM to use innerHTML, so we can change all the options in one shot. It works perfect in firefox, but for internet explorer… well… This code:

var combo = document.getElementById("combo");
combo.innerHTML = "<option value='1'>Test1</option><option value='2'>Test 2</option>"
alert(combo.innerHTML);

Gives me this:
.
And, of course, it doen’t work. Then, I tried this approach:

var combo = document.getElementById("combo");
var option = new Option();
combo.add(option);
option.outerHTML = "<option value='1'>Test1</option><option value='2'>Test 2</option>"
alert(combo.innerHTML);

And it gives me the same result!! It just doesn’t make sense at all! At least, Microsoft is aware of it… are you kidding me? it was found in the IE 5.5 era and continues broken?

Changing the combobox outerHTML works, but we miss the reference to the previous combo in the DOM and the ASP.NET Validators stop working.

After days of Internet Explorer induced stress we decide that the problem was actually functional, and called the client. He confirmed that there shouldn’t be so many options and that there should be a configuration problem, so we limited the amount of options to 200 and start working on the configuration issues instead.