I recently posted about an update to my WebPageSecurity module project to the newly named SecuritySwitch. One of the best ways to ramp up coding on the project again is to get it into a public code repository.

Get with Git?

I thought about using Git on GitHub, but I want to get moving on this and that would not be the case if I had to fumble through learning Git now. Although, I do really like the concept of a distributed version control system (DVCS). Instead, I will stick with Subversion (SVN) for now.

Google Code

That lands the project in the capable arms of Google Code, which I find to be a very nice new home for SecuritySwitch. I will likely have a dedicated page here on GeekFreeq for SecuritySwitch that refers visitors to the project on Google Code, and/or I will just pipe updates from the project site here via RSS.

Anyway, this is the first stage of a “grown-up” SecuritySwitch.

After a bit of a struggle supporting my WebPageSecurity module on Code Project, I’ve decided to put some quality effort into the project in the very near future. One of the first things that needed attention was the name.

What’s in a Name?

Could I have named it something more generic all those years ago? Perhaps, but not likely. After a few minutes of running through some of the key nouns and verbs that describe the project’s purpose, it will now be known as SecuritySwitch.

Educational Value vs. Quality Functionality

Another change to the project will be the maintenance of the dual source code languages. Since I originally started the module, a distinct project for C# and VB.NET have been maintained. While this was great for the educational aspect of the article and accompanying code, it is not ideal for a quality “product”.

After some consideration, I decided to drop the VB.NET version of the source code in favor of a single project written in C#. An immediate benefit to the community of this decision is faster releases.

What’s Next?

All of this change should be balanced with something to make it all worth while. I intend on stopping development on the 2.x version of the module for .NET 1.1 where it is now. Of course, I’ll fix any bugs, but no new features will likely be added. Version 3.x for .NET 2.0 will continue until version 4.0. That’s when I will add some of the new features in the queue and enable full support for ASP.NET MVC as well.

Keep checking back for more progress on this project.

ASP.NET Login Control

So, you’ve set the timeout value for forms authentication to a fairly large value, yet checking the “remember me” check box on the Login control still does not persist your users’ authentication, even after a fairly short period of inactivity.

<system.web>
    ...
    <authentication mode="Forms">
        <forms timeout="10080"/>
    </authentication>
    ...
</system.web>

Don’t spend hours trying to figure out why this, seemingly, basic functionality doesn’t perform as it should. The solution to this problem is very simple, albeit somewhat obscure.

Encryption is the Key

To make the “remember me” check box actually obey your users when they check it, you need to ensure that a static machine key is added to your website’s web.config file. That’s it! Really.

<system.web>
    ...
    <machineKey
        validationKey="xxxxxxxxx"
        decryptionKey="xxx"
        validation="SHA1" decryption="AES"/>
    ...
</system.web>

Generate Random Keys

Generate your own keys by using one of the machineKey generator websites available. After using a generator, copy and paste the machineKey element inside the system.web element of your web.config.

The “remember me” option for authentication should start working as expected.

Why this Works

When a user authenticates on an ASP.NET website with forms authentication enabled, an authentication ticket is generated for that user. This ticket is then stored inside a cookie in the user’s browser. The cookie’s purpose is to allow the forms authentication system to recognize subsequent requests by the same user as valid/authenticated.

Of course, this functionality works without issue even before the solution above. When a user leaves the “remember me” box unchecked, a session cookie is stored in their browser. Checking that box, sends a persistent cookie back to the browser instead. This persistent cookie is set to expire based on the timeout value mentioned earlier (i.e. it expires approximately timeout minutes from the current date/time). The persistent cookie is also created without issue. A quick look at your cookies during a test should prove this.

So, if the persistent cookie is getting created properly, why are users being forced to login again after only short periods of inactivity? Well, the authentication ticket is encrypted before being sent to the browser as a cookie. This is done to secure the details of the ticket and prevent tampering. However, the ticket must be decrypted by the forms authentication system on each request that follows.

Process Recycling

When the ASP.NET process recycles, the website’s validation and decryption keys may be randomly re-generated. In fact, the default behavior is to auto-generated these keys per application. If the keys are changed, those tickets cannot be decrypted. When the forms authentication system fails to decrypt a ticket from the user’s cookie, it sends them along to the login page for validation. No amount of checking the “remember me” box will help this situation; specifying your own keys in web.config will.

