Develop Reference

CSharpAddImportCodeFixProvider encountered an error and has been disabled

I had my PC re-imaged for me. I have Visual Studio Version 14.0.25123.00 Update 2 installed on my computer. I'm getting this error when I try to use VS intellisense to reference another project.
CSharpAddImportCodeFixProvider encountered an error and has been disabled
I have two projects. One of them using namespace ProjectName.Web. And the other project using ProjectName.Web.Controllers. The provider crashes when I reference ProjectName.Web.Controllers, I believe because it is setup as a project. Any idea how to fix this?

I had the same issue on VS-2015 update 3.
I did was :
1) Closing visual studio
2) restarting as administrator

Happened to me when chose Add using System.Data.SqlClient automatically after typing using (SqlConnection...){} in DataLayer, in one of Repository classes.
Nothing helped (except creating new project), but I saw that the problem was with loading System.Data.SqlClient.dll file, although it existed in appropriate folder.
Found by trial and error that after removing Dependencies->Assemblies->System.Data.SqlClient from DataLayer (right click -> Remove, or just press Delete key when selected), I can Add System.Data.SqlClient without any errors.
Didn't try for other cases where CSharpAddImportCodeFixProvider encountered an error and has been disabled message appears, but the solution might be similar.
In my case the problem appeared probably due to .net Core version conflict or something like that, because the project was on external drive and created on another computer.
Edit: Also, some errors might be caused by .vs folder (hidden by default) inside Solution folder, especially if the project is moved between different computers. I know from experience that IntelliSense can seem to be broken and classes from other namespace would be unavailable although using namespace_name statement is present. The solution is to delete .vs folder or just avoid copying it with the project, as suggested here: https://weblog.west-wind.com/posts/2018/Aug/07/Fixing-Visual-Studio-Intellisense-Errors

There may be multiple reasons why this error occurs. So this answer may not apply to all situations, though it seems that it only occurs when another project is referenced.
The error does not occur for all statements. In my case I had the following code:
private System.Threading.Timer Timer;
public void Start()
{
Timer.Change(0, 60000);
}
As soon as intellisense would open for Timer.Change( the error occurred. Please note that I had no parameters at that point. If valid parameters are present there will be no error.
I could solve the issue by updating the version of the framework. I found out that both projects targetted different frameworks, resp. 4.5.2 and 4.6.
As long as the framework versions are different the error occurs. As soon as both are equal (either 4.5.2 or 4.6) the error no longer shows.
I have tested this with VisualStudioVersion = 14.0.25420.1 (Visual Studio Community 2015).
-- update --
I've reported this as a bug to Microsoft. Including steps to reproduce.

I end up with this same error.
what i did was to manually go and find the nuget packet for System.Data.SqlClient, installed and then invoke it in the class i was working on, like:
using System.Data.SqlClient;
Dont know if this is some kind of bug, cause it happens on a new blank project i create using visual studio 2019 community
hope it helps someone

Had the same problem solved by installing the sqlClient package from nuget package manager
right-click on the project choose manage nuget packages.. and go to browse tab and search for System.Data.SqlClient and install it. that easy :)

