Trying to upgrade a solution from 2008 to 2010. And I suddenly get a lot of ambiguous reference errors compiling in VS 2010.
It works fine in 2008. Is VS 2010 more strict regarding the using directives?
I had a similar issue.
I dont think it is stricter, but more a coincidences of the newer framework now having the same class name I was using in the dlls referenced, either things were moved or there was some new development to existing dlls.
It took some time to fix the entire project, but the ways around it I found were:
To use either define the full location of the classes
or
define an alias:
using CompanyMagic = Core.Company.Magic;
have you references to two different dll-versions of the same assembly in your solution?
For example are you referencing "System.dll from dotnet 2" plus "System.dll from dotnet 4"?
There is a quite similar post on StackOverFlow : Ambiguous reference error in VS2010
From this article, from Richard :
There may be slight changes in lookup rules about how different cases (e.g. identifier in current namespace takes precedence (as in class Program above).
There are two options to disambiguate:
Use fully qualified identifiers, in the above, either System.Action or ConsoleApplication1.Action.
Use a namespace alias to fully qualify the identifier without so much typing:
using MyAction = MyNamespace.Action;
Related
The AutoComplete Function in VS2017 suggests me fully qualified using statements.
I have two projects with following (simplified) structure:
Company.Contracts
IMyExample.cs
Company.Core
MyExample.cs
Now when I use IMyExample in Class MyExample, VS2017 suggests me a using statement like
using Company.Contracts
But I think that there was a time when VS2017 suggested me:
using Contracts
which is sufficient as the projects share the same main namespace.
How can I configure VS2017 so that it prefers simplified instead of fully qualified namespaces? In fact this is the opposite of StyleCop Rule SA1135.
Hint: I was using VS2019 before but switchted back to VS2017 because the test licence ended and I'm pretty sure, that I didn't have to correct my using statements. Maybe in VS2019 this is possible?
Maybe in VS2019 this is possible?
Sorry but the answer could be negative, I test it in VS2019 release 16.3.4 and confirm this behavior is not supported for now.
In your situation, instead of using full qualified names, you can also use the format like Contracts.ClassName.
And for the reason why full qualified namespace is more preferred in this situation, assuming your current project Company.Core references one assembly whose root namespace is also named Contracts, now if VS do what you suggested, add the using Contracts when you use functions from Company.Contracts project, the intellisense would be confused about this. See:
In that situation you suggested, VS intellisense may get confused about what the using Contracts really mean, another assembly whose root namespace is Contracts or Company.Contracts project? So I think this could be one possible reason why it suggests full qualified namespace.
And if you do need one option which supports this behavior, I suggest you can send a feature request here.The team would consider about it if this request gets enough votes.
Hope my answer makes some help:)
I've ran into this issue a couple times and I'm wondering if anyone has a better solution than trial and error or searching stack overflow.
Lets say we are using some .net class Foo
Foo resides in the Bar.Baz namespace
The following statement
using Bar.Baz;
is not sufficient to compile the program, we are missing an assembly reference. So add a reference to System.Bar.Baz It still doesn't work so after searching the internet I find that I actually have to add a reference to Some.Other.dll and now it compiles.
My question is how do I know what namespace maps to what reference when the usual one doesn't work?
Most recent problem was
The type or namespace name 'DbContext' could not be found Instead of adding a reference to System.Data.Entity I had to install through Nuget.
If it is a .NET framework function, you can just search it on MSDN, and it will tell you in which assembly the class/function exists.
You can also use ReSharper which is a very nice plugin to Visual Studio, and it can help you add assemblies automatically.
If you're using Visual Studio 2013 or higher, one easy way to discover which namespace a class belongs to is using the Peek definition feature. You can easily find it in the right-click context menu.
In the screen below, I used it with KeyValuePair:
Also, take a look at the documentation.
So I'm a fledgeling programmer that's been assigned to get to know an application that's been in development (in VS2005, then in 2008) for quite some time. Over the life of the project the naming conventions therein have become somewhat convoluted. For the sake of example, here is a piece of the naming structure.
_MegaCorp.sln
Application_Install
Megacorp
DbResources.csproj
Forms
Megacorp.Forms.Concept.csproj
Properties
Resources
Megacorp
Forms
Concept
xyz.cs
It's maybe not the best way to organize information, but it works fine in VS2008. Updating to VS2010 shouldn't necessitate an overhaul of the existing code, right?
What's happening is this: when xyz calls for DbResources, visual studio is looking in Megacorp.Forms.Concept.Megacorp, not in the parent Megacorp folder. All the proper references and using statements are in order: as I said, everything works fine in VS2008. What's happening here?
Error 826 The type or namespace name 'xxx' does not exist in the namespace 'MegaCorp.Forms.Concept.Megacorp.Forms.Concept' (are you missing an assembly reference?) C:\x\y\c-sharp\Megacorp\Forms\Concept\ConstructEditor.Designer.cs 99 63 MegaCorp.Forms.Concept
UPDATE: If I add global:: before each use of a class in xyz.cs, this resolves the problem. However, there are about 1,000,000 lines of code, and over 400 errors reported by the compiler. I'm sure that if I combed through each of the 400 errors, pasting global:: before each one, more errors would arise. There must be another way to do this, because again, the solution comprises a very functional and in-use application compiled in VS2008.
Thanks for your help!
I had similar issue and found out that it is related to Target Framework. Check if all the added references are of solutions for same Target Framework.
So I am starting to learn C#, like literally just started learning, and coming from a Java background, it doesn't look too bad. However, I have a question. I am following THIS tutorial on using the client-object model. And just starting from the top, I added the references, but using Microsoft.SharePoint.Client; keeps giving me the error that "the namespace 'SharePoint' does not exist in the namespace 'Microsoft', but I clearly see it on the right side panel. So looking at the instructions, the only difference I can think of is that fact that I am using Visual Studio Express and thus do not have the option to choose which framework to use when creating a new project. Other than that, I don't know what the problem might be. Does anyone have any ideas on what else I could be missing or how to correct this problem?
Make sure that the target framework is 3.5 and not 4 i.e for SP2010
Did you add the references to the Microsoft.SharePoint.Client assembly and Microsoft.SharePoint.Client.Runtime assembly as noted near the beginning of that tutorial?
Add required references to the solution.
Make sure that the target framework is 4 for SP2013(3.5 for SP2010).
Did you do this part of the tutorial you mentioned above?
To build the application, you must add references to two assemblies,
Microsoft.SharePoint.Client.dll and
Microsoft.SharePoint.Client.Runtime.dll. Installing SharePoint
Foundation installs these assemblies on the server. The two assemblies
are located in the following directory:
%ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\ISAPI
Take a look at the references in your project and make sure you have the reference to the assembly. If it is not there try adding it, right click -->add reference and find "Microsoft.SharePoint.Client"
Thanks to those who mentioned the 4.0 framework.
Mine defaulted to .NET Framework 4 Client Profile (and I have no idea what that means), and the Namespaces looked good in Intellisense, but the build would say they weren't found! Crazy.
for anyone developing for SP2019, you need to target .net 4.5
I'm trying to use my 'context' object in a using statement. It works on one project, but on another, I'm getting the following error.
'...': type used in a using statement must be implicitly convertible
to 'System.IDisposable'
When I'm referring to the 'context' object, I'm referring to the object automatically created when you're working with LINQ to SQL.
The class I'm working within, implements another interface, could that be screwing up this context object?
using (TGDC context = new TGDC())
{
}
the word
using
has the red squigly line under it (error).
You should add a reference to System.Data.Linq. I suspect that's the issue.
Or, if you are using Entity Framework, make sure you have a reference to System.Data.Entity and System.Data.Objects (C#: using / VB.NET: Imports).
Add a reference to the EntityFramework.dll assembly that is referenced by the project that defines your EF context class.
Add a reference to the EntityFramework assembly
This is an older question, but since I found it via a Google search:
I've experienced this while working with a website that worked without issue in Visual Studio 2010.
There's something odd about Visual Studio 2012 and Entity Framework; adding EF to an existing project causes EF 5.0 to be installed (NuGet package), with no option to stick with 4.0.
A comment on this answer to a linked question is what made the realization pop.
Solution seems to be upgrade to the EF version that VS 2012 uses, or use VS 2010.
It says that TGDC does not implement the IDisposable interface.
How does the class declaration for TGDC look? Do you have more compiler errors? Do you have several classes named TGDC in different namespaces?
I get this periodically and for a while I always used to struggle with it because its not immediately evident what's wrong. Seems like all the hoops have been jumped through, but alas, not so. Eventually the solution will stick.
In the project you are writing this code you are referencing the project in which your "TGDC" is defined but you are not referencing System.Data.Linq. You need to reference both these assemblies. This can only really happen when you are using some sort of a layered architecture.