SubSonic on GoDaddy Shared Hosting

by Donn Felker 9. September 2007 21:52

subsonic_logo I was trying to get SubSonic to run on a Free Hosting Environment (on GoDaddy) but unfortunately I kept getting a SecurityException when the code would attempt to save an entity. The code looked like this:

faq.Save(); // Saves a faq item to the database. 

This code would save the new FAQ entity to the database. Unfortunately this code would throw an exception. The reason the code threw an exception is because in SubSonic, the Utility.cs file trys to write to the Trace listeners. The Trace listeners have a SecurityAction that demands a security permission. On GoDaddy, they lock down this access. Why? Who knows. They're hosters, they do what they do. GoDaddy usually has everything locked down to a medium trust environment.

The documentation states that you can turn off the trace by setting a flag called "enableTrace" to false, BUT... because this doesn't work because the SecurityAction Demand walks the call stack right when its referenced in code at runtime. Since the flag is being checked in the calling code, the security action is being checked in the stack when the class is called.

This has been addressed in the SubSonic forums and it looks like it will be fixed soon. Here's how to get around it for now.

Open the source for the SubSonic project. Go into the AbstractRecord.cs and comment out any line that has the following call:

Utility.WriteTrace("...");

From my finds, those line numbers are:

  • 901
  • 948
  • 951
  • 957
  • 962
  • 995
  • 1002

Comment all of those lines out, and then recompile the SubSonic project.

Then in your project, delete your SubSonic.dll reference, and now reference the new SubSonic.dll that you just built. This DLL will not have the call that writes to the trace.

This will avoid the Security call that eventually throws the exception.
The .Save() call will now succeed.

Good luck. :)

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

ASP.NET | Code Generation

CodeSmith Screencast

by Donn Felker 5. September 2007 09:19

CodeSmithLogoI recently finished a screen cast that demonstrates the use of Code Smith to create files based upon a database schema.

The Haps

In this screen cast I make a connection to the database, loop through each table in the database create a file based upon the table information. The file is exported to a directory (such as c:\temp). The files are named with the following nomenclature.

TableName.txt

Therefore, if we have a table by the name of "Customers" we will have a file in the c:\temp directory with the name of "TableName.txt".

Inside of the table file I have the names of the columns in the database.

This screen cast will introduce the Database Schema object as well as the process for registering templates and setting template properties at run time.

Click the image below or this link to view the screen cast.

CodeSmithScreenCastThumb

Downloads

CodeSmithScreenCastFiles.zip (1.17 KB)

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | Code Generation | Screencasts

.NET Scaffolding

by Donn Felker 20. June 2007 20:19

Jeremy D. Miller has a great post on keeping source code where it belongs. The thought process behind this is that code should be where YOU would assume it would be. If its data access code, it should be in a project/namespace that is something like Data Access or DAL or Data or something that represents the lower layer of the architecture. If its the business rules/tasks the files should be in a project called Business Rules, or BLL, or Tasks, or something similar. It makes sense, just think about this -- if you walk into a business and are given a project that was created by another developer and you're getting a ADO.NET Exception, you'd expect to find the code Data Access code in a Data Access layer, NOT in the code behind. I should not have to hunt down where you put your data access code.

We're talking about basic separation of concerns. The thing is, many developers lack these concepts because they're under the assumption of "I can write this the correct way, and it will take me 2 weeks, or I can do it quickly and it will take me 2 days." This may not matter when the application is running for a few months, but when you are asked to change the data provider from SQL Server to Oracle, or remove the web service calls and replace them with RPC calls, you're going to find yourself in a world of hurt because you didn't set everything up correctly. At this point they have amounted a large amount of Technical Debt.

He also noted that a large number of people were now using Ruby On Rails (RoR) as their development platform and I won't deny that I also believe that Ruby/Rails is huge right now. Tons of shops are running RoR and even Martin Fowler said on Hansel Minutes that ThoughtWorks was doing about 40% (or more) of their business with Ruby. The key point Jeremy brought up is that "RoR forces web developers into a bit of a straight jacket, but that's a good thing in a way." I completely agree. RoR enforces a consistent source code tree layout which allows for developers to easily find there way around a project. "Developer A" can create a project with RoR and then "Developer B" can come along and take a look at it and be familiar with the code layout and structure. The RoR community has agreed that this is the basic way to organize a project and it seems to be working for them.

So what about .NET? Enter Tree Surgeon. Right now, its a stand alone application, but in its near future it should be implemented as a template in Visual Studio 2005/2008. So what is it? It's a application that will create that straight jacket that Jeremy spoke of. It gives the developer a basic set up of layers, unit tests, code coverage and build script. It builds the entire source code directory and allows you to build on top of it. The source code layout follows a white paper written by Mike Roberts. I've been using it for quite awhile and I'm one of the developers on the project. I recently updated the source to allow creation of Visual Studio 2005 projects. Please note, this is only on the source and has not been reflected on the production release. Download the source, run it and then choose a application name, and generate the project source directory tree. Open the solution file and your application is ready to go.

The best part is that its easy to integrate existing projects into this format. I've done it quite a few times to allow for easy integration into my clients CI environment.

If you have any requests for Tree Surgeon, please visit the Issue Tracker page and submit and issue.

Enjoy!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

.NET | Code Generation | Continuous Integration | Productivity | TDD | Tools | Visual Studio 2005

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Donn Felker

Senior Consultant
MCTS
ScrumMaster
Agile Practitioner

About Me | Books I Recommend

Gotta Pay The Bills


Tag cloud

    Popular Posts

    RecentComments

    Comment RSS

    Calendar

    <<  December 2008  >>
    MoTuWeThFrSaSu
    24252627282930
    1234567
    891011121314
    15161718192021
    22232425262728
    2930311234

    View posts in large calendar