Here's one I will not probably remember the next time I need it.

A coworker was trying to use a DAL i generated in LLBLGen against a staging database on the same SQL Server as the production database the DAL was generated against.  If you look at the generated code you will see that the reference to the database is hardcoded. 

Turns out there is a way to tell LLBLGen to ingnore the hardcoded entry and use the catalog indicated in the connectionstring instead.

In your app.config or web.config file of your application project (not the llblgen project), add the following configuration:

<configSections>

     <section name="sqlServerCatalogNameOverwrites" type="System.Configuration.NameValueSectionHandler" />

</configSections>

<sqlServerCatalogNameOverwrites>

     <add key="myProdDB" value="" />

</sqlServerCatalogNameOverwrites>

In this example, the blank value (value = "") tells llblgen to just use whatever catalog is indicated in the connectionstring.  You could put the name of the new database in there and it will ALWAYS redirect to that database.

Additionally, Somewhere in your code that is calling your llblgen classes will need to include this line to set the connectionstring:

DbUtils.ActualConnectionString = "Data Source=mySQLServer;Initial Catalog=myDatabase_Staging;Persist Security Info=True;User ID=xxx;password=xxxxxxxxxx!"

Where myDatabase_Staging is the name of the database you want it to point to instead of the one you built your LLBLGen classes against.

I overloaded a method in my WCF service that compiled fine, but exploded in my face at runtime.   A bit of digging around later and I discovered you can get around this "limitation" by using the "name" attribute in your OperationContract tag of the ServiceContract.

Here is an example I found and the link to the original article where I found the answer:

[ServiceContract]
public interface ICalendarService
{
   [OperationContract(Name = "GetScheduledEventsByDate")]
   ScheduledEvent[] GetScheduledEvents(DateTime date);

   [OperationContract(Name = "GetScheduledEventsByDateRange")]
   ScheduledEvent[] GetScheduledEvents(DateTime start, DateTime end);
}

http://jeffbarnes.net/blog/post/2006/09/20/Overloading-Methods-in-WCF.aspx

I just stumbled on a nice "feature" that will have you scratching your head if you don't know it's there.  Apparently Microsoft changed the way the Async methods in a web service proxy get generated somewhere between VS 2003 and VS 2005.  

However, the project KNOWS if it's been "upgraded" from VS 2003 all the way to 2008 and generates the proxy with backward compatibility in place.  It wasn't until I started this rewrite and consumed the same web service that I noticed things MISSING from my proxy because, of course, this isn't an upgrade so they don't generate the old style async methods.

So here I was with my old and new solutions loaded side-by-side, regenerating the SAME web service reference and getting different results, and wondering ...  hhhhhhow?

So to be clear, BeginMyMethod and EndMyMethod style async methods are the "old" way and will not be generated until you  set a project level property WebReference_EnableLegacyEventingModel to be true.

Fortunately for me in this case, I can just abandon it and do it the 'new' way.

Here is the link to the article I found the answer on, though you will have to read through the comments a while to get there.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=288660