SqlMembershipProvider requires a database schema compatible with schema version 1

Whilst recently working with the ASP.Net Membership tools, I decided to script a copy of an existing database with the same Schema. This, I thought, would save a bit of time and get me working quickly. Unfortunately my application experienced the following error when calling the Membership.ValidateUser() method:

System.Configuration.Provider.ProviderException: The 'System.Web.Security.SqlMembershipProvider' requires a database schema compatible with schema version '1'. However, the current database schema is not compatible with this version. You may need to either install a compatible schema with aspnet_regsql.exe (available in the framework installation directory), or upgrade the provider to a newer version.

After a bit of research, I found the following blog post Schema Changes in the latest ASP.NET V2.0 bits which seemed to fit with what I was doing. Unfortunately running the aspnet_regsql.exe tool with the option to "Configure SQL Server for application services" didn't fix it for me.

After reading this forum post I looked (quite rightly) into the aspnet_SchemaVersions table. Sure enough the data was empty so I ran the tool trying various configurations detailed on the msdn page.

Using the visual studio command prompt, I ran the following command. This sets up the membership, role provider, and profile tables on a database called My_Membership located at localhost using integrated credentials:

aspnet_regsql.exe -E -S localhost -A mrp -d My_Membership

This successfully populated the data as expected. Unfortunately this didn't resolve my issue, I was still getting the exact same error!

After taking a step back and assessing what I had changed, I realised that the only actual difference was the application name (specified in the web config). With this in mind I was able to check through the database and noticed that there was an aspnet_Applications table with the old application name in (but not my new version). After adding in my new application name it all worked fine... Phew!

Typically, once I solved it I stumbled across this scott gu blog entry Always set the "applicationName" property when configuring ASP.NET 2.0 Membership and other Providers which goes through pretty much the same issue. If only I had seen that first.

In summary. If you get this error, check that the application name matches an entry in the aspnet_Applications table. Or better still, run through the proper setup steps...

Web Deployment Project - Post Build Events

In my current setup, I have a few web deployment projects which I use to easily compile my ascx user controls for shared use within other projects. With this setup I have cascading references to core web controls projects, to more specifically used web controls projects up the references chain.

With each project comes a standard assembly for the code behind, and an assembly which contains the compiled ascx information. Note: I am using the 'Merge all control outputs to a single assembly' option within the web deployment project property pages.

To save me having to include all of the projects within my main visual studio solution, I copy the compiled assemblies for each of these projects into a shared dependencies folder which can be referenced by many of my web applications. It was getting a bit of a pain to copy the files across to the dependencies folder each time I wanted to roll out a change, so I wanted to find a way to automate the process.

Deployment Projects Post Build Tasks
Within the web deployment projects, you can specify tasks to be run after build, these can include all of the macros from the standard post build tasks (see Web Application Project->Properties->Build Events->Edit Post Build->Macros >>) plus some addition tasks specific to the web deployment projects.

It is well documented that you can copy the compiled website output from the deployment project to another location, however I didn't want the whole website, I needed the merged assembly only.

Using naming conventions, I set the merged assembly to match the parent assembly name but with a '.compiled' addition e.g. 'myWebAssembly.dll' for the main project and 'myWebAssembly.Compiled.dll' for the web deployment project output.

With this in mind, I was able to put together a quick rule to identify the assemblies I wanted to copy using wilcards.

<Target Name="AfterBuild">
<ItemGroup>
<MySourceFiles Include="$(OutputPath)\**\*myWebAssembly*.dll"/>
</ItemGroup>

<Copy SourceFiles="@(MySourceFiles)" DestinationFiles="@(MySourceFiles->'..\Dependencies\%(Filename)%(Extension)')" />
</Target>

Minify JavaScript and CSS files
Within my compiled web controls projects, many of the script and CSS files used are added as embedded resources. One of the problems with this was that I wanted to minify the files when used as a dependency, but keep the originals, comments included, for the project itself. Luckily I found this great blog entry on automatically compressing embedded resources that goes through how to minify the embedded resource files and replace the originals within the assembly itself.

Note: To view the project file, unload your current web application project, then right click and select edit [myproject].csproj

<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" />
<PropertyGroup>
<ResGenDependsOn>
MinifyJavaScript;
$(ResGenDependsOn)
</ResGenDependsOn>
</PropertyGroup>
<Target Name="MinifyJavaScript" Condition=" '$(ConfigurationName)'=='Release' ">
<Copy SourceFiles="@(EmbeddedResource)" DestinationFolder="$(IntermediateOutputPath)" Condition="'%(Extension)'=='.js'">
<Output TaskParameter="DestinationFiles" ItemName="EmbeddedJavaScriptResource" />
</Copy>
<AjaxMin JSSourceFiles="@(EmbeddedJavaScriptResource)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".js" CssSourceFiles="@(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".css" JSLocalRenaming="CrunchAll" />
<ItemGroup>
<EmbeddedResource Remove="@(EmbeddedResource)" Condition="'%(Extension)'=='.js'" />
<EmbeddedResource Include="@(EmbeddedJavaScriptResource)" />
<FileWrites Include="@(EmbeddedJavaScriptResource)" />
</ItemGroup>
</Target>

Unfortunately this step seemed to be ignored when building through the web deployment project. I got around this by creating separate post build tasks, one for the web application project, and one for the web deployment project. I changed the web deployment project to only be responsible for the merged assembly using the naming convention above:

<Target Name="AfterBuild">
<ItemGroup>
<MySourceFiles Include="$(OutputPath)\**\*myWebAssembly.Compiled*.dll"/>
</ItemGroup>

<Copy SourceFiles="@(MySourceFiles)"
DestinationFiles="@(MySourceFiles->'..\Dependencies\%(Filename)%(Extension)')" />
</Target>

Post Build Tasks
Once I had updated the after build task above to only target the merged assembly, I then needed a way to copy the assembly from the main web project, including the minified embedded resources.

I added the following post build task to the main web application project through (Web Application Project->Properties->Build Events->Edit Post Build)

COPY $(TargetPath) ..\..\Dependencies\$(TargetFileName) /Y

This copies the assembly built for the current project into the same dependencies folder, and is fired when building the web deployment project (through the build dependencies).

Conclusion
In the end, my projects are building the assemblies, minifying the JavaScript and CSS, and copying to the dependencies folder ready to be referenced by my other projects. Just a few less things to worry about, which is always good in my book.

Further Reading
MS Build Task Reference
VS 2005 Web Deployment Projects
FAQ in ASP.NET Setup & Deployment
Web Deployment Projects: copy build output to a network share
Minify JavaScript and CSS files as Embedded Resources