Causes of Process Recycling

There are a number of causes for the ASP.NET process getting recycled. Here just a few.

• IIS determines certain conditions were met
• any change in the bin directory of the website
• changes to the physical path of the virtual application or website
• a sub-directory of the website is deleted
• changes to Global.asax, web.config, or machine.config
• policy changes
• the count threshold of re-compilations is exceeded (numRecompilesBeforeAppRestart on the compilation element)

If your website is hosted on a shared server, odds are the process for your application will get recycled more often than on a dedicated server. Hosts set the thresholds for recycling pretty low for shared hosing servers to account for poor programming.

Final Recommendations

I almost always recommend that one of the first things a developer does with a new ASP.NET website is generate a random machineKey and add to the web.config. This will likely save you many headaches in the future. By the way, this step is absolutely necessary for Web farms/gardens.

Interfacing Your Demons

Like many version control systems, SVN utilizes a command-line interface (CLI) to interact with users. Some users frown upon the command-line; especially, Windows users. However, I want to point out how necessary it is that these tools use the command-line.

After you use a version control system for a good length of time, you should notice that there are routines you follow over and over again. Perhaps you lock certain files before editing them to prevent conflicts with other potential editors on your team. Maybe you always commit your changes when you build a project for release, or when you shut down your computer for the evening. The point is, these are things that can be automated with small scripts through build events or even Windows Task Scheduler. Having a command-line tool is essential to such automation.

On the other hand, there are many times you will want to issue commands to SVN on-demand. A nice graphical user interface can make things much easier and faster for those tasks. Enter TortoiseSVN.

TortoiseSVN and the Shell

I like to think that the tortoise stands for something meaningful. Granted SVN was created as an alternative to CVS, which had TortoiseCVS. For me, it’s all about the shell!

TortoiseSVN Context Menu

TortoiseSVN integrates with the Windows shell. That means a lot in the way of usability. When you right-click a file from anywhere in Windows, you will see contextual items on the menu for TortoiseSVN commands. Personally, I think this gives much more value to the program than those that just mingle with integrated development environments (IDEs). I use SVN to control more than just source code. In fact, I consider my other project assets to be just as important (i.e. original design images, documentation, research, etc.). Integration with the shell means I can open Windows Explorer and start managing my files with TortoiseSVN.

Repositories

Repositories are where your files, and their many versions, are stored. There are many theories on how to organize your repositories, from creating one for each project to creating one for everything. I prefer creating a repository for each solution I am working on. That is, I create a repository for every application, website, or stand-alone library that I work on. My reasoning stems from the fact that I may need to invite new team members into the development process for a given application or website, and I want to be able to ensure they only have access to what they need. It also makes it very easy to move a repository to a remote, shared location in the future.

I do, however, store all of my repositories in a single directory on the computer chosen to host them. This makes for a very clean and trivial backup structure. I can easily backup all of my repositories by simply pointing to this root directory. I name mine, “SVNRepositories”. Aren’t I clever?

Use Templates

As a programmer and architect, I am a huge fan of templates. They make things so much easier. Creating stuff from templates is quicker and less riddled with mistakes. The idea of using templates to create your repositories may seem too trivial to bother with, but it does speed things up and ensures that you stick to a naming convention. Many recommend the following directory structure for repositories.

• SVN Structure
  • branches
  • tags
  • trunk

The trunk is where your primary development line will be maintained. You will commit most of your changes to the trunk. You will most often update your working directory from the trunk (more on this soon). The trunk is the latest official version of your solution. There are conflicting views on exactly how to use the trunk, but this is the most widely accepted usage of it.

Branches are there for you to try new things and to experiment with the solution/project. Create a branch when you do not want to mess up the trunk with possible breaking changes. Branching is most common when a new feature is being developed that will take some time to implement. You would create a branch from the trunk and begin working on the branch; committing and updating to and from the branch instead of the trunk. Once the feature is complete, the branch should be merged back into the trunk and become part of the overall solution.

Note: It is good practice to merge the trunk into a developing branch every so often, so the branch can benefit from any changes made on the trunk.

Tags are ideal for marking milestones for the solution/project. It’s a good idea to “tag” each release of the software, documentation, or the like. This allows you to time travel back to a release at a future point if you need to troubleshoot an issue with that old release, or to revert back to a release if things go awry later. For example, a diet-tracking website I am constantly improving upon will soon be sent to a buddy of mine for his personal use. Each time I send him an update, I will tag that release so I can instruct SVN to find the difference between then and now in order to send him a patch.

