I am converting CLR class Library from vs2010(v4.0) to vs2015.
I am getting error:
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\system_error(24): error C2869: 'std::errc': has already been defined to be a namespace
I am also unable to add reference in x64, while c# assebly has been build with Any CPU target.
Could not add a reference
Targets a higher version of .NET Framework
Not a .Net assembly
Not a registered ActiveX control
For me, the C2869 error was caused by referencing an assembly that was built using an older version of Visual Studio. I solved the problem with the following steps:
Create a dummy cpp file in your project, with just the following lines:
include "Stdafx.h" // if required
include "system_error"
Compile just the dummy file and confirm you're seeing the C2869 error.
Remove all references from your project, compile just the dummy file and confirm that C2869 disappears.
Add your references back in one-by-one and compile the dummy file until C2869 reappears. Now you know which reference is causing the problem.
Either rebuild the reference using Visual Studio 2015 (v140* toolset) or find a way to remove the reference.
Related
Error Debugger
Inline
References
While working on a project I started debugging and out of no where a bunch of CS0426 errors came out of nowhere in the generated .g.cs files. I checked my references and I see all the assemblies referenced and added to the project already as you can see in the images. I have already tried reinstalling VS2019, restarting my computer, reinstalling/updating dotnet to 4.8 and tried a new project solution file as well.
Looking closer I do not know how it cannot find for example "Window" in "System.Windows" especially that is included in that type. All my 'usings' are in tact as well. I believe this pops up when I created multiple classes in a solution as well.
Any idea on how to fix this? I am using Visual Studio 2019 and DotNet 4.8.
Direct class initialization works without using the assembly names but it contradicts not being able to find it within the assembly and the generated file uses the assembly name to initialize the class anyway
I have a Visual Studio extension that we use internally that I'm in the process of updating for Visual Studio 2022. The extension worked fine in previous versions of Visual Studio, but I've had to follow several steps to get it building and running for VS 2022. I've gotten to the point where it will build and run, but I'm getting an error at run time when I'm trying to create a TFS ticket in the extension (which is the main point of the extension).
On this line:
projectCollection = new TfsTeamProjectCollection(url, cred);
I get:
System.IO.FileNotFoundException
HResult=0x80070002
Message=Could not load file or assembly 'Microsoft.TeamFoundation.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Source=Microsoft.TeamFoundation.Client
Searching around a bit, it seems that there is a version of that assembly at C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer, but apparently you aren't allowed to add that to your project. Because when you try, Visual Studio will complain that:
A reference to 'Microsoft.TeamFoundation.Common' could not be added. This component is already automatically referenced by the build system.
Further searching reveals that that assembly is also included with the Microsoft.TeamFoundationServer.Client Nuget package (that I did have referenced in the original version of this extension but it was since removed somewhere along the line), but installing that did not fix the problem either (not with the version that used to work in previous versions of VS, or with the latest version available on NuGet)
I suspect that the problem is that there is a version of this assembly that is loaded by Visual Studio itself and is conflicting with the version that the extension is built again. But trying to add a bindingRedirect to app.config hasn't worked for me either (although maybe I don't have the version I'm redirecting to correct?).
Does anybody know the correct way to resolve this conflict?
I'm currently making an extension for Spotfire that embeds a web browser (CefSharp) into the application. However, when I attempt to run the package, I get the error:
"Package 'D3Visualizations' has unresolved assembly references:
'CefSharp, version 1.25.4.0' is referenced by 'D3Visualizations.dll'."
I've added CefSharp.dll and CefSharp.WinForms.dll as references, and I have added those two as well as icudt.dll and libcef.dll into the bin/Debug folder.
I honestly don't know why it doesn't work right now; the last time I got an error in the package builder like this, it was due to .NET version mismatches.
What am I doing wrong? I'm using Visual Studio 2013 Express Desktop, and the project is in .NET framework 4.5.1.
Can you check the path for the references in their properties window? You can try removing and re-adding the references to the dlls in your bin folder and set Copy Local = true. If that doesn't work try setting it explicitly in the project file as in this question: Force VS to reference local dll
I'm working on a C# 4.0 project in VS2010 and needed to use some older DLLs containing controls that were created in C# 3.5 on VS2008. When I first add the DLLs to the references, I was able to see the namespace via intellisense and create an instance of one of the controls, but when I go to build, it gives me the following error:
The type or namespace name 'BCA' could not be found (are you missing a using directive or an assembly reference?)
And I do have a using directive for that namespace already, which is now underlined in red, showing that VS cannot find it. And now, intellisense won't pick up that namespace at all.
I even tried added the controls to the toolbox (which worked) but then when I drag them to the GUI, it says that it cannot locate the DLL reference, even though it obviously knows where it is.
I even tried changing the target framework to 3.5, but still with the same results.
Any thoughts as to why this could be happening?
Edit - I've notice that in the csc.exe arguments that VS outputs, it does not have any /reference entries for the DLLs I'm trying to use. When I create the same basic project in VS2008, those entries exist. Also, I can successfully reference the DLLs in a DLL project in VS2010... it seems to just be WinForms projects that don't work.
Turns out that it was something to do with VS2010 defaulting to the .NET 4 client profile, as soon as I changed it to the regular profile it built fine. There's a day wasted...
view the target framework.. in my project, was 4.0 client profile, e the reference dll was in 4.0
I tried Build->Clean Solution and then could add the reference.
I used to have similar problem, but the profiles were not the issue, so the problem was that my class library use a special NuGet package that has Dependency... so I install the dependency package in the target project and added the project reference and works!
But I am not sure if there is a better solution for this problem??? for me VS should be smart enough to carry those dlls along with the references. (I already verified that "Copy Local" is set to True)
Without much luck I've been trying to attach the HTMLTidy c++ library dll within Visual Studio, however everytime I get various errors with different builds. I'm adding a reference to the project and then manually selecting the dll, which has been copied into a lib folder within the project folder.
The first dll I tried was from Mark Beaton, and I'm using his HTMLTidy wrapper as it seems the most up to date. The standard Win32 one was built.
Mark Beaton Builds
I've also tried the build from the official HTMLTidy page, again the dll
Official Build
The error when referencing, please help! I've tried compiling from source, but the source doesn't seem compatible with VS 2010.
libtidy.dll is an unmanaged C DLL, so you can't add a reference to it in Visual Studio's Add Reference dialog. You need to build the C# code from https://github.com/markbeaton/TidyManaged into a managed DLL, and add a reference to that DLL instead.
Make sure that libtidy.dll is copied to your output folder; you can achieve this by adding the DLL file to your project, and changing its properties to "Copy to Output".