Rails 3.1 and MySql2 installation

Install MySql 2 adapter using gem install:

gem install mysql2


Modify the gemfile for your app by opening it and add the version of the mysql gem you want to use:

gem 'mysql2', '0.3.7'


Create the mysql2 bundle, which links mysql2 gem with its dependencies (to the best of my understanding this is what is going on)

bundle install


If you get the error "Library not loaded: libmysqlclient.18.dylib" it is because the bundle you created earlier doesn't know where to find this dylib (DLL). To fix this, use the Xcode tool install_name_tool:

sudo install_name_tool -change libmysqlclient.18.dylib /usr/local/mysql/lib/libmysqlclient.18.dylib ~/.rvm/gems/ruby-1.9.2-p290/gems/mysql2-0.3.7/lib/mysql2/mysql2.bundle

Basically this command says: for this dylib, it is located here, and put that location in the mysql2.bundle


To connect at terminal, use the mysql command, this line logs you in:

/usr/local/mysql/bin/mysql -u root -p


Create a shortcut to the mysql command by adding to your bash path:

echo 'export PATH=/usr/local/mysql/bin:$PATH' >> ~/.bash_profile

Now you can simply type:

mysql -u root -p

database.yml file needs to be configured as such:
development:
adapter: mysql2
database: dbname
host: 127.0.0.1
username: user
password: password


chown -R mysql /usr/local/mysql
chmod -R u+rw /usr/local/mysql

start mysql with:

sudo mysqld --user=root


Set root mysql password with mysqladmin


start mysql monitor with:

mysql -u root -p (p prompts for password)


to shutdown server:

mysqladmin -u root -p shutdown (will prompt for password set above)


To create a new user:

create user 'username'@'localhost' identified by 'password'


Grant the user access:

grant all 'username'@localhost' identified by 'password'

Web Sites and the CodeDom

If you are using a WebSite (as opposed to Web Application project), and upgrade to .Net 3.5 (so you can use features like LINQ), you will need to add the following config section to your web.config:

<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warninglevel="4">
<provideroption value="v3.5" name="CompilerVersion">
<provideroption value="false" name="WarnAsError">
</compiler>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warninglevel="4">
<provideroption value="v3.5" name="CompilerVersion">

<provideroption value="false" name="WarnAsError">
</compiler>
</compilers>
</SYSTEM.CODEDOM>

This of course is for both C# and VB, you can remove the non-used language section. The reason this is needed is that when you have a website, individual pages are compiled when requested, which requires the CodeDom to know which version of the framework you want to use. If you use a Web Application project this setting is not needed since an assembly is pre-compiled for all pages in your project.

Publish click once application via MSBuild

By default, the only way to create a click once installed application is to publish via Visual Studio. If you are planning to automate your builds using TFS Team Build projects, you will need the following task to actually publish your product:

In your TFSbuild.proj, use the following MSBuild task:
<MSBuild Projects="$(SolutionRoot)\MyProduct.UIShell\MyProduct.UIShell.csproj"
Properties="Configuration=%(ConfigurationToBuild.FlavorToBuild);
PublishUrl=http://appserver/MyProduct/;
PublishDir=$(OutDir)_PublishedWebsites\MyProduct.UI\;
InstallUrl=http://appserver/MyProduct/;
InstallFrom=Web;
DTPublishDir=$(OutDir)_PublishedWebsites\MyProduct.UI\;
ApplicationVersion=$(ClickOnceVersion);
ProductName=MyProduct_DEV; <--NOTE: this allows you to publish different versions of the same product.
PublisherName=MyCompany;"
Targets="Publish" />


Additionally, checking the "minimum version required" option under the Update panel will cause clients to be updated without the option to skip new versions (assuming the client already had a prior version installed). The clients will also be required to get a version that is higher than what is marked as minimum.

IIS 6 Native Compression

IIS 6 allows compression of messages sent to client requests. The following explains how to enable compression/decompression using gzip.

• Open IIS Inetmgr.
• Right click on "Web Sites" and then click the service tab.
• Check "Compress application files" and "Compress static files" under HTTP compression.
• Click OK
• Click "Web Service Extensions"
• Add the gzip.dll extension
  