Create a directory on your computer that has the 3 sub-directories above in it. The sub-directories should be empty. Name the parent directory as your template structure so that you can find it later. I named mine, “SVN Structure”, and have it in a folder named, “Templates”.

New Repositories

Follow these steps to create a new repository that is consistent with the best practices discussed above.

New Repositories

1. Create a new sub-directory in your SVNRepositories directory. Make sure you give it a meaningful name for the project/solution it will manage.
2. Right-click the new sub-directory, hover your mouse over the TortoiseSVN context menu, and click “Create repository here”.
3. You should see a confirmation message that the repository was successfully created.
4. Navigate to your “SVN Structure” directory template, right-click it, hover your mouse over the TortoiseSVN context menu, and click “Import…”.
5. Enter/select the URL of the new repository you just created. If the repository is on your network, you will use a URL in the form of file:///X:/SVNRepositories/RepositoryName. Otherwise, use a valid Web URL for the remote location.
6. Supply a nice message for the import. I recommend, “Structure import.”
7. Click OK.
8. Enjoy the log displayed that informs you of the successful addition of the 3 directories and click OK.

Feel free to right-click on any folder and choose the “Repo-browser” item from the TortoiseSVN context menu. After entering/selecting the URL to your repository, you should see the new structure eagerly awaiting files to manage.

Working Directories

A working directory is where you make the changes to your files. These are standard directories that have hidden SVN sub-directories tucked away for change tracking and property management. The presence of these hidden directories is what enables the icon overlays and most commands on the TortoiseSVN context menu.

You can have multiple working directories; even for the same repository. In fact, if you are working on the trunk and a branch of your project/solution, you will likely want to have separate working directories, as opposed to switching back and forth between each. Simply, create another directory separate from your current working directory, and checkout the other branch or tag to the new location. Then, you can work in both directories and update/commit to the appropriate trunk/branch/tag for each.

Setting Up in a Clean Working Directory

Consider setting up version control before you begin working on a new project. It will make setup easier, and it will ensure that you can start committing changes immediately.

Setting up in a clean working directory is a cinch! After you have created your repository from the structure template provided earlier, follow these steps.

Checkout

