none
'DataSource' is ambiguous in the namespace 'MSDATASRC'

    Question

  • I am new to VB.Net and am in the process of upgrading a VB6 enterprise application (I know, about time).   I have read other posts dealing with this same and similar titles but still have not found a solution to my problem.   I am using VS 2008.

    I know I need to convert to ADO.NET, but am trying to get this project at least working and then convert sections at a time as we are able to dedicate the time.   My project has an ADO data control and a hierarchical flexgrid control and the upgrade wizard generated this code in MyformA.Designer.vb in the Declarations section:

    Public WithEvents AdodcCust As VB6.ADODC  

    Public WithEvents msgCustomer As AxMSHierarchicalFlexGridLib.AxMSHFlexGrid

    The AdodcCust definition was accompanied by the error message:

    Error        21        Reference required to assembly 'MSDATASRC, Version=7.0.3300.0, Culture=neutral,

    PublicKeyToken=b03f5f7f11d50a3a' containing the implemented interface 'msdatasrc.DataSource'.

    Add one to your project.

    I did that, finding a reference named msdatasrc in the .NET tab of references, and referencing the file in c:\Program Files (x86)\Microsoft.Net\Primary Interop Assemblies\msdatasrc.dll

    The upgrade wizard also created the following in MyformA.Designer.vb:

    #Region "Upgrade Support"
        Public Sub VB6_AddADODataBinding()
            msgCustomer.DataSource = CType(AdodcCust, msdatasrc.DataSource)
        End Sub
        Public Sub VB6_RemoveADODataBinding()
            msgCustomer.DataSource = Nothing
        End Sub
    #End Region

    The bold text "msdatasrc.DataSource" is now generating the error message in the title of this post.

    Looking in Object Browser, I find 2 entries for msdatasrc.   the first references Interop.MSDATASRC that I find in my project files under obj\debug\interop.msdatasrce.dll.   The second entry references the PIA file I added above.

    If I remove the Interop.MSDATASRC file, then I generate tons of error messages indicating I need to add a reference for the assembly 'Interop.MSDATASRC, version 1.0.0.0...'  

    I feel like I should be able to fully qualify something to resolve this ambiguity, but nothing I try syntactically is working.  When I try to add an Imports alias to Interop.MSDATASRC, it generates an error saying the namespace or type specified doesn't contain any public member or cannot be found.  How do I specify which assembly to use?  Is there any hope of resolving this conflict without starting from scratch, which I would rather not do?

    Sorry for the long post - just hoping to provide as much info as possible.   Appreciate any advice for this novice.


    • Edited by GreydogMe Wednesday, April 19, 2017 5:59 AM added space for readability
    Wednesday, April 19, 2017 5:58 AM

Answers

  • I was finally able to resolve the ambiguous namespace reference by following the advice in this post which thankfully had very specific details.

    I am now getting a COMException related to the datasource, but at least the advice from JimBrown helped with the initial ambiguity problem.   On to the next.

    Thanks again for your input Acamar.   It was your link from another post that sent me to JimBrown's solution.

    Sunday, April 23, 2017 9:30 PM