Judging from the label you were given, "CSharpAddImportCodeFixProvider", I'd guess your problem was due to Visual Studio trying to identify and/or correct a missing "using" statement at the top of your C# source code file in which you made reference to a class that needed it. The Visual Studio components that usually deal with this type of problem are Intellisense, or third-party syntax highlighting/correction plugins like JetBrains' ReSharper.
On second thought, I'm not quite sure it's Intellisense's fault as opposed to the plugin ReSharper's. That's to be determined.
I did file a similar bug report with Microsoft. The error in my case seemed to be a result of the Intellisense not knowing how to deal with a logic error in my own code (see https://connect.microsoft.com/VisualStudio/feedback/details/3133049).
In my case, I had inadvertently placed code for a method outside its class definition, though inside its similarly named namespace. Visual Studio 2015 Update 3 complained,
'GenerateVariableCodeFixProvider' encountered an error and has been
disabled.
The fix was to move my method back into its corresponding class definition, but it definitely brought a Visual Studio bug up to the surface.
Specifically, Visual Studio Intellisense had seen the line of code,
Response.Write("I did something");
placed in a method that was declared outside a class definition (i.e., inside a namespace, but inadvertently not inside its class). The "'FeatureLabel' encountered an error and has been disabled" error was then displayed in a yellow bar across the top of my editor window and an "Enable" button and an "Enable and ignore future errors" button were displayed next to it.
I believe that Intellisense (or ReSharper?) tried to automatically deal with the situation and attempted to generate a variable for the keyword, "Response", but it tripped trying to do so--which in turn caused the error that was displayed.

anyone trying this solution from here ?
https://developercommunity.visualstudio.com/content/problem/623872/add-import-not-working.html
the last reply solves my issue..
Tools > Options > Text Editor > C# > Advanced
turning off Suggest usings for types in NuGet packages

Assembly binding error when building Office add-in: "FindRibbons" task failed unexpectedly

We're trying to set up a Jenkins (build server) job to build our Office add-in based on VSTO. However, I keep getting a strange error that fails the build process after the DLL is copied to the bin directory of the project:
Error 11 The "FindRibbons" task failed unexpectedly.
System.IO.FileNotFoundException:
Could not load file or assembly 'MyAddIn, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its dependencies.
The system cannot find the file specified.
File name: 'MyAddIn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
So the problem is that the "FindRibbons" task, triggered by the Office add-in build target, has successfully identified the MyAddIn DLL as being an Office Add-In, but is not able to locate and load it!
Any ideas? I'd love to be able to debug the FindRibbons task directly but hooking into and debugging the compile process seems a little extreme...
Here are some observations:
In our build server's Fusion logs for binding the MyAddIn assembly it looks like it's looking in the folder where MSBuild.exe lives (C:\Windows\Microsoft.NET\Framework\v4.0.30319\) and nowhere else.
On my dev machine, there is no Fusion log entry for MyAddIn! But the build process succeeds and Kivo works fine.
On both my dev and build machines I also have Fusion log entries for WhereRefBind!Host=(LocalMachine)!FileName=(PresentationCore.dll) and ExplicitBind!FileName=(MyAddIn.dll) which show the binding succeeding.
This error comes up on the build server whether I use Visual Studio or MSBuild from the command line to build the project.
I've ensured that the .NET/MSBuild/VS2012 versions are identical on both my dev machine and the build server and the error still occurs. The only difference seems to be that the build server is running Windows Server 2012 (since it's Azure, and we can't spin up a Windows 7 image).

This has worked for me every time I upgrade Visual Studio - I don't use ribbons.
This worked for my solution, but use at your own risk:
Open the following file in an XML editor (make a backup first): C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets (the v10.0 part may be different for you, e.g., it might be v14.0)
Remove the following section:
<FindRibbons AssemblyName="$(AbsolutePathToCustomization)" TargetFramework="$(TargetFrameworkVersion)">
<Output TaskParameter="RibbonTypes" ItemName="RibbonTypesCollection"/>
</FindRibbons>
Replace all occurrences of "#(RibbonTypesCollection)" with the empty string ""
Save the file and restart the visual studio

If you migrated the project from a previous version of Visual Studio, be sure to remove the ExcelLocale1033 and SecurityTransparent attributes from the AssemblyInfo.cs file (as answered by Swati in this other question)
If the project still fails to build, it may be because your .csproj file has some references to msbuild's tasks of previous versions of Visual Studio. I suggest you to create a new empty Excel AddIn project, and uses the msbuild structure of the new project file as base for your project.

I had this problem. It was apparently caused because I changed the "Copy Local" setting on reference "Microsoft.Office.Tools.Common.v4.0.Utilities" from True to False. ISYN. (I sh*t you not)
I had upgraded a project from VS2012 to VS2013 and noticed that that reference was the only one set to "Copy Local = True". So I set it to false, because it was different. This caused the error. Changing it back to True solved it.

I had the same error message and finally found a fix. The problem stemmed from the VSTO project being targeted for .NET 4.0 (it seems this is the minimum for VSTO4), while also referencing an assembly built for .NET 3.5. The real culprit was that I had a class in the VSTO project deriving from an interface defined in the .NET 3.5 assembly that in turn derived from a .NET 3.5 library interface. i.e.,
using System.Xml;
class MyVSTOClass : IMy35AssembyInterface // This caused the error
class MyVSTOClass : IXmlSerializable // This compiled OK
using System.Xml;
interface IMy35AssembyInterface : IXmlSerializable
The fix was to update the .csproj to explicitly reference the older version of System.Xml.dll and System.Data.dll which would otherwise default to 4.0 and conflict with the 3.5 assembly references.
<Reference Include="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <!--<Aliases>Data2</Aliases>-->
      <HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll</HintPath>
      <SpecificVersion>True</SpecificVersion>
      <Private>False</Private>
    </Reference>
 <Reference Include="System.XML, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <!--<Aliases>Xml2</Aliases>-->
      <HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll</HintPath>
      <SpecificVersion>True</SpecificVersion>
      <Private>False</Private>
    </Reference>
For those who need to simultaneously reference both the newer and older versions of a DLL, note that it is in theory possible using:
extern alias XmlDll1
using XmlDll1::System.Xml
See http://geekswithblogs.net/narent/archive/2008/11/11/126940.aspx for more info.

This problem can also be caused by adding a reference to an unsigned assembly to a signed/strong named add-in project. In my case I added the RestSharp Nuget package and started receiving this error on build as soon as I referenced RestSharp in code. After some digging I noticed that RestSharp was the only unsigned assembly in the project references. If you have this problem, there are 3 possible solutions:
In the case of RestSharp, I found that there was a signed version available on Nuget - searched for "restsharp signed" and installing that solved the problem.
If you have access to the source code, you can configure Visual Studio to build a signed version of the assembly in the Project Properties page.
If you do not have access to the source code, you can sign the assembly with your own key by following these instructions.

I had the same error and none of the answers from the internet help me fix this problem. The reason why I was getting that error is because I was referencing an assembly of type Console Application. I changed that assembly to be of type ClassLibrary and I did not got that exception any more.
Also I would only get that exception when inheriting from a class that was located on my ConsoleApplication. It took me forever to figure it out.

May be a little late here, but I just resolved this for myself - after following numerous suggestions (via google) all of which did not solve my problem I manually went down the line. Turns out I had compiled a set of libraries with a dependent assembly with a lower version (not the latest). In my main project I also had a reference to this dependency but it was pulled via nuget and was at the latest & greatest version. For some reason VS.NET couldn't figure that out and would completely trip out and drop the error you posted. Once I updated the set of libraries to the latest version of the dependency all worked as normal.
The crazy part is - it worked fine initially and then out of nowhere the issue came about. Hope this helps someone along the way.
After enabling Fusion the output showed that it was looking for the assembly in the msbuild/ folder.

I just encountered this same situation today, futzing around for a bit, restarting VS and then rebooting my machine without any success. Than one warning popped out at me - One of my dependent assemblies was not strong named. Setting that assembly to be strong-named solved the problem.

I had the same issue, and even after reading KKG's answer I could not resolve mine.
It turned out to be much simpler for me, but not less frustrating and time consuming. I was working in a Win8.1 VM which does not ship with .net3.5 by default. My .net4 VSTO4 project was referencing an assembly that requires 3.5 somewhere. The same project compiled find on my other VM which was Server2008 and had 3.5 enabled.

In my case, the cause for this error was the mere existence of a field of a generic value type in the assembly (not kidding), e.g.:
class Foo
{
ImmutableArray<int> foo;
}
Workaround (if the additional indirection is acceptable performance-wise):
Wrap the value type in a reference type. This can be done generically with something like
public sealed class Box<T>
{
public readonly T value;
public Box(T value)
{
this.value = value;
}
}
then foo can be of type Box<ImmutableArray<int>>.

I have experienced this same issue with an add-in for Outlook.
The solution for me was to set Embed Interop Types to True on my reference to Office.dll.
This however caused the add-in to crash during startup with an Access Denied on Microsoft.Office.Interop.Outlook. I fixed that issue by setting Embed Interop Types to True on all references to Microsoft.Office.Interop.Outlook.dll as well.

This error can be caused by a clash of dependency versions. For example:
YourAddIn
-- OtherLibrary v1.3
-- BaseLibrary v1.0
-- BaseLibrary v2.0
If a newer version of BaseLibrary v2.0 is released and updated in your project, however this version introduce a breaking change in your other dependency OtherLibrary, you will see this exception because OtherLibrary is still trying to find the old methods that doesn't exist in newer assembly.
Update OtherLibrary with the latest packages will resolve this clash of dependency versions.

This can also happen if the Microsoft.Office.Tools.Outlook.v4.0.Utilities reference is set to <Private>False</Private>.
<Reference Include="Microsoft.Office.Tools.Outlook.v4.0.Utilities">
<!-- Required for FindRibbons task -->
<Private>True</Private>
</Reference>

Compile errors after upgrade to TFS 2012

I'm getting 2 different compile errors but repeated across several projects in our solution. The solution was upgraded from VS 2010 to VS 2012. Locally the solution builds fine and runs without error.
"The type (xxx) is defined in an assembly that is not referenced. You must add a reference to assembly 'Blah, blah, blah..., ...'"
"The type caught or thrown must be derived from System.Exception"
The second set of errors seem irrelevant as the try catch block "ex" is the issue but not consistently throughout the solution/projects. Its probably a cascading issue resulting from the first error.
Thanks

For the reference in question, check to make sure you are referencing the csproj (a Project Reference) and not a binary file that may or may not exist on the build server. I've seen it before where people somehow get a reference to the .dll in the bin\Debug folder, and when you try to build that on another machine where the bin\Debug doesn't exist yet it will of course fail.
Note: There may be a better way, but when I want to inspect my references I right click the project in Solution Explorer and Unload it, then right-click and Edit it and inspect the XML directly.

For "The type caught or thrown must be derived from System.Exception", it looks like you have written a user defined exception which does not inherit System.Exception. You can refer the below link for possible solutions
http://www.codeproject.com/Questions/457402/The-type-caught-or-thrown-must-be-derived-from-Sys

Strange exception suddenly appears when trying to install a setup project, need help big time

Using Visual Studio 2010 to build a setup project that installs a Windows Forms application .Net 4.0 C#. It has worked fine for ages but now when I'm trying to install the finished setup file, I'm getting this error message:
Error 1001. Unable to get installed types in the "Path" assembly. -->
Unable to load one or more of the requested types. Retrieve the
LoaderExceptions property for more information.
I have been searching for answers for over 4 hours now without finding anything. This problem just came without me doing anything. Last time I build the install file was like 2 weeks ago and there was NO problem at all. I haven't deleted any reference or any code that have anything to do with the setup project.
How could this problem appear from nothing and more important, how do I fix it?

Based on the error message in your second comment, it appears that your SysDir.exe assembly has been added as a Custom Action with the InstallerClass property set to true, but either no installer classes could be found in the exe or the exe could not be loaded due to missing dependencies.
You can see the list of Custom Actions by right-clicking on the installer project, selecting View and then Custom Actions.
If your exe does not can an installer class, then you can remove it from the list of custom actions.
If it does contain an installer class, then the issue is going to be missing dependencies. If fuslogvw doesn't work for you (it has always helped resolve this kind of issue for us), you can carefully review the list of references in the exe's project and compare them to what is listed in the installer project.
The other trick that we use is to examine the install directory while the error message is displayed on the screen. We can often see that DLLs are missing by doing this, usually because the path was entered incorrectly in the DLL entry within the installer project or because a condition was set incorrectly.

Have the same error today. For me it was the project type of the class library.
I noticed that the pucture on the guide I was following had selected Class Library (.NET Framework) instead of just Class Library.
Creating the correct project type fixed the error.
https://nhvu1988.com/posts/how-to-create-msi-installer-using-vs-installer/

Service Reference Error: Failed to generate code for the service reference

I have a Windows Service Solution and am trying to add a service reference to a Hermes(Opensource ebms message server) Web Service in VS2010.
I can find the Web Service using it's URL, but when I try and populate the Service reference I get the following errors in Visual Studio:
Error 8 Custom tool error: Failed to generate code for the service reference 'testService'. Please check other error and warning messages for details. C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Warning 6 Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[#name='EbmsStatusQuery']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[#name='EbmsSoapHttpStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Warning 7 Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[#name='EbmsSoapHttpStatusQuery']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:service[#name='EbmsMessageStatusQuery']/wsdl:port[#name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Warning 5 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: Schema with target namespace 'http://service.ebms.edi.cecid.hku.hk/' could not be found.
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[#name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Some investigation seemed to suggest it is due to svcutil.exe not been able to build the proxys due to not having permissions to a directory (possibly c:\windows\temp). I have tried assigning various access permissions, but I am not really sure which user needs the permission, or if it is just a red herring.
Any ideas would be greatly appreciated.
Thanks

Have to uncheck the Reuse types in all referenced assemblies from Configure service reference option
Check this for details

Right click on your service reference and choose Configure Service Reference...
Then uncheck Reuse types in referenced assemblies
Click OK, clean and rebuild your solution.

I also encountered a similar error when trying to generate the client for a web service from an ASP .Net MVC 4.0 project using Visual Studio 2012.
The root of the problem seems to be that fact that the project from where I was trying to generate the client was referencing an assembly which in turn was dependent on another assembly that was not being referenced as well.
When "Reuse types in referenced assemblies" is enabled in the service configuration, the service generator is probably inspecting all the referenced assemblies to get a list of types that can be reused. The fact that one of the referenced assemblies is referencing another assembly which is not available is probably causing the generator to fail.
Unchecking "Reuse types in referenced assemblies" from the service configurations will solve the above problem, but there is a side effect to it. The reuse types option is there for a reason and in some cases it avoids unnecessary casting in the code consuming the service.
For example, if the service itself is built using WCF and some methods parameters inside it are of type System.Guid, they will be translated to strings in the generated client if the reuse types option is disabled.
An alternative that I prefer to disabling reusing types is to add the service reference from Class Library project specifically created for that purpose. The one thing to keep in mind is to copy all the service related configurations from the class library's app.config to the configuration file of the startup project.
If there are types defined in local assemblies that need to be reused in the service client, those assemblies simply need to be referenced from the above mentioned class library project, along with all their dependencies.

http://uliasz.com/2011/06/wcf-custom-tool-error-failed-to-generate-code-for-the-service-reference/#comment-1647
Thanks to the article above.
In my case, i have this issue with my WPF project in VS.Net 2008. After going through this article, i was realizing that the assembly used in the web service is different version of assembly used on client.
It works just fine after updating the assembly on the client.

It would be extremely difficult to guess the problem since it is due to a an error in the WSDL and without examining the WSDL, I cannot comment much more. So if you can share your WSDL, please do so.
All I can say is that there seems to be a missing schema in the WSDL (with the target namespace 'http://service.ebms.edi.cecid.hku.hk/'). I know about issues and different handling of the schema when include instructions are ignored.
Generally I have found Microsoft's implementation of web services pretty good so I think the web service is sending back dodgy WSDL.

Restarting Visual Studio did the trick for me. I am using VS 2015.

I get the same error in Silverlight 5 (VS2012)
You can also remove the references to:
System.ServiceModel.DomainServices.Client
System.ServiceModel.DomainServices.Client.Web
After you've updated the service references, be sure to add them back in.

As stated above, there are a couple of different problems possible. What we found is that the .DLL for the WCF library had been added as a reference to the client project. This, in turn, created problems with resolving the objects and thus caused the files to be "emptied" by code generation steps. While unchecking the use "Reuse Types..." can seem like an answer, it creates extra definitions of object types, which are proxies to the real types, in a new name space, which then causes all kinds of "compatibility" issues with the use of those types. Only if you really want to "hide" a type should you check this option.
Hiding the type would be appropriate when you don't want a "DLL" type dependency to "leak" into a project that you are trying to keep segregated from another. If the DLL for the WCF library project creeps into the client project references, then you will have this problem with all kinds of strange side effects since the type definitions are also in the DLL.

face same issue, resolved by running Visual Studio in Admin mode

I have encountered this problem when upgrading a VS2010 WCF+Silverlight solution in VS2015 Professional. Besides automatically upgrading from Silverlight 4 to Silverlight 5, the service reference reuse checkbox value was changed and generation failed.

"Reuse types" is not always the problem when this error occurs.
When adding a reference to an older service, click 'advanced' and there 'Add Web Reference'. Now link to your wsdl and everything should be working.

If you want to correct this without uncheking the assembly reuse checkbox this is what worked for me:
Remove referenced assembly that you want to re-use
Delete all the bin folder of the project
Update service reference
Keep "Reuse types in specified referenced assemblies"
Add reference to assembly again to fix the errors
Update service reference again

I had this problem when trying to update my service reference (The error only shows up when adding a service reference though) but didn't want to remove the assembly reuse checkbox.
What worked for me was the following:
Remove referenced assembly that I wanted to re-use
Update service reference
Keep "Reuse types in specified referenced assemblies"
Ignore the errors, it's because the reference is missing!
Add reference to assembly again to fix the errors
Update service reference again
Voila, now it actually updates and doesn't try to remove all of my generated code anymore.
I was almost ready to give up on the re-use types feature...
EDIT: Also make sure that the build config is AnyCPU or x86, since svcutil is buggy with x64.
To the downvoter: Sorry if it didn't work for you, I don't even know why it worked for me, but it did. I may have done something else that time that fixed the problem, but no way to know now.