Archive

Archive for the ‘C#’ Category

The delights of SqlMetal: Multiple ResultSets from a stored procedure

May 17, 2011 5 comments

Ever wanted to return multiple result-sets from a stored procedure using Linq to SQL? Well I have and, like you if you’re reading this, I found that the default settings in Visual Studio generated code did not allow it. The problem was that the code generated only returned the first result set from the stored procedure. I.e:

SELECT * FROM USERS
SELECT * FROM ROLES

Gave me an IEnumerable return value. Now this just wasn’t good enough; so without further ado here’s the simple code to create a database entities ‘later’ using SqlMetal (a Microsoft authored tool supplied with both Visual Studio 2008 and 2010). First of all, the easiest way to start this tool (as with all Visual Studio tools) is to open the command window within the Tools sub-menu in the Visual Studio section of the Start menu.

Once in try this:

SqlMetal /server:. /database:MyDb /code:”DalEntities.cs” /sprocs /namespace:DalEntities /pluralize /serialization:Unidirectional

…and you’ll find that magically the usual dbml style generated code is produced and placed in DalEntities.cs – in this particular case with all the Stored Procedures included also.

What’s more, as previously said, the tool supports multiple result-sets to be returned from stored procedures. As shown below:

[global::System.Data.Linq.Mapping.FunctionAttribute(Name="dbo.TestStoredProcedure1")]
[global::System.Data.Linq.Mapping.ResultTypeAttribute(typeof(TestStoredProcedure1Result1))]
[global::System.Data.Linq.Mapping.ResultTypeAttribute(typeof(TestStoredProcedure1Result2))]
public IMultipleResults TestStoredProcedure1()
{
	IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())));
	return ((IMultipleResults)(result.ReturnValue));
}

It’s like magic, I tell ye!  Have fun!

Advertisements

Loading an assembly from a specific directory (i.e. when not in GAC)

March 20, 2011 Leave a comment

C# Post HeaderJust like dynamically loading DLLs with C# – at last!

You do not have to put an assembly that an application must use at runtime in the bin folder of the application. You can put the assembly in any folder on the system, and then you can refer to the assembly at runtime.

My preference – which requires no configuration during installation – is to use method 3; just find your current executable’s folder and calculate a relative path from there – ensuring that, even when the app is copied using a standard file copy, it still works on the new server (shedding any deployment requirements with regard to this). See here:

http://support.microsoft.com/kb/837908

Categories: C#
%d bloggers like this: