>>Even better would be a way to mark sections of code as "BLG please keep"
> Do you still see this as necessary .. when .. BLG automatically generates a second partial class source file

Yes I think so - WHATEVER you do, the BLG-written code will potentially need some tweaking.

Here's what I do...

I override ABusinessObject.cs and add a HookConstructor() method.

BLG writes Xyz.cs, XyzEntity.cs, XyzRules.cs - I create XyzExtra.cs which contains extensions to all three classes, ie it might look like this (condensed):

namespace MyApp.Business
{
  partial Xyz  { .... }
  partial XyzRules { ... }
  partial XyzEntity { ... }
  public XyzDefaults { ... }
} // namespace

Typically I need to do the following sorts of adjustments to BLG-written code:

* The bizobj class, put code in HookConstructor() to set key properties
* Override SetDefaultValues() - I put this code in the Extra.cs and comment out the BLG-written version.
* The XyzEntity.cs nearly always gets completely left alone, since adding and removing fields on a table is quite a common change and the usual reason to need to regen code at all. (primary key is unlikely to change).
* The entity class might get the odd extra property, derived values, eg:

public decimal GetValue() { return This.price * THis.Quantity }
  // elsewhere public enum OrderStatus {..}
  public OrderStatus Status { get { return (OrderStatus)this.StatusCode }

This would go into XyzExtra.cs

* The rules class either gets completely left alone because it is not needed, or completely rewritten and I never want the BLG to touch it again.
* Sometimes an additional namespace needs to be brought in.

So for example, if I override SetDefaultValues() and regen the bizobj class, I end up with TWO SetDefaultValues() methods and get a compiler error, which tells me there is a problem.

Now - say my BLL library has 10 entities - so it's a small one! - and 40 source code files. I don't always remember which ones the BLG can safely rewrite and which ones it should never touch.

(Perhaps should go without saying that I always have the last version checked into source control - Subversion in my case - as a backstop. But some minor regressions won't get picked up until full system testing is done)

So at least it would be nice to have something like this

/* #MM.NET:BLG-Leave-This-File-Alone */

If the BLG ever tries to overwrite a file containing such a comment, it would pop up a message "Are you really really sure you want to destroy your precious work? <g>".

The second side is more tricky - giving finer control over rewriting only parts of a source code file. For example, this might work:

//This is a bizobj class
using System;
... 
using OakLeaf.MM.Main.Data;
//#blg-begin-snippet Using
using MyApp.Types;
//#blg-end-snippet Using

namespace MyApp.Business {  class Xyz : ABusinessObject {

  public Xyz()
  {
	this.TableName = "Product";
	this.PrimaryKey = "ProductID"; 
//#blg-begin-snippet ConstructorExit
    this.AutoNewOnParentNew = true
//#blg-end-snippet ConstructorExit
  }

//#blg-begin-snippet Methods
    public void AddedMethod() { ... }
//#blg-end-snippet Methods
  } // clss XYZ

//#blg-begin-snippet Classes
    public class XyzDefaults { ... }
//#blg-end-snippet Classes

} // namespace

The idea I have here is that the BLG templates would define insert points - "Using", "ConstructorEntry" ,"ConstructorExit", and would scan for code between #blg-begin-snippet and blg-end-snippet, and place any matching code in the defined place in the code file.

[-- updated renamed "ConstructorBEnt" (what?) to "ConstructorEntry" .. oops]

The onus would be on the developer to bracket their changes properly, and get the snippet names right (although you could warn if a name was not recognized) and the BLG would not guarantee the exact position or ordering of the code, but it would enable a lot of things that aren't easy now.

In fact the five snippets I've come up with now are probably all most people would ever need - without resorting to .Partial.cs at all.

If the BLG generates a .Partial.cs for each and every class it generates - help! Instead of three .cs (or .vb) files for every bizobj, we have six. TO be quite honest, no thank you.