I have a dataset (*.xsd) in App_Data with table adapters. I needed to change one of these adapters because of the new fields in my database. The current one has been working fine for months.

I load up the xsd and try to preview data off of one of the adapters.

datasetname.tableadaptername.Fill,GetData () could not be previewed.

Unable to find connection 'tbmposConnectionString' for object 'Settings'. The connection string could not be found in application settings, or the data provider associated with the connection string could not be loaded.

Confused, I create another dataset. Add a table adapter using the default choices. The connection string is already preloaded from my web.config file. I can preview data for this table adapter and everything works fine.

I save the new dataset and recompile. I get an error!

The custom tool 'MSDataSetGenerator' failed. Unable to convert input xml file content to a DataSet. Requested value 'Properties' was not found.

Error 27 Custom tool error: Failed to generate code. Unable to convert input xml file content to a DataSet. Requested value 'Properties' was not found. Requested value 'Properties' was not found. C:\work\tbm\TbmPOS\App_Data\DataSet1.xsd 1 1 TbmPOS

My old XSD had a connection string like this:
<Connection AppSettingsObjectName="Settings" AppSettingsPropertyName="tbmposConnectionString" ConnectionStringObject="" IsAppSettingsProperty="True" Modifier="Assembly" Name="tbmposConnectionString (Settings)" ParameterPrefix="@" PropertyReference="ApplicationSettings.TbmPOS.Properties.Settings.GlobalReference.Default.tbmposConnectionString" Provider="System.Data.SqlClient">

My new XSD has a connection string like this:
<Connection AppSettingsObjectName="Web.config" AppSettingsPropertyName="TbmPOS.Properties.Settings.tbmposConnectionString" ConnectionStringObject="" IsAppSettingsProperty="True" Modifier="Assembly" Name="TbmPOS.Properties.Settings.tbmposConnectionString (Web.config)" ParameterPrefix="@" PropertyReference="AppConfig.System.Configuration.ConfigurationManager.0.ConnectionStrings.TbmPOS.Properties.Settings.tbmposConnectionString.ConnectionString" Provider="System.Data.SqlClient">

My guess is something changed since VS.NET 2005 SP1 and that explains the XSD file is not the same. In addition, I also guess that MSDataSetGenerator is not the right version to be compatible with the new tool. Can you give me any pointers?

I tried what I found here:
http://www.thescripts.com/forum/thread501733.html
"In the custom tool for the xsd or xml remove the custom tool (cut and paste routine) (in the properties window) and paste the tool name back into the custom tool text space.
I have been coding a project for 4 weeks and today out of the blue my project gave me the same error and after looking on the internet to no avail I happened on this fix accidentaly"

I saw a flicker in the UI and the error message went away, but I recompiled later and it did not work and no longer wants to work.

1. VS 2005 SP1
2. Windows 2003 EE
3. Admin
4. IE7
5. This project used the web application project (WAP) beta for vs.net 2005 until SP1 was released.
6. C#

Let me know if there is anything I can do to work around this problem.

I have a very similar problem.  Dataset working fine for months, than all of a sudden, I make a seemingly innocuous change and all of a sudden this:  Any ideas?

Custom tool error: Failed to generate code. Unable to convert input xml file content to a DataSet. Requested value 'My' was not found. Requested value 'My' was not found.

I'm running Windows Vista Ultimate Edition and Visual Studio 2005 SP1

Thanks
Chad
 

I am having exactly the same problem.

I can't believe that VS 2005 SP1 can have completely broken typed datasets (.XSDs) for all development sites!?

The new graphical editor breaks files; it generates stuff that the external tool doesn't understand.  I just loaded up the XSD in notepad++ and modified it there directly, using the great art of copy-paste. Thankfully, I only had to add a field, but I can imagine the pain when a bigger task needs to be performed.

By the way, am I the only one who thinks that the Reporting Services report creator (that requires typed datasets, if I recall) is horrible when it comes to maintenance? If you change your typed dataset, it will create another datasource in your document so you have to go manually and edit the RDLC files as well. I also discovered the other day that the reporting services viewer calls all public properties of all objects in a ObjectDataSource even if they aren't used ? (actually, more like a generic List<MyCustomObject> than an ObjectDataSource). In my context, I had to hide those fields from reporting services if they aren't used because some return an image (byte[])  that takes a while to generate. I use this image in some reports, some not. I was having a performance hit even on the reports that didn't use this field. In any case, enough rambling.

