LINQ to SQL deployment problem

Question

Hi all

I have an asp.net application developed. It uses LINQ to SQL to access database, using the .dbml designer in Visual Studio 2008. We are installing the application on client, and they have decided to change the database name on their servers. Now, the application does not work because LINQ can't find the database information. This is not an issue with the connection strings, but with the files generated by the .dmbl designer. I suppose we have some options: 1. Change the development database name to match the client's name, regenerate de dbml, recompile, and send the application again to client. 2. Install VS2008 on client and make the necessary modifications there.

None of the options seem really good. This is not the end of the world, but it is a real pain. I hope there's a more reasonable solution! Any ideas?

---

UPDATE
After studying the problem a bit further with the help of your answers, I think the problem lies with the schema. To sum up, the database has a new name and a new schema. I suppose the sqlmetal.exe option is the best one right now. Anyways, if this is the case, I still think it's a real pain.

Answer 1

There's an exe as part of VS2008 class SQLMetal.exe which does the important part of generating the DataContext.cs file. I think all you'd have to do is change the DBML file (it's a simple XML file), run SQLMetal (producing a .CS), and then run csc.exe (part of the .NET framework) to produce an Assembly (It'll be easier if you put the DataContext in an assembly by itself). This essentially boils down to option 2, but with far fewer files which need to be installed.

---

Update: Re-reading you question, I realize it's not the table names that changed, but the database name. This is a different problem (although the solution described above will work for that too).

When VS2008 generates the DataContext class from the .dbml file, it creates two constructors: One which taken no parameters, and once which takes one string (plus a couple more ctors, which we can ignore).

The zero parameter ctor uses the connection string you used when you created the dbml, which it then embeds in the resource file. This is an incredibly dumb design, and really should only be used for proof-of-concept code and demos.

All real production code should use the ctor which takes a string -- specifically, the connection string --- which you should read out of the app.config file.

This of course means the "correct" solution is option #1 -- rewrite the code at your office and re-deploy. It's a bother, but in the long run, it's for the best.

Answer 2

I would say it Is a connection string problem, see the generated class:

    public SomeDataContext() : 
        base(global::System.Configuration.ConfigurationManager
.ConnectionStrings["someConnectionStringKey"].ConnectionString, mappingSource)

Please provide more info. Perhaps you mean an schema change, in which case I strongly suggest to have it the same on the dev environment.

Update 1: Perhaps the DatabaseAttribute on the generated class confused you.

Use the Name property on a DatabaseAttribute attribute to specify the name of a database when a name is not supplied by the connection

Source: http://msdn.microsoft.com/en-us/library/bb399355.aspx# (enpashis by me)

Just specify the database in the connection string, and you are good to go.

Update 2: If your generated class for some reason doesn't has the above code (and you aren't explicitly specifying one in the parameter), open it on the designer, open the properties, and make sure it is configured in the Connection property with Applications Settings set to truth.

Answer 3

OP:

I'm surprised that this would cause an issue. I've developed around 5 Add-on pieces using Linq to SQL. The only thing that I had to do to circumvent this was to do the following:

using (NamedDataContext ctx = new NamedDataContext("{insert connectionstring from config file/registry entry/etc. here}")) {

... code to be done against the database ...

}

and have not run into any issues yet at this point. I'm confused as to why your application doesn't have a configuration method to handle configuring your database connection, as that is usually the first thing most applications need built into them.

Answer 4

Personally I would tell the client that changing the database name from what was developed will cost them $XX in new development costs and watch them change the name right back.