Develop Reference

Using SSDT as source for T4 templates

I have a SQL Server Data Tools (SSDT) project that has a number of stored procedures for which I would like to generate the C# code to call them using T4. Are there any existing examples for doing this?
So far, I can create a function per proc, but I'd really like to be able to tap into the meta data SSDT creates so I can get the parameters, data types, and return values from it rather than doing string parsing.

COOL WITH A CAPITAL C! (but don't tell anyone who uses an ORM!)
To get the datatypes etc make sure you grab the latest DacExtensions from the MS DacFx team:
https://github.com/Microsoft/DACExtensions
The new api (which incidentally is written using T4 templates) makes finding the info you need many many times simpler.
There should be enough information you need in this blog to get you going:
https://the.agilesql.club/Blogs/Ed-Elliott/DacFx-Create-tSQLt-Tests-From-A-Dacpac
The only difference is that you are creating C# and not T-SQL so you won't have to deal with the ScriptDom.
When you do this, please dump it on github it sounds like a really useful project.

To answer this question in the comments:
I can create methods with the correct parameters, but I'm struggling
to find where the objects are in the model are that represent the
content of a stored procedure. I need to know the columns returned by
a SELECT statement in order to generate the return objects. Any ideas?
The referenced objects are provided by the TSqlProcedure.BodyDependencies relationship. That will return objects referenced in the stored proc body, but won't tell you how they are used. The relational model doesn't try to embed this info as it doesn't help in deployment, but you can get it by querying the SQLDOM AST for the procedure.
The AST is a syntax tree defining the actual structure of the Procedure statement, including the structure of the procedur body. What you need to do is:
Create a Visitor that visits SelectStatement nodes (or their children)
Find the column names used in the select
Map these names to names of objects returned by TSqlProcedure.BodyDependencies. Now you have a rich object that can state the table the column is contained in, the column's data type, etc.
Do whatever you need to based on this (for example define a return type with the correct properties matching the column data types?)
A few notes / resources:
Ed's DacpacExplorer will help you view and understand the code.
Dave Ballantyne just added SQLDOM support to DacpacExplorer. Not only will this help you see what statements you need to match in the visitor, you should also look at how they use loadAsScriptBackedModel (see this commit) to ensure you have the full AST for the procedure body. Without this you would just get the body as one SqlScript object which isn't much use to you.
Further examples of the visitor pattern are Dave's TSqlSmells and the DacExtensions project
Twitter is an easy way to contact Ed, Dave and me if you are blocked :-)

Deserializing Json string to C# Class object or DataSet. Which is more efficient?

I am using JSON.Net to deserialize a JSON string to object. My JSON string consists of huge data which can be loaded onto an array or dataset. Could someone please let me know which of the below appraoch is more efficient for the same.
var CSharpClassObject = JsonConvert.DeserializeObject<CSharpClass[]>(jsonString);
and
var dataSetObject = JsonConvert.DeserializeObject<DataSet>(jsonString);

Datasets are generally inefficient due to the memory they require, as well as events, etc. They are really suited to RAD (Rapid Application Development) and not too much else. For your purposes (and probably most others) I would certainly suggest using a custom type.

DataTable vs. Collection in .Net

I am writing a program that needs to read a set of records that describe the register map of a device I need to communicate with. Each record will have a handfull of fields that describe the properties of each register.
I don't really need to edit or modify the data in my VB or C# program, though I would like to be able to display the data on a grid. I would like to store the data in a CSV file, or perhaps an XML file. I need to enable users to edit the data off-line, preferably in excel.
I am considering using a DataTable or a Collection of "Register" objects (which I would define).
I prototyped a DataTable, and found I can read/write XML easily using the built in methods and I can easily bind to a DataGridView. I was not able to find a way to retreive info on a single register without using a query that returns a collection of rows, even though I defined a unique primaty key column. The syntax to get a value from a column is also complex, though I could be missing something on both counts.
I'm tempted to use a collection of "Register" objects that I can access via a unique key. It would be a little more coding up front, but seems like a cleaner solution overall. I should still be able to use LINQ to dataset to query subsets of registers when I need them, but would also be able to grab a single field using a the key value, something like this: Registers(keyValue).fieldName).
Which would be a cleaner approach to the problem?
Is there a way to read/write XML into a Collection without needing custom code?
Could this be accomplished using String for a key?
UPDATE: Sounds like the consensus is towards the Collection of register Objects. Makes sense to me. I was leaning that way, and since nobody pointed out any DataTable features that would simplify acessing a single row, it looks like the Collection is clearly the way to go. Thanks to those who weighed in.

I would be inclined not to use data sets. It would be better to work with objects and collections. Your code will be more maintainable/readable, composable, testable & reusable.
Given that you can do queries on the data set to return particular row, you might find that a LINQ query to turn the rows into objects may be all the custom code that you need.
Using a Dictionary<string, Register> for look ups is a good idea if you have a large number of items (say greater than 1000). Otherwise a simple LINQ query should be fine.

It depends on how you define 'clean'.
A generic collection is potentially MUCH more lightweight than a DataTable. But on the other hand that doesn't seem to be too much of an issue for you. And unless you go into heavy reflection you'll have to write some code to read/write xml.
If you use a key I'd also recommend (in the case of the collection) to use a Dictionary. That way you have a Collection of the raw data and still can identify each entry through the key in the Dictionary.

I usually use datatables if its something quick and unlikely to be used in any other way. If it's something I can see evolving into an object that has its own use within the app (like your Register Object you mentioned).
It might be a little extra code up front - but it saves converting from a datatable to the collection in the future if you come up with something you would like to do based on an individual row, or if you want/need to add some sort of extra functionality to that element down the road.

I would go with the collection of objects so you can swap out the data access later if you need to.