Basically, I feel that every time I go off the beaten path with VS.NET, I get screwed :)

This time, it isn't as bad as last summer right after a fresh VS.NET install:

http://www.flickr.com/photos/49822479@N00/212238011/

(good for a laugh)

So Jason, you are of the opinion that it is the Graphical tool screwing up the .XSD rather than the MSDataSetGenerator not producing a correct C# dataset class from the .XSD?

Thing is, I made a change by adding a new "Query" to the TableAdaptor (which broke Dataset designer/MSDataSetGenerator) and using VSS compared the before and after files. No changes were made to the .XSD file other than the definition for the added query and the ConnectionString change which I had to make (prefixing old name with <namespace>.Properties.Settings )which I have seen discussed elsewhere.

Can you please confirm that you did the following:

1) Went back to the last known version of .XSD that worked

2) Opened the .XSD in Notepad, made and saved a change

3) Did a "Run Custom Tool" from Solution Explorer on the .XSD to generate the <Dataset>.Designer.cs file?

That is correct. The prefix generated by the UI broke the custom tool so I loaded up the XSD and

added this in one portion:

              <Mapping SourceColumn="Tax1" DataSetColumn="Tax1" />
              <Mapping SourceColumn="Tax2" DataSetColumn="Tax2" />
              <Mapping SourceColumn="Tax3" DataSetColumn="Tax3" />
              <Mapping SourceColumn="Tax4" DataSetColumn="Tax4" />

and this elsewhere:

              <xs:element name="Tax1" msprop:Generator_UserColumnName="Tax1" msprop:Generator_ColumnPropNameInRow="Tax1" msprop:Generator_ColumnVarNameInTable="columnTax1" msprop:Generator_ColumnPropNameInTable="Tax1Column" type="xs:boolean" minOccurs="0" />
              <xs:element name="Tax2" msprop:Generator_UserColumnName="Tax2" msprop:Generator_ColumnPropNameInRow="Tax2" msprop:Generator_ColumnVarNameInTable="columnTax2" msprop:Generator_ColumnPropNameInTable="Tax2Column" type="xs:boolean" minOccurs="0" />
              <xs:element name="Tax3" msprop:Generator_UserColumnName="Tax3" msprop:Generator_ColumnPropNameInRow="Tax3" msprop:Generator_ColumnVarNameInTable="columnTax3" msprop:Generator_ColumnPropNameInTable="Tax3Column" type="xs:boolean" minOccurs="0" />
              <xs:element name="Tax4" msprop:Generator_UserColumnName="Tax4" msprop:Generator_ColumnPropNameInRow="Tax4" msprop:Generator_ColumnVarNameInTable="columnTax4" msprop:Generator_ColumnPropNameInTable="Tax4Column" type="xs:boolean" minOccurs="0" />

I then ran the custom tool and it generated a *.Designer.cs. (I guess I renamed something and forgot to delete it because I have a new viewWhatever.Designer.cs and an old viewWhatever1.Designer.cs) 

Comparing the two files, I see only a few changes here and there to support my new fields. I did not use the visual tool at all.

Btw, I looked at my SVN logs to get to these conclusions and diffed the files.

Now, I spent lots of time trying to change my old XSD to make it work with the new connectiong string stuff generated by the UI, but that didn't amount to anything.

OK, I think I have found the solution.

The problem appears to be entirely to do with the format of the connection string which somehow appears in the "new" .XSD version.

 My old connections string of the form:

<Connection AppSettingsObjectName="Settings" AppSettingsPropertyName="ArcTimeConnectionString" ConnectionStringObject="" IsAppSettingsProperty="True" Modifier="Assembly" Name="ArcTimeConnectionString (Settings)" ParameterPrefix="@" PropertyReference="ApplicationSettings.ArcTime.Properties.Settings.GlobalReference.Default.ArcTimeConnectionString" Provider="System.Data.SqlClient">

became "replaced with" a new connection string of the form:

<Connection AppSettingsObjectName="Web.config" AppSettingsPropertyName="ArcTimeConnectionString" ConnectionStringObject="" IsAppSettingsProperty="True" Modifier="Assembly" Name="ArcTimeConnectionString (Web.config)" ParameterPrefix="@" PropertyReference="AppConfig.System.Configuration.ConfigurationManager.0.ConnectionStrings.ArcTimeConnectionString.ConnectionString" Provider="System.Data.SqlClient">

 I simply used Notepad to edit the .XSD and put the old connection string back in place of the new one.

