Chris May

Problem:

We have a server that gets all files from TFS and uses Nant w/ Visual studio to compile our projects.  Basically nant issues a command line statement to get VS to build a given solution.

Everything was working great, until I upgraded our clients to 2008.

I went through and upgraded all our solutions.

I installed vs 2008 on the server.  But when I try to build from the command line, it tells me that the solution file "is from a previous version of this application and must be converted in order to build in this version of the application."

I tried directly copying my solution file (skipping the source control step) directly to the server but I get the same message.

If I try to build it from the command line with VS 2005 it tells me that the solution is too new!! 

So 2005 says the solution is too new, 2008 says it is too old!

The solution on the server has the "version 9" icon, just like on my laptop.

The solution file starts with:
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008

Resolution:

Even thought I compared the solution files and found them to be exactly the same using a diff compare tool, I allowed the server to run the "upgrade" process on the solutions.  I didn't save any of the changes it made, but from then on it recognized those files as having been already upgraded.

I even replaced the "server upgraded" solution files with the old solution files that it didn't like and it continued to work just fine.

There must be some other files stored somewhere that made it think that it hadn't been upgraded yet.

This isn't a great solution, but it works at least.

Somehow the term ALT.NET has been created to describe people who use .Net to program, but try to avoid the "standard" practices and tools that microsoft pushes.

Roy Osherove has an article where he pits the HOT and NOT as seen by the alt.net guys.

My major issue with trying to adopt more of these practices is that I work mostly on existing large applications.

I can't just show up at a client who already has millions of LOC using a more standard approach with thousands of stored procedures, and jump into a Monorail/NHibernate project.

For now I am focusing on getting one of my clients using a server based build and deployment.  We have already moved off of VSS, which is making a big difference in our productivity.

The VSSConverter tool which allows you to convert from VSS to TFS will attempt to utilize a local version of SQL Express.

This sucks, as I hate SQL Express.

After some searching/trials/errors, I found a way to get it to work against a SQL Server 2005 database.

Just add the SQL tag to your migration settings xml file like so:

<Source name="VSS">

      <VSSDatabase name="D:\Program Files\Microsoft Visual SourceSafe\VSSHttp"></VSSDatabase>

      <UserMap name="D:\VSS2TeamFoundation\Usermap.xml"></UserMap>

      <SQL Server="name_of_your_SQL_Server" />

</Source>

In previous versions of VS.Net you could take a project and go File->Source Control->Add Selected Project To Source Control and you could simply add the project to your VSS provider.

Now in VS.Net 2005 (maybe caused by VSS 2005, or VSS 2005 over HTTP), if you follow this route you will end up with File->Source Control->Add Project to Source Control, and your project will be added with the following path:

$\MyProject.root\MyProject.

Thanks VSS, thanks a lot.  I really needed that .root in there.

To get around this problem, just add another existing project to VS.Net (creating a solution).  Now highlight the actual project you want to add and do:

File->Source Control->Add Selected Project to Source Control and all will be wonderful.