1. Create a new directory where you would like to start working on your project/solution (e.g. C:\My Documents\My Projects\New Project).
2. Right-click the new directory and click “SVN Checkout…”.
3. Enter/select the URL of your new repository.
4. Append “/trunk” to the end of your repository URL (i.e. file:///X:/SVNRepositories/RepositoryName/trunk).
5. Ensure that the checkout directory is set to the one you just right-clicked.
6. Keep the checkout depth set to “Fully recursive”.
7. Make sure the “HEAD revision” is selected.
8. Click OK.
9. Enjoy the success log and click OK.

You now have a working directory all ready to be filled with files. You may notice that the folder icon for your new working directory has a green check overlaying it  (if you do not see it, refresh Windows Explorer until it appears). This indicates that no changes have been made to files in that directory. Considering there are no files, this makes sense.

Setting Up in an Existing Working Directory

If you already began your project and have files inside your working directory, don’t worry. It isn’t too much of a pain to get your working directory synchronized with your new repository.

After you have created your repository from the structure template provided earlier, follow these steps.

Commit

1. Create a new directory, anywhere you’d like, to hold all of your existing project files temporarily. I often just create a temporary folder on my desktop.
2. Move (not copy, move) all the files and folders that are in your existing working directory to the new temporary directory you created in step 1.
3. Your existing working directory should be completely empty now.
4. Right-click the, now empty, working directory and click “SVN Checkout…”.
5. Enter/select the URL of your new repository.
6. Append “/trunk” to the end of your repository URL (i.e. file:///X:/SVNRepositories/RepositoryName/trunk).
7. Ensure that the checkout directory is set to the one you just right-clicked.
8. Keep the checkout depth set to “Fully recursive”.
9. Make sure the “HEAD revision” is selected.
10. Click OK.
11. Enjoy the success log and click OK.
12. Move all of your files and folders back to the working directory from the temporary folder you moved them to in step 2.
13. Feel free to delete the temporary folder after you verify all the files/folders moved over.
14. If you peek inside your working directory now, you should see a blue question mark image overlaying your file and folder icons . This icon indicates that the files/folders are unknown to your repository at this time. In other words, they are not versioned yet. It’s time to fix that!
15. Navigate to the parent directory of your working directory, so you can see the working directory in the list of folders. It should have the green check overlay.
16. Right-click the working directory and click “SVN Commit…”.
17. Enter a nice message for the initial commit. I recommend, “Initial commit”, or similar.
18. Select all the files and folders you want to add to the repository (drag a rectangle around them with your mouse, or Shift/Ctrl click them), right-click one of them, and click “Add”.
19. If there are any files you want to ignore from now on, select them, right-click one, and click “Ignore x items by name”. You may also select a single file and choose to ignore it or all files with the same extension.
20. Finally, click OK to commit the files to your repository.
21. Enjoy the success log and click OK.

Your existing working directory is now under version control!

What Next?

After you have a repository setup and a working directory linked to it, there’s not much more to do except…get to work. Just update your working directory, make changes to your files, and commit the changes back to the repository at the end of the day (or sooner if you feel the need). Of course, there are some minor caveats to keep in mind in your daily use.

Special Actions

Rename

Adding and editing files under version control is a no-brainer. However, there are special considerations for file renaming and moving. If a file is already under version control and you want to rename/move it or delete it, you must use TortoiseSVN to accomplish this in order for it to properly account for the action. Truthfully, you can just delete files and TortoiseSVN will let you mark those files as deleted the next time you issue a commit. The renames/moves are the real trouble-makers if you just make those changes outside of TortoiseSVN.

If you need to rename or move a file, right-click it, and select “Rename…” from the TortoiseSVN context menu. Enter the new name of the file to rename it, or enter the relative path and file name if you want to move it (i.e. SomeSubDirectory\MyFile.txt). Alternatively, you can right-click-drag (drag with the right mouse button) the file to another folder and select “SVN Move versioned item(s) here”.

This will instruct SVN to delete the original file and add a new one with the new name/location. If you rename/move an entire folder, you must commit the changes before editing any files inside that folder. In addition, make absolutely certain that you do not rename, move, or delete a directory that is under version control except via SVN or TortoiseSVN. Doing so, will change those hidden SVN sub-directories and that would be very bad. For all the details on these actions, read the Deleting, Moving and Renaming section of the Daily Use Guide.

Further Reading

I highly recommend that you learn all the capabilities of both SVN and TortoiseSVN. These are great products aimed at helping us stay organized and track revised files. Below is a list of resources I believe are helpful to beginners and seasoned users alike.

• TortoiseSVN – Daily Use Guide – this is a must-read
  • Branching / Tagging
  • Merging
  • Creating and Applying Patches
• TortoiseSVN – Most Forgotten Feature
• TortoiseSVN FAQ
• Version Control with Subversion (free online version) – the official Subversion book

So, why all the past-tense in my explanation above? Well, the Save the Developers website (savethedevelopers.org) now redirects to Microsoft’s website for Internet Explorer 7 and 8 beta. At first, one might assume that Microsoft bought the domain for the website and issued the redirect themselves. However, I’m not so sure about that upon some digging.

A whois query for microsoft.com reveals that the owner of that domain is Microsoft Corporation; no surprise there. However, a whois for savethedevelopers.org (and .com) shows the owner to be Conveyor Group. There is only a month left before the domains expire, so who knows. Maybe they succumbed to the financial power of Microsoft.

Sometimes it’s all just too much!

Integration with the Rest of Your Schema

The default implementation of the ASP.NET providers are not ideal for integrating with the rest of your database schema. By that I mean, if you want to include a foreign key to a user’s ID in a table that you’ve created for your application, you’ll have to play by those default rules. Your foreign key will have to be a unique identifier (SQL Server’s GUID data type).

What if I’ve already defined my entire schema and the User ID I had in mind is an integer?

Write Your Own Providers

Something that I truly appreciate with ASP.NET since version 2 are providers. Being able to customize the implementation details of specific pieces of a well-defined machine is empowering. Unfortunately, for the membership, role and profile providers, your data for each will more than likely be interdependent. For example, you cannot use the default SqlMembershipProvider with a custom role provider that does not link to the aspnet_Users table or use a GUID for the User ID when associating roles to users. If you want to change the data type of the primary keys for some entities, you’ll have to write custom providers for all aspects you wish to use in your application.

It’s also not as simple as just changing the data type from a uniqueidentifier to an int. Ideally, the flexibility to configure the providers to use one of your own existing tables in the database would be more robust than hard-coding several table names into the code. What if the provider uses the correct database provider based on the supplied connection string? How about the option to use dynamic SQL or stored procedures?

These would all be very nice features for a set of ASP.NET providers. Of course, I have a real-world example. My host lets me create MySQL databases for my website. They have MySQL 5 installed, which has the ability to create stored procedures (after a bit of a wait). The only trick here is, stored procedures in MySQL 5 are actually stored in the “mysql” database. This can pose a problem for security in a shared hosting environment. Everyone’s stored procedures are in the same “bucket”! It would be great if I could configure my membership and role providers to use MySQL and build dynamic SQL instead of relying on stored procedures.

They’re Coming

That’s the plan. I am currently writing ASP.NET providers that offer all the benefits mentioned above. When will this project be complete? Who knows with my schedule! I can tell you that I have a couple of big websites that I’m working on that will require MySQL as the backing database. They also require membership and roles support. I guess I’ll be finishing the providers in order to complete those websites. ;-)

Well, I am finally setting out to write the next version of the web page security module. I have quite a list of features requested by its many users. The fact is, I’ve been wanting to write the new version for nearly 2 years now. I have an idea that will make this thing so much more usable that I’m beginning to doubt its efficiency. So, before I begin putting too much effort into it, I will be running some tests, like a responsible programmer.

I suspect the new method I have in mind will be a bit more CPU-intensive. The problem is, I have no idea how much more CPU I can expect the algorithm to use. I’ll see how my tests go, beginning tonight. If the metrics show an acceptable increase in CPU (I’ll have to decide what is acceptable), I will begin coding the new version this week.

Stay tuned.

When trying to communicate across these and other involved systems, it can get a bit crazy. The Web tools are my primary concern. They require authorization granularity that just is not offered via our Active Directory (AD) layout. For example, some of those tools have some users that share a similar AD group and other users that do not. In addition, not all users of an existing group should have access to a given tool. Yet specific collections of users needs access to these tools and I am responsible for granting such access.

An Obvious Solution

The first solution that one may consider is to create new AD groups for the user of the tools. However, the network administrator need not be concerned with these specialized “Web groups” for his routine tasks. He also should not have to worry about granting me permission to create the groups that I continually need, or repeatedly filling requests to create them on my behalf.

When performing audits of the AD entities, the network administrator will have no idea what purpose certain groups fulfill and whether or not they are no longer needed. That is, of course, without constant communication and documentation from me. Likewise, when I absolutely need to add a user to one of the specialized groups in order to grant access to a tool, I cannot be guaranteed quick processing of my request; especially around lunchtime.

A Hybrid Solution

This is where the power of ASP.NET’s custom providers comes into play. To solve the above problems, I devised a hybrid role provider. The new custom provider allows me to see what AD groups a user belongs to and manage my own roles for the website.

I only care about a small subset of all the AD groups, so I mapped them to roles in my database. These mapped roles are not editable via the provider. Therefore, users cannot be added to, or removed from, them since they are virtually a link to the read-only AD groups. I am free, however, to create my own roles in the database and add/remove users to them internally.

The custom role provider handles everything for me. It overrides most of the virtual properties and methods of the base RoleProvider class. It ensures that the provider is not used to modify the AD mapped roles. It also looks up what AD groups a given user belongs to, as well as what users belong to a given group, via LDAP.

Lastly, the custom role provider manages “calculated roles”. Calculated roles are those that are implicit to a user in the website database. These include: instructors, department heads, course coordinators, etc. The presence of one or more records in various tables or the value of a field in a table are ways the calculated roles are determined.

To assist with several aspects of the website’s needs, I also created a custom membership provider that descends from the ActiveDirectoryMembershipProvider class. The main reason for this is to make use of a custom ActiveDirectoryMembershipUser class that contains often needed information about the currently logged in network user.

The Result

With my new custom role provider (and matching membership provider) I get seamless authentication with our Active Directory structure and a very robust hybrid system for authorization. I can create website-specific roles, assign users to those roles, and check users against common AD groups used across the college. Each of these abilities grants me the ease of using the many declarative authorization approaches available to me via ASP.NET. I can configure directories and/or individual pages to authorize users based on their AD group and/or their custom website role.

When completed, I was able to offer the internal users of the website an array of custom tools that are authorized transparently to appropriate individuals. That is some great power allowed by the provider system
in ASP.NET. It was fairly easy to pull off too. I thought out my needs, and with less than a thousand lines of code, I have a complete and robust solution.

The Lesson

Do not accept the lack of a feature as a limitation; especially with regards to the .NET Framework. Sure, there will be times where you are limited (those horrible choices some Framework developers make to mark a very useful method as internal), but with each new version, we (the developers) are given ways to replace entire systems at work across one or more applications.

Happy coding!

LINQ to SQL currently only works with SQL Server 2005. It’s not likely that Microsoft will bother with any other providers with the Entity Framework and LINQ to Entities on the horizon. There is a way to get standard LINQ to SQL to work with the SQL Server Compact Edition (SSCE) however. You have to use the SqlMetal command-line tool to generate the appropriate file(s). Once you generate the .dbml file, you can even open it in the Visual Studio 2008 designer.

Deploying SSCE when Using LINQ

Deploying SSCE with your desktop application is pretty easy. You can quickly publish your application via ClickOnce, but I’m not a big fan of that technology. Instead, I prefer an installer program. You can use any one that you prefer and still easily deploy SSCE with a couple of options.

Windows Installer

First, you can choose to create a pre-requisite or dependency tests for the system installation of SSCE for the version you require (3.5 or later to work with LINQ). If the engine is not installed, you can send the user to the Microsoft website for installation or you can launch the redistributable Windows Installer file for it. This method requires that the user have Administrator privileges in order to perform the system install.

Please note that if you launch the .msi file to install SSCE and your installer is a Windows Installer program, you will have to close your installer first; two instances of Windows Installer cannot be run simultaneously.

X-Copy

Second, you can just copy the necessary redistributable library files for the SSCE engine into your application’s install directory. This method does not require Administrator privileges! There are 7 files that need to be copied with your application and they should be copied to the same directory as your primary executable.

• sqlceca35.dll
• sqlcecompact35.dll
• sqlceer35EN.dll
• sqlceme35.dll
• sqlceoledb35.dll
• sqlceqp35.dll
• sqlcese35.dll

Make sure your application references the System.Data.SqlServerCe.dll assembly and it is set to copy the assembly locally as well. This is especially important when you use LINQ to SQL with SSCE because that assembly is implied at runtime and therefore not explicitly required as a reference in your application until it’s time to deploy on a system that does not have SSCE installed.

Please, be aware that if you choose to redistribute SSCE in either form (Windows Installer or individual libraries), you must register for redistribution rights with Microsoft.

The Hidden Problem

There is a hidden problem with all of this will finally crop up with the x-copy method. Since LINQ uses a factory pattern to acquire the necessary data provider, the necessary reference to the provider does not occur until runtime. Herein lies the problem.

When your application makes that first attempt via LINQ to connect to the SSCE database file without a system install, you will receive the following error message:

Cannot open “X:Pathtodatafiledatafile.sdf”. Provider ‘System.Data.SqlServerCe.3.5′ not installed.

If SSCE is installed by the user via the Windows Installer file, this problem is handled for you. The installer adds an entry to your machine.config file. Since the whole purpose of an x-copy install is usually to avoid the need for Administrator privileges, this just will not do.

Instead, you will need to add an application configuration file to your desktop application, if you do not have one already. Right-click your project in “Solution Explorer”, choose “Add new…”, select “Application Configuration”, and click OK. Make sure the new file looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.data>
    <DbProviderFactories>
      <remove invariant="System.Data.SqlServerCe.3.5" />
      <add
        name="Microsoft SQL Server Compact Data Provider"
        invariant="System.Data.SqlServerCe.3.5"
        description=".NET Framework Data Provider for Microsoft SQL Server Compact"
        type="System.Data.SqlServerCe.SqlCeProviderFactory,
          System.Data.SqlServerCe,
          Version=3.5.0.0,
          Culture=neutral,
          PublicKeyToken=89845dcd8080cc91"
      />
    </DbProviderFactories>
  </system.data>
</configuration>

This ensures that the appropriate database provider factory is added for your application, without the need to edit the end-user’s machine.config file or require a system installation of SSCE.