System.ComponentModel.Component in Visual Studio 2008

The "replacement" is either using typed DataSets (use "Add->New Item" and choose DataSet, then drag tables, views or stored procedures onto the design surface). Or Entity Framework / LINQ to Entities.

And, yes, this changed in VS2005.

A little research has left me wondering, because "it works for me".

Open a simple class library project
Right-click and choose "Add -> Component". The component is created and the familiar component design surface is displayed.
View the toolbox. Note that SqlCommand, etc. aren't on it. Right-click the toolbox and choose "Choose Items".
Type "System.Data" in the filter box. It will help you find all your old friends, "SqlConnection", "SqlCommand", "SqlDataAdapter", and even "DataSet" and "DataView". Select them all and click "Ok".
Drag a SqlConnection onto the design surface. Configure it as normal.
Drag a SqlCommand onto the design surface, configure as normal. I even set the Connection property to point to my first SqlConnection.
Drag a "SqlDataAdapter" onto the design surface. The normal "Configure DataAdapter" dialog will appear. Configure the adapter, choose "Create DataSet", etc.
Save the Component and then close it.
Open the component again. All those pieces are still present.

What was it you tried that didn't work?

We are, indeed, using typed DataSets. What I'm referring to is not the data transport object (DataSet) but the data access (Component Class). Previously, you could drop adapters, connections, commands, etc. out of the Server Explorer onto the Component Class Surface. Now, you cannot. I'm looking for a replacement for that, rather than the data transport object.

Mark A Johnson 2009-05-13 14:08:02

I, indeed, meant typed DataSets. The new DataSet designer will create a strongly-typed TableAdapter class, which does what the DataAdapter class used to do, but in a strongly-typed manner. Try what I suggested. New DataSet, drag tables and drag stored procedures. Look at generated code. See what's there.

John Saunders 2009-05-13 15:56:09

Ah, my confusion came from your use of "typed DataSets", which can be used, and typically are, without the TableAdapters. Knowing that you really meant TableAdapters clears it up for me, although it doesn't really answer my question yet. I'm more interested in how the use of the Component Class has changed for data access than I am in re-architecting my solution yet.Any idea how or when the Component Class changed with respect to database objects?

Mark A Johnson 2009-05-13 16:27:21

Ah, your research is very helpful. I'll try to recreate that. What didn't work for me is dragging items (stored procs, e.g.) directly out of the Server Explorer. I'll try the manual creation by dragging on the controls from the toolbox. Thanks!

Mark A Johnson 2009-05-13 18:57:17

Seriously, the DataSet Designer isn't what it used to be. Try dragging onto a newly-created DataSet. Drag a table and drag an SP that returns a result set and one that does not. Preferably use SPs that have parameters. Then go look at the generated code and see what you think. It's not nearly as bad as it used to be, and the semantics are not that far off. It's like wrapper code you probably already have to wrap DataAdapter.Fill.

John Saunders 2009-05-13 19:06:52

It's not so much that the code might be ugly. It's that we have a very large application we're maintaining. While the code might be better than the old, the effort to re-architect that portion of the app (dozens of data access classes) might not be worth the upgrade.

Mark A Johnson 2009-05-13 19:21:16

No big deal if it's too expensive. I don't like Typed DataSets anyway. When you get around to upgrading your DAL, I'd use Entity Framework and LINQ to Entities. I mentioned typed datasets because they are so close to what you've already got, not because they're such a wonderful technology.

John Saunders 2009-05-13 22:23:57

ansaurus

tags:

views:

answers:

System.ComponentModel.Component in Visual Studio 2008

related questions