The screen shot below shows that VS 2012 intellisense picks up Helpers namespace from SendGrid namespace, but there is still a compile time error stating
The type or namespace name 'Helpers' does not exist in the namespace 'SendGrid'
(are you missing an assembly reference?)
What I checked:
The project is .NET 4.5 and that never changed.
SendGrid and SendGrid.CSharp.HTTP.Client references both have
v4.0.30319 runtime version, same as the rest of references.
Newtonsoft.JSON used by SendGrid is also the same runtime version.
Both are set to copy local True.
There are no other errors in the project.
F12 following a method from SendGrid.Helpers namespace navigates to its definition successfully, so I surmise there is no issue with the referenced DLL???
Cleaned and rebuilt the solution, restarted VS and machine.
Switched .NET version of the project between 3.5 and 4.5 several times back and forth.
SendGrid was added using Nuget to an existing project.
Installing an older version SendGrid-4.0 as per Hans solved the issue.
Lots of times this is caused by a build break during a design-time build, see https://github.com/dotnet/roslyn-project-system/blob/master/docs/design-time-builds.md#diagnosing-design-time-builds for instructions on diagnosing these.
Related
When I upgraded Oracle.ManagedDatabaseAccess.dll from v. 4.122.18.3 to v. 4.122.21.1 there are several compile errors, specifically:
error CS0246: The type or namespace name 'Oracle' could not be found (are you missing a using directive or an assembly reference?)
The reference has been added. I initially used a version-specific folder, and thinking this could cause some sort of problem, I moved it to the exact same folder where the older DLL had been successfully referenced, and there was still the problem.
This is somewhat like Similar Oracle problem, except that the linked post appears to be about Oracle.DataAccess.DLL whereas this is the managed version, Oracle.ManagedDataAcess.dll
I also have tried cleaning and "rebuild all" as well as unloading the problematic project in the solution and reloading it also, and neither helps.
As far as I can discern, both DLL's are 32-bit.
I am using Visual Studio 2019, a C#, asp.net context, and since the other Oracle.ManagedDataAccess.dll worked without special usage of a "register DLL" procedure, I'm not certain if that is needed or will help.
Is there any help for this situation?
Turns out that I needed to use .net Version 4.6.2. This locally built on my machine and everything worked. We are not ready for this so I reverted to the previous DLL, but thanks. Also, when changing .net versions, one sometimes has to load/unload projects, restart Visual studio, and make sure the saves of the project file actually "take".
Perhaps this Question and Answer will help someone else, someday.
Everything is installed and everything is ready, but this problem occurs during compilation:
Error 296 The type or namespace name 'combit' could not be found. (Missing a using directive or assembly reference?)
Yes, we were able to solve it after a long time.
Our Project Version
Our project runs on .net 4.5.2.
Plugin Version
The latest version of Combit.Reporting is .net version 4.7.
In other words, it will not give any error, but it will prevent your project from compiling because the .net versions do not match.
Attention!
If you want to connect a project that needs a higher .net version to
your project, consider the above article.
I had a Microsoft WebForms report viewer library version 10 referenced in my project, and I decided to remove that reference and add the version 150 NuGet package. However now I get a bunch of compile errors like so:
Error CS0246 The type or namespace name 'LocalReport' could not be found (are you missing a using directive or an assembly reference?)
and other similar errors. The weird thing is, when I open up the files containing the errors, the errors go away, but as soon as I try to build my project, they reappear! What's going on here? How can I compile my project without errors?
The problem was that the report viewer library I added the reference to required .NET Framework version 4.6, but my projects were only using version 4.51. Upgrading to v4.7 solved the problem.
We recently tried to upgrade our software to .net 4.0. We ran into a small snag and rather than spend the time to try to track everything down we decided to revert back to .net 3.5.
We have encountered a few issues like .resx files not properly reverting, but they have been fixed. The final problem we have encountered is a few projects are not building via command line now (everything was before). The error in all cases is as follows.
The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)
We use Visual Studio 2010, msbuild for the command line builds, every project has been changed to a framework of 3.5. The projects will still build in the IDE, but it is fairly time consuming for us to build them all by hand, rather than by our automated script.
It would also be worth noting that all the projects that aren't building are web projects. Within the web.config I don't see a single version=4.0.0.0 reference.
CodesInChaos was partially right. While the UI showed a reference to System.Core, there was no actual reference in the .csproj file. This had to be added in manually. This explains why the UI would build, but the command line wouldn't.
I started using Thrift about a week ago. I got the latest source from SVN and built the C# library (Thrift.dll). I used the library to prototype a TCP client/server with the data types that my team will be using. This worked with no problem, I just followed the example code in the SVN repo.
Yesterday, I wanted to run the same test but over HTTP instead. I searched around online some and found out that from the time I got the code last week until yesterday patch "THRIFT-322" https://issues.apache.org/jira/browse/THRIFT-322
Was applied to the trunk. So I updated my thrift source from SVN and saw the new THttpHandler class. I rebuilt the Thrift.dll so I can use the THttpHandler class but now whenever I reference the new dll Visual Studio 2010 gives me an error at compile time: "The type or namespace "Thrift" could not be found (are you missing a using directive or an assembly reference?)". When I replace the reference with the old Thrift.dll that I have I do not get this error.
I can't figure out what I'm doing wrong, I just recompiled the Thrift.dll from the SVN source and I can no longer link to the Thrift.dll. When I first add the reference it seems like it's going to work fine. Visual Studio gives me the correct intellisense, etc. Once I try to build it's like there is no longer a reference to the Thrift.dll. Any ideas?
I also submitted this to the Thrift Users Mailing List, I just thought maybe this was more general and someone here may be able to help.
Thanks,
-Sean
Since you mentioned using VS 2010... I have seen this error/behavior sometimes when I am compiling a .NET 4.0 project and my target framework for the project is set to ".NET Framework 4.0 Client Profile" instead of ".NET Framework 4.0". So you might want to check that and see if it helps.
I had a similar problem I had to switch from '.NET Framework 4.0 Client Profile' to '.NET Framework 4.0' and it worked because a referenced dll is compiled using the '.NET Framework 4.0'
One Suggestion I have is to check for a file with 'refresh' in the extension E.g. Thrift.dll.refresh or something similar. This file is usually added on adding a refernce. Try removing this file, replace the dll and try builtign and running again.