James Skemp's StrivingLife

After converting one Web site over to ASP.NET MVC 2 yesterday, I ported my second one today.

The first Web site was originally just a bunch of static HTML pages, so it was fairly easy to move over. This one, LogParserPlus.com, gets all of its data from a collection of XML files. Using LINQ to XML the files are read and parsed out to the page, using a Repeater control.

Unfortunately, when I was creating the site I had run into issues with that Repeater control not acting as I would have liked. Luckily, now that I've moved to ASP.NET MVC those issues have been eliminated.

While the addresses changed for every page save the home page (and the static content), the Web.config was more than able to handle these via some httpRedirect elements.

<configuration>
	<location path="LogParserExpressions.aspx">
		<system.webServer>
			<httpRedirect enabled="true" destination="/Expressions" exactDestination="true" childOnly="true" httpResponseStatus="Permanent"/>
		</system.webServer>
	</location>
</configuration>

Memory usage didn't jump as much as for the static site, but there was still an increase from approximately 14 K (with all pages visited) to a little under 29 K (again with all pages visited).

On the bright side, it's highly likely that I'll now add additional functionality to the site. However, I believe I'll need to tweak the data access classes a bit before I go too far down that path.

Overall, I'm happy to be able to move away from Web Forms for this site.

On Saturday (when I'm actually writing this, but I can't have 3 posts on one day, after my posting history the last handful of months) I finally ported a Web site over to ASP.NET MVC.

The existing Web site was for a client who just needs a simple, static, Web site, with a half dozen areas for content. However, if they were given the ability to directly post content to the site - news, specials, etcetera - I believe they might. There's also a weekly update that I perform that I wanted to simplify - not that it takes much time now - but that I didn't really do in this port, but now at least can.

There were perhaps 6 or 7 static HTML files, each of which, save one, was in its own sub-directory. On IIS 7.5, the application pool serving the site used approximately 6188 K of memory. Approximately. I used a mix of Visual Studio 2008 and Notepad to update the site, with Visual Studio 2010 being swapped in for the former the day after the final release. FTP was used to move the changed files to the production server.

I used Visual Studio 2010 to create the new site, and the Web publish functionality to, at the moment, publish it locally for FTPing it to the server. This might change, or I might just push the one View and two or four files that I need to push. I'll probably see what happens when I make that update.

Memory usage on the server for the application pool is now approximately 22348 K, with it jumping below that every so often.

For converting the static site over, it wasn't all that bad. I did have some repository cleanup to do as well, so I believe it took me just short of 2 hours, including some time researching on whether I could redirect a request to another Web site entirely using routing. I seem to recall Scott Hanselman had mentioned this in one of his videos, but it may have just been on redirecting to a Web forms page instead.

Overall, I'm pretty happy with the move, although now that I know memory usage jumped 16 M with ASP.NET MVC 2 being used (without any login functionality, by the way), I'm not sure I would have switched this particular site over so quickly. But there's only two others that I could have moved over, and one is going to be a pain, and the other is going to involve a level of complexity that this one did not.

I've known since October that I really wanted to work almost exclusively in ASP.NET MVC for the Web; I'm glad I'm finally able to start moving in that direction.

I'd really like to implement membership providers in my Web applications, but just don't have the user-base that requires SQL Server (Express), nor the memory on my production server.

Having looked at SQLite before, I figured it would be exactly what I'd need, without going to the alternative of XML.

After some research I found Roger Martin's SQLite Membership, Role, and Profile Providers, and finally decided yesterday to implement these on a dummy MVC site.

However, when attempting to add this to my MVC site I kept running into issues, the last of which was an "Unable to open the database file."

The first issue was with the type declared in the examples on the page above; TechInfoSystems.Data.SQLiteProvider should be removed completely, as he suggests just adding the three classes to your site.

The second and last issue was that pesky database issue. At first I didn't think the app_data directory was getting pushed over, so I verified that I was pushing that as part of the Publish process (how they recommend you push a MVC site to production).

Upon further review it looks like the App_Data directory was placed inside the Bin directory. Google didn't help me much on whether that was the expected behavior, but it consistently did that. I added a ton of permissions to NETWORK SERVICE on the bin\app_data directory, but still the same pesky error.

So I commented out the membership, profile, and role items completely from web.config and added the following code to the Index view.

<%= AppDomain.CurrentDomain.GetData("DataDirectory").ToString() %>

Lo and behold, it was looking for it in the root of the site, exactly where I was expecting the App_Data directory to publish to.

Move the App_Data folder and sure enough, the site works (after uncommenting the Web.config provider information, of course) and I'm able to create a new user.

So, why does the publish process require me to move the App_Data directory?

The fix

In order to get the database pushing correctly I changed Copy to Output from Do not copy to Copy always. However, what really needed to happen was the Build Action needed to be changed to Content.

An App_Data directory is now created correctly, and the SQLite database is correctly placed in the directory.

Another gotcha

If you want troubles, change the applicationName in the Web.config for all three items. If you do this, you'll run into errors like "Attempt to write a read-only database attempt to write a readonly database" with a line reference suggesting there's an issue with roleManager. Comment that out, or that and membership and profile, and things will seem okay.

The issue is that the applicationName (SQLite ASP.NET Provider) is baked into the sample SQLite database. Durr.