I recently inherited an application to work on which for whatever reason didn't have the code-behind files linked with the corresponding .aspx and .ascx files.

Visual studio looks for a codefile="class.cs" attribute in the page or control directive and this was missing.

So, when opening the application in Visual Studio the list of files was twice as long as it should have been and prevented Visual Studio from working some of it's magic like it does.

There were hundreds of files and editing each one to add the codefile="..." attribute to each page or control tag would have taken far too long.

What is the quickest way of turning this:

<%@ page language="c#" inherits="Company.Application.Class, Assembly" theme="Default" %>

... into this:

<%@ page language="c#" inherits="Company.Application.Class, Assembly" theme="Default" CodeBehind="Class.aspx.cs" %>

? Regular expressions of course !

Visual Studio can do search and replace and provides it own Regular Expression syntax that can be used (slightly different to most other versions strangely including the .NET framework itself but it works).

In case anyone needs to do this the syntax I used was:

Find what:
^{\<\%\@:bpage.+inherits=\"}{.+}\.{.+}\,{.+\"}{.+}$

Replace with:
\1\2.\3,\4 Codebehind="\3.aspx.cs"\5

Not forgetting to make sure that the 'Use:' option has 'Regular Expressions' selected.

Now, one click of the 'Replace All' button and the files were re-associated (after saving and re-opening the project).

For controls, I just replaced the 'page' part of the Find text with 'control'.

If you don't use a namespace then you may need to tweak the regex's a little but hopefully this should save you some work.

The current project that I am working on has experienced a few problems recently where developers have made changes to the build files (such as adding assembly references) but not the Visual Studio project files or vice versa which results in the rest of the team coping with a broken build or a solution that appears broken when first opened.

While the obvious and probably most common solution would be to use the Visual Studio definition of the projects as the master and create the build file from that (or use MSBuild directly) we do have some added complications that prevent this approach:

• The application is cross-platform and has to run on Linux / MONO as well as Windows / .NET
• There are C#, C++ and FORTRAN modules in the application (scientific computing)
• Some developers work on Linux and do not want to use Visual Studio

I have evaluated and had some success with the Prebuild project which lets you define all the project settings and dependencies in an Xml file (which isn't too dissimilar to the Visual Studio format but is probably 'politically acceptable'). From this Xml file the tool generates the Visual Studio solution & project files plus the (NAnt) build files. It can also generate Mono Develop or Sharp Develop projects for use on Linux to keep everyone happy.

While it's a great tool there are a few things I don't like - I wish you could define your own templates for build files instead of being forced to use the one provided (although you can change the source to alter what it generates). Also, it doesn't directly support the build tool we are using (SCons) but I'm hoping we can switch to using NAnt at some point to fix some other issues.

It does address the main problem though - ensuring that there is only one 'truth' and a single way to add project references (in the Xml file). Adding it to the build files or the project files directly is pointless as they are both generated as part of the build process (which will then fail if the Xml definition is wrong).

Also, it's quite nice to just have source code checked into the repository ... no build files, no solution, no projects. Everything is created as needed which may also help as the team migrates to VS.NET 2008.