Also edited web.config to make sure that the connection is called ArcTimeConnectionString and not ArcTime.Properties.Settings.ArcTimeConnectionString

Dont understand what has gone on here, or what if anything I may have broken by doing this, but at least the Dataset Designer works, the Designer.cs file is built, I can modify the Dataset and the code builds!

 Then selected the TableAdapter and made sure that the Connection property

I hit the same problem today. I was trying to add a new database table to a project that's been around for about three years and couldn't understand why the new tableadapter class was not appearing in Intellisense. Then I noticed that the designer class had been deleted. I tried this again but decided to try opening the designer before configuring the adapter. This gave the message about "Properties" and also a spurious message about a memory error. This is under Windows 2003. I've found many people hitting this problem and a variety of "fixes". I took the route of removing all connection strings in "settings" and "web.config". I deleted the existing data connection in "data sources" and then created a new dataset. This put the connection string into web.config - funny it used to ask if I wanted it to automatically go into "settings", but not any more.On all of the other datasets that use tableadapters I set the "connection" property to "None" on the drop down and then set it to the new connection string property that has "(Web Config)" shown at the end of the string. I'm fortunate in that there were only about a dozen to amend as the tableadapters only went in after .Net 2.0 came along, the rest were regular data adapters and these don't seem to have any problems. The final thing to do was to change to using a ConnectionStringSettingCollection to get at the connection strings in web.config instead of using the class.properties.settings["connectionName"].connectionstring:

I guess that this is going to upset a whole load of folk. It's wasted half of my day.

A Simple Solution

Ok, I have searched about this and no word from Microsoft still. This is a big problem, but I was able to come up with a fix.

My solution uses a Table Adapter Base. In the constructor for this base class, it creates a connection string and assigns it to _connection (using reflection).

So in order to use it:

1. In the DataSet Designer, use a connection string that is not in the settings class. (This is the only way I got the designer to work without throwing expections).
2. Add the TableAdapterBase and configure for your connection string and your namepace, etc.
3. In the DataSet Designer, set the Base class to TableAdapterBase for each Table Adapter

Explanation:

I could only get the DataSetDesigner to work when I did not use a connection string that was in the settings or config files. In fact it would not even list any of those connection strings in the designer. So I just created a new connection string (or use one from Server Explorer). Now the designer worked, but it also hard coded the connection string in the xsd and designer.cs files. So this is the connection string that will be used at design time. The base class only works at run time and will override that connection string with whatever you specify in the base class.

In order to change the connection string at run time:

1. Open the data set designer
2. Select a Table Adapter
3. Go to properties window
4. Expand Connection
5. Edit ConnectionString

This will change the connection string for all the table adapters (assuming you set them all to use the same connection string in the first place).

In order to change the runtime connection string, just modify in your web.config like normal. Also, if you need to use multiple connection strings for different tables, then just create another _TableAdapterBase for each connection string and set the Base class in the designer.

Code:

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
using System.Data.Common;
using System.ComponentModel;

namespace TableAdapterNamespace
{
	public class TableAdapterBase : Component
	{
		public TableAdapterBase()
		{
			FieldInfo _connectionField = this.GetType().GetField( "_connection",
				BindingFlags.GetField |
				BindingFlags.Instance |
				BindingFlags.NonPublic );

			if( _connectionField != null )
			{
				DbConnection connection = new System.Data.SqlClient.SqlConnection();
				connection.ConnectionString = SettingsConnectionString;
				_connectionField.SetValue( this, connection );
			}
		}

		public static string SettingsConnectionString
		{
			get
			{
				return global::ProjectNamespace.Properties.Settings.Default._ConnectionString;
			}
		}
	}

}

Whoever said we can't modify a private field

rlove:

In order to change the connection string at run time:

1. Open the data set designer
2. Select a Table Adapter
3. Go to properties window
4. Expand Connection
5. Edit ConnectionString

Should be:

In order to change the connection string at design time:

I've torn out at least a third of my hair over the past three days trying to figure this out. Thanks guys.

I ended up using an even simpler solution: just make a new connection string and select it in the table configurations in the designer.

I hope they fix this really, really soon.

Ergh... it's back! And nothing seems to be working this time.

I think I'm gonna cry...