Updates, please don’t do that…

Using a MySQL DOT-Net Conncetor and getting these error messages? Shared Memory Provider: No Process is on the other end of the pipe. Error 0. Unable to find the request .NET Framework Data Provider. It may not be installed. Or your login not working, but your password is right? Try this solution.

Using Visual Studio 2010, it’s possible to use MySQL databases. The trick is to use the MySQL DotNET Connector.

Everything was going swimmingly until for what appeared to be no reason, until one day I went to work on my project and I started getting a strange error message for what appeared to be no reason.

Shared Memory Provider: No Process is on the other end of the pipe.
Error 0.
Unable to find the request .NET Framework Data Provider. It may not be installed.

Exploring the exception shows that a connection to the database is made, but the login has failed for the username. However, the username and password work when logging in using the MySQL client. No drivers have changed, and MySQL works with all other applications just fine, just not the Microsoft development IDE. The connection string validated in a test environment, as did a raw connection with the MySqlConnection. EntityFrameworks, not so much.

Attempting to use EntityFrameworks from VS2010 results in an error dialog box that when dismissed goes back to the database wizard that brings up the dialog box again; the only way out is using Task Manager and violently killing the IDE’s process.

Attempting to use the .MySQL .NET/Connector installer to repair the installation doesn’t help, either. Yes, it updates the .dll files, yes it tweaks the registry, but no, it doesn’t help.

Making a new project and creating a new ADO.NET Data Model reveals something interesting: the MySQL providers are not listed anymore in VS2010.

The solution is to UNINSTALL the DotConnector and then re-INSTALL the same MySQL .NET/Connector.

The full installer indicates that it updates the VS2008 and VS2010 development environments. Trying the IDE again works perfectly. The ADO.NET Data Model shows the MySQL Data Provider, the Entity Frameworks doesn’t get stuck in an endless loop, and my code worked again without change.

What happened to cause all this? Turns out I had installed a minor VS2010 hotfix service pack at the end of the weekend. The result? The update silently uninstalled all non-Microsoft data providers.

Updates, please don’t do that…

Clearly, I’m not happy about that. Especially since it did it silently. If it told me that it was going to, or if it asked me to reinstall after the fact, I could live with it.

Defined in Multiple Assemblies

The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias … mscorlib.dll and System.Core.dll. SOLVED!

Today I migrated a C#/WPF project in Visual Studio 2010 from .NET 3.5 SP1 to .NET 4.0. Immediately the compile failed issuing this set of errors:

  • The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias; using definition from ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’
  • The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias; using definition from ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll’

To resolve this error involved understanding a little bit more about C#, .NET, and the Common Language Runtime (CLR).

According to C# 4.0 In A Nutshell from O’Reilly Press, on page 181 it says:

Some of the .NET types are used directly by the CLR and are essential for the managed hosting environment. These types reside in an assembly called mscorlib.dll and include C#’s built in types, ….

At a level above this are additional types that “flesh out” the CLR-functionality, …. These reside in System.dll, System.Xml.dll, and System.Core.dll, and together with mscorlib the provide a rich programming environment….

So mscorlib and System.Core are both needed. This begs the question, why is Func declared in both and thus causing a conflict? Or is it?

Further on in C# 4.0 In A Nutshell from O’Reilly Press, on page 183 in a general note it says:

A notable exception is the following types, which Framework 4.0 have moved from System.Core to mscorlib.dll:

  • The Action and Func delegates

This suggests a case exists where mscorlib is from our current .NET (the later one has Func), and System.Core is coming from the old one (which is where Func lives for that version).

How is this possible? It’s our projects fault.

This question on StackOverflow provides some insight; check out Simon‘s answer.

  1. Right-click the project and select Unload Project
  2. Right-click the project again and select Edit Project
  3. Scroll down in the XML to find the ItemGroup element; it’ll have Reference elements insider of it.
  4. Locate the Reference element that has Include=”System.Core” as an attribute.
  5. If it has other qualifiers, remove them. If it has a TargetFrameworkVersion subelement remove it.
  6. Save the XML.
  7. Right-click the project and reload it; try a build now.

In my case, I had an entry that looked like this:

<ItemGroup>
  <Reference Include=”System.Core”>
    <TargetFrameworkVersion>3.5</TargetFrameworkVersion>
  </Reference>
</ItemGroup>

Removing the TargetFrameworkVersion, shown in red above, un-pinned the dll from the older .NET framework and things worked just fine.