Resharper - Inline Method

While most of the time my experience as a developer has been in the .NET stack, I've had the opportunity on a previous project to step into Java for 7 months. This gave me the opportunity of working with IDE's such as Eclipse and IntelliJ that have strong support for refactoring.

I've since returned back to the .NET side and have been found wanting.

Resharper is a crucial piece to the productivity of any .NET developer working in Visual Studio, but there's just some things missing. I won't even go into the really big ones.

One simple, small one in particular has been driving me absolutely bonkers lately:
No support for Inline Method

What makes me truly sad is that i see no indication that the next version (Resharper 4.0) looks to include this.

Can anyone answer why?
Is it significantly harder to implement in Resharper than in IntelliJ?

But I can't really blame JetBrains. That'd be likely biting the hand that feeds me. Deep down I actually blame a colleague of mine for being too good at what he does. He never should have shown so many different ways of safely refactoring code using that refactoring knowing that I'd miss it so. He knows who he is. No scotch for you.*

*note the sarcasm before the flame storm.

Using DBDeploy.NET

To get dbdeploy.net up and running on a project is relatively straightforward.

First thing, if you haven't already downloaded dbdeploy.net, get it from here
I try to keep unnecessary files from being committed to the source control repository, so extract the downloaded zip somewhere (like your desktop) and we'll pick and choose what is needed from there to add to our project.

I tend to follow a project structure similiar to this:


So the first step is to copy the dbdeploy.net\bin folder from the desktop into a tools\dbdeploy folder:

Next we'll want to setup the location we keep all our db related scripts.
In the working directory, add a db folder and below that also add a deltas folder. For dbdeploy.net to work, your database requires a schema version table, so from the dbdeploy.net\scripts folder from the desktop, select the appropriate sql based on the database being used and copy it to your db folder: I also usually keep the database creation script at this location:

Finally, its time to modify our nant build file to include tasks for the db related work.
(Note that i'm omitting some things to reduce the noise, so if something is unfamiliar let me know)

Use of the sql task from nantcontrib is required so ensure you have that available in your tools and import it at a global level in your build file as so:

<loadtasks assembly=""tools\nant\contrib\NAnt.Contrib.Tasks.dll"/>

Add a folder to hold the automated builds upgraded script.

<target name="init" description="initial compilation setup">
<mkdir dir="${build.dir}"/>
<mkdir dir="${build.dir}\db"/>
</target>


Then a task for creating the database:

<target name="db.create" depends="init">
<echo message="create database" />
<sql connstring="${connection.string}"
source="db\createDatabase.sql"
output="${build.dir}\db\createDatabase.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />

<echo message="create db deploy change log table" />
<sql connstring="${connection.string}"
source="db\createSchemaVersionTable.mssql.sql"
output="${build.dir}\db\createSchemaVersionTable.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />

<call target="db.upgrade" />
</target>

And finally, the task for upgrading the database:

<target name="db.upgrade" depends="init">
<loadtasks assembly="tools\dbdeploy\Net.Sf.Dbdeploy.dll" />
<echo message="upgrading database to latest version" />

<!-- creates the script -->
<dbdeploy dbType="mssql"
dir="db\deltas"
dbConnection="${connection.string}"
outputFile="${build.dir}\db\db-upgrade.sql"
undoOutputFile="${build.dir}\db\db-upgrade-undo.sql" />

<!-- applies the script -->
<sql connstring="${connection.string}"
source="${build.dir}\db\db-upgrade.sql"
output="${build.dir}\db\db-upgrade.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />
</target>


I also usually add a task to handle undoing the changes.

<target name="db.upgrade.undo">
<sql connstring="${connection.string}"
source="${build.dir}\db\db-upgrade-undo.sql"
output="${build.dir}\db\db-upgrade-undo.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />
</target>


Thats it. Infrastructure done.

Assuming your existing build all target is something like this:
<target name="all" depends="clean, init, compile, test, dist" >

To make that recreate the database on each build:
<target name="all" depends="clean, init, compile, db.create, test, dist" >

Or if you only want to upgrade on each build:
<target name="all" depends="clean, init, compile, db.upgrade, test, dist" >

We're now set up to follow a more evolutionary database design, with each additional database change needed being added as a file in the db\delta folder. Remember, the only rule is to follow a naming convention around these scripts. Each file needs to begin with a number, one higher than the previous one.



NOTE: for a good post on using the java version of dbdeploy see Pramod Sadalage blog here

DBDeploy.NET

Taken from www.dbdeploy.com:

dbdeploy is a Database Change Management tool. It’s for developers or
DBAs who want to evolve their database design - or refactor their
database - in a simple, controlled, flexible and frequent manner.

While the java version of dbdeploy has received accolades over the past year, I'm curious how many people are aware that there is a .NET port (available here).

How many people are currently using it? How many would like to be?

I know there is limited documentation or examples of using the .NET version available and have been toying with the idea of doing some posts on how to use dbdeploy.net on a project.

Anyone interested?

(note: expressing interests strongly increases the likelihood it will happen)

Interesting tool - SVNBridge

I see that they have released a V1 of an interesting tool called SVNBridge about a month ago.

The project description sums it up:

allows you to use TortoiseSVN and other Subversion clients with Team Foundation Server. It converts the calls made by your Subversion client to the API supported by TFS.

I prefer to use Subversion/TortoiseSVN as my source control/client of choice.

But in those situations where I'm required to work with Microsoft Team Foundation Server, for example working with CodePlex projects, this allows me to continue to use TortoiseSVN as the client.

Which is nice. Not perfect but good.

Am i alone here???

I'm a strong believer that when developing an application, your main source tree should contain everything that is required to build and run the application. Getting up and running should be as simple as getting the latest version of the code from the repository, running a build and that should be it.

Yes, i am aware of the pragmatism of real world always means there are exceptions.. but i still believe this should be the ideal.

In order to achieve this ability, most projects I've been involved in use the concept of a tools or lib folder at the root of your source tree. These folders contain external dependencies needed by your project in order to build/test/deploy the application.

For example:

projectname
|---trunk
|------- db
|------- docs
|------- src
|------- tools
|----------- nant
|----------- nunit
|----------- nmock2


This works great...except when you have to use Microsoft related technology tool.

95% of Microsoft tools I've attempted to use still have a dependency on an MSI needing to magically install something somewhere to make it work. Which, pardon my french, is crap.

For example... I had a small requirement that the ASP.NET AJAX framework appeared to solve quit nicely. Seemed as simple as adding one line to an aspx page would have done the trick. Plus its an AJAX framework, should be simple to add to the tools folder, add a reference, build and deploy it out.

Nope.

First you have to run an installer, then you have to download and extract another zip file... then you have to repeat on any machine hosting the web application. And have the rest of your team do the same the next time they get the latest version of the code. Crap.

Am i alone in my frustrations of how Microsoft suffers from severe "Installitis" with their developer tools??