All replies

  • When I try to add an Imports alias to Interop.MSDATASRC, it generates an error saying the namespace or type specified doesn't contain any public member or cannot be found.  How do I specify which assembly to use?

    Don't try to resolve this using Imports - it is useful when you know what the namespaces are, but it only confuses things when you are trying to work it out.  Fully qualify the names in your code, at least until the issue is resolved.

    When you qualify the names, you need to use the namespace, which is not necessarily the same as the assembly name.  If you search all files for "MSDataSrc" you should be able to find the one declared in the VB6 conversion code.  When you find the declaration you should be able to determine from the code what the fully qualified name is, and apply it as required.  That may be sufficient for the compiler to disambiguate all other references.  Otherwise you need to examine c:\Program Files (x86)\Microsoft.Net\Primary Interop Assemblies\msdatasrc.dll to determine the fully qualified name.  See, for instance:  http://www.dependencywalker.com/

    • Proposed as answer by Cor Ligthert Wednesday, April 19, 2017 10:53 AM
    Wednesday, April 19, 2017 7:02 AM
  • Hi GreydogMe,

    Since this forum is discussing and asking questions about the Visual Basic programming language, IDE, libraries, samples, and tools (Not for VB6 questions). And your issue is more related to VB6. This link about vb6, please refer that: http://www.vbforums.com/forumdisplay.php?1-Visual-Basic-6-and-Earlier

    Thank you for participating in the forum activities.

    Best Regards,

    Cherry Bu



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    No it is not VB6, the OP said very well he is using VB.Net. That is the problem with many moderators, it seems they are paid per message and don't read the complete message but after a word which they know they start typing.

    Success
    Cor


    Wednesday, April 19, 2017 10:53 AM
  • Thank you for the support, Cor.   And thank you very much for the reply Acamar.  

    I followed your advice and searched all files in my solution for msdatasrc.   The only results were all the places similar to the one above where a datasource is being assigned:

    msgCustomer.DataSource = CType(AdodcCust, msdatasrc.DataSource)

    I didn't find a declaration of any sort.  Perhaps that is my problem?

    I then opened the PIA file with Dependency Walker with the following results.   Unfortunately, am not sure what I am looking for here.

    Back to the Object Browser, here are the 2 assemblies and their redundantly named namespace

    and

    Am I looking for a higher level namespace ahead of MSDATASRC?   Or do I just need to somehow tell my code which assembly I am trying to use?

    Thanks again.

    Wednesday, April 19, 2017 11:01 PM
  • Thank you for the support, Cor.   And thank you very much for the reply Acamar.  

    Dependencywalker should be able to show the namespaces used within that DLL, but perhaps that feature does not exist.   The object browser is showing the same thing, but it seems with insufficient detail.  The first one appears to have a fully qualified name Interop.MSDATASRC, but the browser is not showing you the fully qualified name of the second one.  The default namespace is the project name, so I would consider referencing is at MSDATASRC.MSDATASRC and see if that finds it.   Unless, of course, the object browser reveals a namespace at the top of the dependency tree, which has been chopped of in your image.

    It is also possible that the ambiguity is because there is already a MSDATASRC in the GAC.  See:
    https://msdn.microsoft.com/en-us/library/9x295t9k%28v=vs.110%29.aspx


    • Edited by Acamar Thursday, April 20, 2017 12:51 AM sp
    Thursday, April 20, 2017 12:51 AM
  • Ya the hierarchy in the Object Browser is what is stumping me too (among other things).    The first reference shows Interop.MSDATASRC as the Assembly and MSDATASRC as the Namespace.   the second one has the same 3-tiered structure starting with the assembly name (MSDATASRC) followed by the Namespace (msdatasrc).   What is cut off in the image is just another assembly, with nothing at the top of the tree.   Each tree node is an assembly.   I had tried referencing the interface Datasource as msdatasrc.msdatasrc.DataSource, as Interop.MSDATASRC.DataSource, Interop.MSDATASRC.msdatasrc.DataSource and probably a few others, including case-sensitivity before I came for help.   They all come back with "type xxx is not defined" messages.  Would case matter here?

    Without knowing enough, it seems, and you confirmed in your first response, that I should be qualifying with the namespace, not the assembly.   so it seems that with both these assemblies having MSDATASRC as a namespace, I have to find a way to distinguish the assembly I need.  

    Do I need to load the assembly?   Assembly.Load using the full name?   I have looked at that but again got lost in the syntax.   If I do have an assembly object, what do I do with it?

    Something like this:

    Imports System.Reflection
    Module Example
       Public Sub Main()
          Dim longName As String = "system, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
          Dim assem As Assembly = Assembly.Load(longName)
          If assem Is Nothing Then
             Console.WriteLine("Unable to load assembly...")
          Else
             Console.WriteLine(assem.FullName)
          End If
       End Sub
    End Module
    ' The example displays the following output:
    '       system, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

    Thanks again!

    Thursday, April 20, 2017 2:41 AM
  • I was finally able to resolve the ambiguous namespace reference by following the advice in this post which thankfully had very specific details.

    I am now getting a COMException related to the datasource, but at least the advice from JimBrown helped with the initial ambiguity problem.   On to the next.

    Thanks again for your input Acamar.   It was your link from another post that sent me to JimBrown's solution.

    Sunday, April 23, 2017 9:30 PM