Note: Adding a web service extension allows IIS to utilize a program (in this case gzip). By default IIS only serves up static content, and you will see the ASP and ASP.NET 1.1 and 2.0 are likely currently configured on most servers.

• Navigate to C:\%Windir%\system32\inetsrv
• Open MetaBase.xml
• Find the IIsCompressionScheme nodes, and make sure it looks like the following:
  
  

• Save and close.
• Restart IIS.

Now that IIS Compression is enabled at the website level, you must opt-in for compression at a web service instance level:

MyWebService ws = new MyWebService()

ws.EnableDecompression = true;

Thats it, compression/decompression will automatically occur for this instance of this web service on all method calls.

Note: This information was generally gleaned from Scott Forsyth's blog (which I note below), however the specific metabase.xml settings that were necessary to make this work differed slightly, and are noted in the config snippet above.

Another Note: compression level is set to 9 based on the following:

"HcDynamicCompressionLevel has a default value of 0. Basically this means at if you did everything else right, the compression for dynamic contact is at the lowest level. The valid range for this is from 0 to 10. I had the opportunity of receiving an internal testing summary from Chris Adams from Microsoft regarding the compression level -vs- CPU usage which showed that the CPU needed for levels 0 - 9 is fairly low but for level 10 it hits the roof. Yet the compression for level 9 is nearly as good as level 10. I write all this to say that I recommend level 9 so make sure to change HcDynamicCompressionLevel to 9. Do this for both deflate and gzip." Source: http://weblogs.asp.net/owscott/archive/2004/01/12/57916.aspx

SqlConnection.Dispose vs. SqlCommand.Dispose

After reviewing the service layer of an application to verify that all SqlConnections were properly being cleaned up, I thought I would post my findings on the details of how the SqlCommand and SqlConnection objects work with ADO.Net connection pooling.

I found several blogs/threads that stated "calling dispose on a SqlCommand instance will in turn clean up the underlying connection and remove it from the ADO.Net connection pool". This is not quite the case. I put performance monitor on task, and while watching NumberOfActiveConnections and NumberOfPooledConnections, it was clear that the active connection was never closed by calling SqlCommand.Dispose(). A review of MSDN documentation on the dispose method simply states: "Releases all resources used by the Component. (Inherited from Component.)".

To ensure that the active connection is in fact closed, and returned to the connection pool, you must call either Close() or Dispose() on the SqlConnection instance. It is recommended to call Dispose() since this also releases other instance level resources (such as the connection string). Note that even when calling Dispose, the connection is returned to the ADO.Net connection pool.

You can accomplish this same functionality by wrapping your connection/command in using statements, the underlying connection management is the same, and this accomplishes calling the Dispose() method on both the connection and command.

ADO.Net connection pooling and SQL Server 2005/2008 mirroring

ADO.Net connection pooling

Connection pools are stored within App Domain. For an IIS application, this will be within the app domain that is hosted within a specific w3wp.exe process (one per application pool). For a windows forms application, the connect pools are still stored at the App Domain level, within the process. A connection pool will be created per process/App Domain/executing user (in the case of integrated authentication)/connection string.

Per figure 1, you can see individual identical connections reside within connection pools, which in turn reside within a pool group. A pool group is merely a collection of connection pools that differ only by the executing user. Pool groups are in turn within an app domain within the executing process.

Since connection pools are hosted within an app domain, the lifetime of the connections is the same as the app domain.

SQL Server mirroring

To utilize SQL mirroring, add the “Failover Partner=[server name\instance name]” attribute to your connection string.

ADO.Net will manage determining that the principal server is the one named in the “Data Source” attribute initially.

If a connection pool has already been established within the current app domain when a failover to the mirrored server occurs, the following steps happen:

1. A SqlException is raised with the message “A transport-level error has occurred when sending the request to the server….” Note: you must handle this raised exception, close the current connection and re-open the connection in order to handle the failover as smoothly as possible.
2. Failover is detected by ADO.Net
3. Failover partner is identified from connection string
4. Pool groups are cleared
5. New connection is created in a connection pool with a server name of the failover partner

If there are no current connections, ADO.Net will gracefully handle failing over to the mirrored server.