You can serialize classes with an xml serializer and defining a Serialize attribute or something like that (it has been a while since I done that, sorry for the vagueness). A DataSet or DataTable works great with XML.
Both DS and DT have ReadXml and WriteXml methods. XML must be predefined format, but it works seamlessly.
Otherwise, I personally like collections or dictionaries; DS/DT are OK, but I like custom objects, and LINQ adds in some power.
HTH.

Linq to DataTable without enumerating fields

i´m trying to query a DataTable object without specifying the fields, like this :
var linqdata = from ItemA in ItemData.AsEnumerable()
select ItemA
but the returning type is
System.Data.EnumerableRowCollection<System.Data.DataRow>
and I need the following returning type
System.Data.EnumerableRowCollection<<object,object>>
(like the standard anonymous type)
Any idea?
Thanks

If I understand you correctly, you'd like to get a collection of objects that you don't need to define in your code but that are usable in a strongly typed fashion. Sadly, no you can't.
An anonymous type seems like some kind of variant or dynamic object, but it is in fact a strongly typed class that is defined at compile time. .NET defines the type for you automatically behind the scenes. In order for .net to be able to do this, it has to have some clue from the code with which to infer the type definition. It has to have something like:
from ItemA in ItemData.AsEnumerable()
select ItemA.Item("Name"), ItemA.Item("Email")
so it knows what members to define. There's no way to get around it, the information has to logically be there for the anonymous type to be defined.
Depending on why exactly your are trying to do this, there are some options.
If you want intellisense while still encapsulating your data access, you can return xml instead of a datatable from your encapsulated data access class. (You can convert data tables to xml very easily. You'll want to use the new System.Xml.Linq classes like the XElement. They're great!) Then you can use VS2008's ability to create an xsd schema from xml. Then use/import that schema at the top of your code page, and you have intellisense.
If you have to have an object an with properties for your data, but don't want to define a class/structure for them, you'll love the new dynamic objects coming in C#4.0/VB10. You have object properties based on what the sql returns, but you won't have intellisense. There is also a performance cost to this, but (a) that might not matter for your situation and (b) it actually is not so bad in some situations.
If you're just trying to avoid making a lot of classes, consider defining structs/structures on the same code file, beneath your class definition. When you add more columns to your result set, it's easy to adjust a struct with more public fields.
In short you can have any two of the following three: (a) dynamic, (b) strontly-typed objects, (3) intellisense. But not all three.

There is one way to accomplish what you want, but it required knowledge of dynamic linq. You would build the query during run-time and then use it. I am no expert and have never really played around with it, but here is a link to Scott Guthrie's blog about it - Dynamic Linq. Hope that helps.
Wade

The best way to store class instances to a file/database

What is the best way to store instances of a class to file/database?
We have a base class called Command and loads of derived classes.
Users create instances of these classes by adding commands to a graphical designer
where they can configure them. (Set the properties).
We then need a way to store these "commands" to a file without losing
any information.
One idea was to use db4o, but the GPL license is not acceptable for this project.
Any suggestions or code samples?
Update:
(In order to "de-blurryfie" my question :p)
The generated code might look something like:
command[i++] = new DelayInSecondsCommand(2);
command[i++] = new DaliRequestCommand(1, false, 254);
command[i++] = new DaliRequestCommand(2, false, 254);
command[i++] = new DaliRequestCommand(3, false, 254);
command[i++] = new WaitInSecondsCommand(2);
command[i++] = new DaliRequestCommand(1, false, 0);
command[i++] = new DaliRequestCommand(2, false, 0);
command[i++] = new DaliRequestCommand(3, false, 0);
command[i++] = new JumpCommand(0);
But then with loads of different commands.
I know it's possible with .NET serialization, altough I've never used it before,
but I was wondering if there are better alternatives, like I said db4o seems nice but the license doesn't fit the project.
Update 2:
Thank you for the replies. I'll probably go with the serialization solution now,
but I'll look into the other options as well. F.Y.I. data is stored in a SQL Compact database.

Are you trying to save the data in tables? or as blob/clob data? Since you mention files, I assume the latter: any of the standard .NET serializers should be fine - they all support inheritance etc. I'd consider for DataContractSerializer, as this combines the field-level support (like BinaryFormatter), and the assembly-independence of XmlSerializer.
You could also consider more esoteric things like protobuf-net.
So: what is it you need to do that won't work under the standard serializers?

serialization does the trick! Serialization is nothing more than converting an object or a connected graph of objects into a stream of bytes (in order to persist the current state of the object). This can be a binary stream, XML or whatever. You don't have to do this conversion by your own since .Net has great support for serialization. Once you serialized an object, you are free to store this data to a file or database. Likewise, a stream of bytes representing a serialized object can be deserialized into an object which will have the same state as the original one.
Btw: Once you have a serialized stream of bytes, you can apply some more functions on it, e.g. compression or encryption.

Pretty blurry question, why don't you just use .NET's built-in serialization possibilities (e.g. XmlSerializer).

db40 also provides a commerical license but it has been recently bought by versant so maybe you may want to look at that. This sort of database is known as object orientated database and is a way of creating persistant instances of classes which is very different to relational databases that work using tables.
This (wikpedia.org) is a good read on object orienated databases and this (also wikipedia) is a list of some of the available options.
In my opinion object databases are much better & more powerfull than relational and I will only use relational databases like mysql if I really have to (not very often).
I would recommomend you watch these videos and download the trial.

Serialization is a great way to store this type of data. See http://blog.paranoidferret.com/index.php/2008/06/20/csharp-tutorial-xml-serialization/

There is http://www.neodatis.org. Its LGPL, but the time I used there was only a implementation for Java. Now, there's a "beta" release for C#, but I didn't tested.