Visual Studio stomping on Linq Stored Procedures

Question

I have several stored procedures which return a strongly typed result set. I've learned that Linq has its own method for handling that, which must be overwrote (or at least it seems that way).

My problem is Visual Studio insists on forcibly recreating stored procedures sometimes. I want to disable this.

Here is my manually modified file:

 [Function(Name="dbo.spGetNote")]
 public ISingleResult<Note> spGetNote([Parameter(DbType="Int")] System.Nullable<int> noteId, [Parameter(DbType="Int")] System.Nullable<int> securityUserId)
 {
  IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), noteId, securityUserId);
  return ((ISingleResult<Note>)(result.ReturnValue));
 }

Here is what it defaults it to:

 [Function(Name="dbo.spGetNote")]
 public ISingleResult<spGetNoteResult> spGetNote([Parameter(DbType="Int")] System.Nullable<int> noteId, [Parameter(DbType="Int")] System.Nullable<int> securityUserId)
 {
  IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), noteId, securityUserId);
  return ((ISingleResult<spGetNoteResult>)(result.ReturnValue));
 }

This is one of the smaller ones.

There are some other areas it messes with, but those are fixable. It gets real old going back and adjusting this.

What we've ended up doing is every stored procedure which returns its own strongly typed item is given it's own data context / class so that every time we update our DAL, it (Visual Studio) doesn't stomp on our custom changes.

Is there something I can do to help alleviate this headache?

What brought all this on is I'm going through cleaning up name spaces and I have found I can not change the namespace without Visual Studio ripping apart every single stored procedure in the project and I don't want to spend hours cleaning up that mess. Seemingly a global replace is not enough, as Visual Studio detects this and then says it can't find a conneciton string and must rebuild every single file involved.

Answer 1

Don't change generated code. If you do, then any time you look at the dbml file your changes are likely to be lost. You might (I haven't tried) be able to fix this by editing the dbml by hand (it is just xml); but IMO, the simplest way of handling this is inside your repository, to do a projection from the dbml-generated type to your type:

Note[] SomeFunc(...) {
    using(var ctx = ...) {
        return (from row in ctx.SomeSP(...) // row is the dbml type
             select new Note { // Note is our custom type
                 Id = row.Id,
                 Name = row.Name,
                 // etc
              }).ToArray(); // or whatever
    }
}

Answer 2

Since the auto-generated DataContext is partial, you could create your own partial class and move your customized methods/types into the partial. i.e.

MyDataContext.cs

public partial MyDataContext
{
        [Function(Name="dbo.spGetNote")]        
        public ISingleResult<Note> spGetNote([Parameter(DbType="Int")]...
}

public class Note...

Joe