Cannot Modify the Needed File

Upon restarting Windows, my StumbleUpon toolbar in Firefox seemed no more.

I went to the StumbleUpon site and tried to reinstall the add-on, but got this error:

StumbleUpon could not be installed because Firefox cannot modify the needed file.

My setup is a bit unusual in that I have a QSoft RAMDisk drive set up on my 4 GB system to utilize the extra 768 MB or so of PAE memory, normally inaccessible to Windows 7. I configured my system to use a folder on this drive, R:, named TEMP as a scratch space, and set up Firefox to use R:\ for its cache.

I discovered, however, that I'd forgotten to create a little script or batch file to create this TEMP folder on the R: drive. This meant that for some programs that might use the system's default temp space, it might fail, the folder R:\TEMP being nonexistent.

To get around this I simply modified my environment variables for TEMP and TMP to reference the root of the RAM drive, R:\. Now the StumbleUpon toolbar add-on installs successfully.

In case you encounter this error, make sure that you have sufficient space available in whatever folder you tell Windows to use as scratch space, and of course that it exists in the first place and is accessible.

iPhones Don't Kill People...

Center Text AND Images Within ASP .NET

I recently integrated the handy AddThis sharing and analytics tool into an ASP .NET site I'm working on.

Whether due to peculiarities of the markup or browser idiosyncrasies, I couldn't get the widget consistently centered. The widget code lives in a div tag, and despite a popular few suggestions, I simply couldn't get things centered horizontally.

Centering text is no big deal; simply applying a CSS style usually does this well enough:


text-align: center;



Images, however, aren't accounted for by this markup. 

I ended up enclosing the widget in a Table control with the HorizontalAlign attribute specified to "Center", and this did the trick.

Centered!

Much easier to allow ASP .NET to handle the grunt work of emitting the necessary markup in this case than messing (directly) with styles.

Assembly must be Strong Signed in order to be marked as a Prerequisite

In the process of trying to update and rebuild a C# project utilizing Microsoft's Enterprise Library, I inexplicably got the error "Microsoft.Practices.EnterpriseLibrary.Data.dll must be strong signed in order to be marked as a prerequisite." 

I hadn't touched this project in a while, in fact I may've last built it on a different PC, so I guess if I had strong signed the Enterprise Library dll, the new system had no idea. Also, I'd installed .NET 4 recently, so maybe this had something to do with this earlier version of the Enterprise LIbrary (my project implements 4.1 whereas the latest version is 5). I guess security in the .NET 3.5 framework isn't up to snuff as far as .NET 4 is concerned.

Anyway, it appeared I had no choice but to use the sn.exe utility and create a key pair and do all the stuff Microsoft suggests in their painfully tedious article on how to sign an assembly with a strong name. Luckily after some digging I found Signer, a command-line utility which simplifies the process of strongly signing one or more assemblies which VS 2008 may be complaining about.

I'm referencing this from the perspective of a Windows 7 64-bit system, so note that the following may vary if you're using 32-bit. 

In order to do it's thing, Signer requires access to some other command line utilities, most of which live in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\. A few, however, including ilasm.exe and fusion.dll, live elsewhere (in my case, these were hanging out in C:\Windows\Microsoft.NET\Framework64\v4.0.30319).

I decided to copy Signer.EXE to the above SDK path, and copy the latest versions of the above files to that same path, so that when I execute Signer.EXE, it'll be able to easily find all the external EXE and DLL files in the same directory.

First of all, though, I needed to use MIcrosoft's sn utility to create an .snk key file in my SDK folder from a command prompt as follows:

sn.exe -k 1024 myProjectKeyName.snk

This instructs sn to produce a key file named myProjectKeyName.snk which I really don't care about for anything other than getting my project to build again. Thus, I chose an arbitrary key file name and value of 1024-bit key length.

I then executed Signer as follows in the same folder:

signer.exe -k myProjectKeyName.snk -outdir C:\myProject\myProjectLibrary -a C:\myProject\myProjectLibrary\*.dll

Here I'm instructing Signer to take the key I just created and strongly sign all .DLL files in my project's library folder. After this, I did a Clean Build on my project, then a Build, and thank goodness, the build completed successfully!
 

Even though Visual Studio 2008 can't build .NET 4 applications, I guess nevertheless since I have the .NET 4 framework installed, it's mandated that all assemblies shall be strong signed, or the project using them shall not build. Whatever, I'm just happy to have gotten past this issue.