Writing to the Asp.Net Bin Directory

I have a question for those of you who host a blog with a hosting provider such as WebHost4Life. Do you make sure to remove write access for the ASPNET user to the bin directory? If so, would you be willing to enable write access for an installation process?

The reason I ask is that I’ve created a proof of concept for a potential nearly no-touch upgrade tool for upgrading .TEXT to Subtext. This particular tool is geared towards those who have .TEXT hosted with 3rd party hosting, although even those who host their own server may want to take advantage of it.

The way it works is that you simply drop a single upgrader assembly into the bin directory of an existing .TEXT installation. You also drop an UpgradeToSubtext.aspx file in your admin directory (This provides a bit of safety so that only an admin can initiate the upgrade process).

Afterwards, you simply point your browser to Admin/UpgradeToSubtext.aspx which initiates the upgrade proces.

The upgrad tool finds the connection string in the existing web.config and displays a message with the actions it is about to take. After you hit the upgrade button, it backs up important .TEXT files, unzips an embedded zip file which contains all the binaries and content files for Subtext. It also runs an embedded sql script to create all new subtext tables and stored procedures and copies your .TEXT data over. It doesn’t modify any existing tables so it is possible to rollback in case something goes wrong. Finally, it overwrites the web.config file with a Subtext web.config file, making sure to set the connection string properly.

It’s a very nice and automated procedure, but it has a key flaw. It requires write access to your bin directory.

An alternate approach that avoids writing to the bin directory is to have the user manually deploy all the Subtext binaries to the bin directory. The upgrade process would run the same, but it would only need write access to the web directory to deploy the various content files. Giving the ASPNET user write access to the web directory is not an unreasonable request since the gallery feature of .TEXT did create folders and require write access.

If you are considering upgrading from .TEXT to Subtext, or if you just have an opinion, please chime in.

Comments

8 responses

Scott Williams • October 31st, 2005
I would have used this several months ago when I upgraded. I don't mind temporarily granting write access, but I would put a big red notice reminding me to remove that privilege when the install is done.

The biggest hurdle I had upgrading was that all of my skin's aspx & ascx files were still pointing to .Text namespaces for references.

Haacked • October 31st, 2005
Yeah, I plan to make rewriting the namespaces for custom skins part of the installation process.

Jason Kemp • October 31st, 2005
I don't mind giving it write access at all if it means an automagic conversion. The less I have to do, the better.

Steve Harman • November 1st, 2005
I don't think that granting the ASPNET worker process *temporary* write access to the /bin/ directory for the purpose of a One-Touch-Upgrade to subText is too much to ask.

I guess my only question is, what happens to any old dotText files that aren't over written by the new subText files? i.e.- a file that used to be in dotText, but is renamed in (or no longer a part of) subText? Or a file that was added to a custom implementation of dotText? Are these files simply abandoned? I'm not sure if the _right thing to do_ is to 1) first delete all the files and folders (except the Images directory) and then unpack subText, or 2) just unpack over the existing dotText files. There are pros and cons to either case I suppose, so just something to think about.

Haacked • November 1st, 2005
Depends how much time I have. ;)

Well for custom skins, I actually want to back up the .TEXT version and modify those so they work in Subtext by simply updating the namespaces we recognize as being .TEXT. That should work in 99% of the cases.

As for other old .TEXT file, we can back them up and delete them. But we don't want to delete custom files. This could take a bit of bookkeeping.

Phil

Matt Elli • November 2nd, 2005
Just a thought - you could put all of the code in the .aspx page, rather than using code behinds and stuff. Messy, but it should work without write access...

David Gero • December 9th, 2007
You don't need write access to /bin
Instead, put the source code to your upgrade assembly somewhere that's normally writable, like /Admin/Src/upgrade.cs
Then, in your /Admin/UpgradeToSubtext.aspx file, add the following to your @Page line:
src="/Admin/Src/upgrade.cs"
When UpgradeToSubtext.aspx is accessed, ASP.NET will automagically compile upgrade.cs and write upgrade.dll to the /bin directory.

Bunmi Akin • December 16th, 2007
hello phil - i ran into this blog entry of yours. i've been on .text for several years now. but it's crashing on me now. i was hoping to just upgrade to subtext. the UpgradeToSubtext.aspx file you refer to up here, is that for real? where can i get it? what do you advice?
thanks a lot!
Bunmi.