Uninstalling an MSI that throws an error during uninstall process

I got caught in Catch 22 that I finally solved yesterday.  I'm working on building an MSI package and had installed it on my machine for testing.  When I went to uninstall, I couldn't because of an error in the MSI.

This was a big problem!  I fixed the problem in my MSI, but I couldn't repair or reinstall using the now fixed version because it wanted to remove the old version first.

After hours of searching, I finally found the right command:

msiexec /fv (product code)

/fv forced a reinstall using my new package.  Then, I could uninstall.

ClientScript.RegisterArrayDeclaration doesn't play nice with Upload Panels

Found a new one today!

I had a problem where some javascript arrays were being initialized by ClientScript.RegisterArrayDeclaration on the server side ASP.NET code.  This worked great initially as the array needed to be loaded up during the first call to the page.

However, I got user requests to add more features to the page including adding new elements to the list that that array would populate.  Of course, they don't want screen flicker on the page either, so no full postbacks.  I assumed that by just doing a normal postback, the array registration code would work fine and everything would move forward.

Turns out, if the declaration is part of controls inside of update panels, ClientScript.RegisterArrayDeclaration won't update the array.  It will look to the javascript after the partial postback just as it did before.

It took me a long time to run this down, but in .NET 4, there is a new animal called ScriptManager.RegisterArrayDeclaration that is built to play nice with UpdatePanels.  So, I quickly changed the ClientScript to ScriptMangager, and sweet!  The array would get updated.

But wait, there's more!  Now, the array gets updated but the old data doesn't get rebuilt.  It just builds on top of itself, adding the same elements to the array each postback.  Bad!

So to solve, I added code to set the array to null prior to all the array declaration code:

ScriptManager.RegistlerClientScriptBlock(me.page, me.page.gettype, "code","array = null;",true)

This would clear the array then reload it.

__doPostBack causing Screen Flicker even when set as Asyncpostbacktrigger

Ran into a good one today that made me to start a BLOG.  I run into issues all the time that require fixes.  Sometimes, you can find solutions on the web.  Sometimes, you can't.

I always felt like I should give back to the community that I extract so much from.  So, here's one that I had to reason through with just a little help.

I had a scenario where I needed a button to exist but not allow the user to click it.  The reason is that I needed some javascript to perform a __doPostBack() using that button so that the ASP.NET page would fire its event on post back.  However, I do this in response to some other user actions handled by javascript.  Thus, to prevent the user from clicking the button, I set the visibility property of the button to false.

<asp:button id="someButton" runat="server" visible="false" />

So, my javascript would fire the event correctly.

__doPostBack('someButton',null);

And my ASP.NET page would capture the event correctly.

The problem I ran into though was that even though my button was inside an UpdatePanel, I would still get screen flicker.  I tried adding the button as an Asyncpostbacktrigger as the recommendation of many on-line searches.

<asyncpostbacktrigger controlid="someButton" />

The screen flicker continues.  I'm annoyed at this point.  How could the event be firing, be being captured, be an asyncpostbacktrigger, and still causing screen flicker?

The answer turns out that the UpdatePanel triggers can't "see" a control that has its visibility set to false, most likely because the control never makes it to the page.  Thus, it performs a full postback.

The simple solution?

<asp:button id="someButton" runat="server" visible="true" style="display : none;">

Solved!