Upgrading to Firefox 3 – and keep your loved extensions

After doing the long awaited upgrade to Firefox 3.0 I realized, that most of extensions would no longer work.

Of course, you might say, they are not compatible with FF3 … that’s true, but does that mean, I have to say goodbye to long trusted fellows? No!

There is a tweak for Firefox, which will allow to keep those extensions:

  • Type about:config into Firefox’s address bar and click the “I’ll be careful, I promise!” button.
  • Right-click anywhere. Choose New>Boolean. Make the name of your new config value extensions.checkCompatibility and set it to false.
  • Make another new boolean pair called extensions.checkUpdateSecurity and set the value to false.
  • Restart Firefox.

Well, this doesn’t make all extensions available in FF3, but at least you can get extensions to work which have been disabled because of the newly introduced security features of FF3.

Make that personal!

Even though I always used to stick with workstion-os to do my developemtn, some of my development-machines are Windows 2003 servers by now. And as a good server I don’t run SQL-Server Express Edition, instead I run a real SQL-Server.

OK – that being said, I recently wanted to create a simple ASP.Net 2.0 application, which would take advantage of the WebPart-Feature of ASP.Net 2.0. But not only placing WebParts in the code on the page, I also wanted to be able to edit settings of those WebParts from within the browser, and do some other cool stuff.

So I turned Personalization=on of my WebPartManager and for this great trust I put into ASP.Net – all I get in return is a lousy error, stating that something went wrong while access the database for my ASP.Net Settings! That is a real bummer! But luckly the page was already giving some hints: maybe I don’t have SQL-Server Express Edition installed on my machine.

After some irritation – since I do have a SQL-Server, but just not the EE (Express Edition) – I finally figured it out (with some great help from a colleague).

So ASP.Net want’s to create a MDF-file in tha App_Data directory of my web-application and then access that newly create database. But this doesn’t seem to work, when you have something else than the EE installed. So you have to tweak ASP.Net a little to get things done.

First of all, create you own custom ASP.Net Settings DB using aspnet_regsql.exe from the current framework directory (e.g. C:\Windows\Microsoft.Net\Framework\v2.0.57[something]). This will bring up a little wizard, which will guide you through the next steps.

Now you have to point your application to the newly created database. A global connectionstring tells the web-application to look for a local database. To change this behavior, you first have to remove the globally set connectionstring, by adding to your web.config a remove element, and then re-adding a new connectionstring, pointing to your custom database. So the web.config section for connectionsstrings could look like this:

<connectionStrings>
<remove name="LocalSqlServer"/>
<add name="LocalSqlServer" connectionString="Data
Source=MyServer;Initial Catalog=aspnetdb;Integrated Security=True;"/>
</connectionStrings>

This should solve any problems.

What is thy configuration?

Well, if you have to deal with a whole bunch of assemblies, you might ask yourself: “is this debug or release compiled”?

Fortunately there is a way to tell: using ILDASM or Reflector you can inspect the compiled assembly. If the assembly is debug-compiled, you will find a AssemblyConfigurationAttribute which will tell you whether it’s compiled debug or not.

Fighting the Shell

Today was a really bad-hair-day! After installing some updates last night, my main (and beloved!) dev-machine was just refusing to startup. I would get the logon-screen and then enter my credentials. That would pretty much sum it up – nothing more was going on!

So I ran through all stages … astonishment, disbelieve and finally denial! But even this last resort didn’t provide any help.

OK – so I tried the safe-mode of Windows XP – just to realize the user experience was just as bad.

So after a couple of hours of disbelive and denial I finally got back on my feet …

… even though I would only see my nice pitch-black-desktop-wallpaper I could at least still fire up the task-manager. So I started regedit and browsed the registry. Maybe there is a key like DeactivateStartup. And there it was: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon would have a string called shell – which was in my case empty!

Go ahead, m-a-k-e m-y d-a-y!