I am porting a .Net Framework 4.7.2 project to .NET 5 and have Excel.Interop build errors that Intellisense has no problem with. I have:
Created a new .NET WPF project
Update the TargetFramework property in the .csproj file from .netcore3.1 to net5.0-windows
Copied my classes over into the new project
Added a reference to the Excel 16.0 Object Library
Changed the Copy Local property of the Interop.Microsoft.Office.Interop.Excel dependency to Yes and changed the Embed Interop Types property to Yes as well
Started a build
The build fails with Interop errors like "'object' does not contain a definition for 'Value'" even though those errors in Intellisense go away after I update the Copy Local and Embed Interop Types properties.
Following the build, if I double-click on each of the build errors, the class file opens and Intellisense considers the error resolved: it disappears from the list and the red line under the code disappears as well.
I see Interop.Microsoft.Office.Interop.Excel in the project Dependencies --> COM expandable items in the Solution Explorer, but when I right click on the Solution, do Properties, and look at Project Dependencies for my project, nothing is listed. Is this a problem? Would a COM reference be listed in Solution Properties --> Project Dependencies?
I was under the impression that the Office Interop libraries would be compatible with .NET 5 and that I am setting things up correctly. Why is does Intellisense think things are fine but build errors result?
Things I've tried
Restarting Visual Studio and my computer
Removing the reference and re-adding it
Cleaning and rebuilding the solution
Deleting the bin and obj folders in the project
Related
In Visual Studio 2022, I have a solution containing several C# projects and one C++ project. C# project “Application” builds into a class library (DLL) targeting .NET 7.0. This project depends on the C++ DLL project “Legacy” (built without /CLI) also in the solution. However, when I build the solution, the Legacy DLL does not get copied into Application’s output folder (nor the main .exe project’s output folder), and so when the overall program is run, it crashes when it realises it cannot find Legacy.dll.
The Legacy project shows up in the dependency list of Application with a little yellow warning triangle, which is probably a significant clue. Removing this dependency and re-adding it makes no difference. Restarting VS make no difference.
If I manually copy Legacy.dll into the same folder as Application.dll, it all runs fine, but this is not an acceptable solution. The assemblies of other dependent projects (all C#) do get copied over during the solution build, and recognised at runtime.
I found out the following when researching the cause of the yellow warning triangle:
although building from within the VS IDE succeeds with no errors, building using “dotnet build -c Debug” from the Package Manager Console fails, with error MSB4019: The imported project “D:\Microsoft.Cpp.Default.props” was not found in the .vcxproj file (from this line: <Import project=“$(VCTargetsPath)\Microsoft.Cpp.Default.props” />).
error MSB4019 seems to be caused by the macro $(VCTargetsPath) not being defined. The missing file does exist (in my case in D:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Microsoft\VC\v170).
if I open the properties dialog for the C++ project, and click on a property that can use macros, and examine which macros are defined, $(VCTargetsPath) is correctly defined as D:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Microsoft\VC\v170. So the macro definition seems to exist, but somehow gets reset during a build (at least, when building from the Package Manager Console).
Ideally, I’d like the yellow warning triangle to go away, AND the C++ DLL to be copied to the correct location during build from the VS IDE.
I have two brand new C# .NET Standard libraries. They each have a project reference to an older .NET 3.5 Framework library. Only one of the two have a yellow icon on the reference.
Everything builds and runs fine but the triangle still exists, why?
I would hope they have a better way to report reference issues
than an unlabeled yellow icon.
Not sure if it's your real question. But you can check the Error List window to get details about why yellow icon displays on the References.
Everything builds and runs fine.
For some scenario, the build in VS can succeed although some build warnings occurs. And it will only fail when some build errors exist.
I add reference to ForTest.dll in my project, this assembly is missing or not compatible with current project, then it displays yellow icon in References. Now since in my project, it doesn't call functions from the ForTest.dll, so it won't exactly affect my build process. Then the project builds successfully and runs fine.
I have tried looking at the build log, in detailed mode, for an error
message, but cannot find anything obvious.
When building a solution with several projects, and set the log in Detailed mode, it's easier to get lost in the hundreds of build logs. Since the yellow icon only displays for one project, you can right-click the project=>rebuild to build the project, it makes the message in build log more clear.
Or just use the Error List window as I suggest above to check the warnings and errors instead of hundreds of logs during Trouble-shooting.
In addition: If you can't find any info in Error List window, then maybe the reason why the yellow icon occurs is because VS didn't load the project well. Please try right-click the project=> unload and reload the project in solution explorer. If it persists,close all vs instance and delete the .vs folder in solution directory, and restart vs.
According to Microsoft, these yellow warning signs get added for every new reference and then removed once the reference is successfully added (=assumed guilty until proven innocent). If some yellow warning remains in the solution explorer, VS knows only that that reference is missing, but doesn't know why and can therefore not display a warning message in the Error window.
Not being able to find out why there is a warning sign is very annoying. The problem was reported, but Microsoft's standard response is: "This problem seems not to be requested enough to be resolved, but if you like, you can contribute your own solution."
So if you read so far, can you please go to developercommunity.visualstudio.com: tell me what's wrong with the reference 2 and vote this issue up, telling MS they should indeed fix this.
After spending hours trying to solve a none existing error, I gave up and closed VS. When I started it again, the problem was gone.
These errors also occur when adding a NuGet package that is not compatible with the current .NET (such as .NET Framework app under .NET Standard or .NET Core, or a .NET version such as referencing .NET Framework 4.8 library from an older .NET version).
Check that the package dependency is the same as the project you're working with.
It could also mean that the third party assembly you have on your machine is not registered in the gac and hence not being found. For older projects mostly if I have to hand copy over the dlls, I will then register them with this powershell script in the directory they reside in:
gci *.dll | % { gacutil /i $_.Name }
I am using Visual Studio 2017 Enterprise, C# 4.7.2
My Solution contains currently nine different projects. A build succeeds without any error messages. When I run the application, a TypeLaodException is thrown, The Type Namespace.AClassName could not be loaded.
The weird thing is, that there isn't any class named AClassName anymore. BUT, the mentioned class did exist in a former version.
I cleaned the solution, startet a build, same error. I rebuilt the solution, same error. Cleaned than rebuilt the solution, same error.
Apparently, the build is not correct. But what can I do to ensure, that the build runs correctly?
If manually deleting the folders bin and obj as suggested in the comments is not working, I will also delete de .vs and there are a few things you can try:
Unload the projects, and search in the .csproj for any reference to
the Old-Deleted AClassName. Check also that there is no namespace related to it. You will have to do it in the project where originally was the class, but I will recommend to search in all 9 projects.
Check if there is any Project Dependency in the Configuration Manager related to the project where the AClassName was.
I would also restart my machine, delete temp folder and run VS As administrator.
Clean Solution.
Clean Debug & Bin folder.
Make sure all project reference are from Project libraries (it should not be directly from Bin folder).
Make sure all interconnected project build on same .net platform (4 , 4.5 or 4.6 ).
Build and try to run.
I previously asked a similar question regarding Visual Studio 2013 but now I'm running into the same problem with Visual Studio 2015 but it seems to work differently, which makes the previous answer not applicable to this question. This is my previous question: Visual Studio 2013 - How to debug a project within a solution
I'm attempting to add a project reference. I have a library I'm working on in a separate solution/project and a console application I want to use to test and debug the library.
I tried: Add Reference > Projects > Solution > Browse
But the open file dialog does not contain .sln files in the filter list and if I force it to display them by typing *.sln and then select the Solution I get:
"Please make sure the file is accessible and that it is a valid assembly or COM component."
What am I doing wrong? How do I properly add a Solution/Project reference?
For me issue was due to difference in Target framework. One was .NET Framework 4.5 and other was .NET Framework 4.5.2
Verify if the Target framework is same for your project and the project reference that you are trying add reference.
(Right click on project -> properties -> Application Tab(Target frame work))
Right click on your solution file in Solution Explorer window, click Add and select Existing Project...
Once the project is a part of the solution, you will be able to add project reference.
In case anyone else runs into this here is something that I found. I had almost the exact same issue in VS 2015. I created a console app and then a class library project but could not add a reference to the class library.
It turns out I didn't create a class library project as I had thought, but rather a class library (package) project. These are different things and I was unaware of what the (package) part meant when I selected it. This is for creating Nuget packages, apparently.
I'm not sure if this is something new to VS 2015 but I had not run across it before and it caused me some grief. The error message ('A reference to ClassLibrary1 could not be added') was totally worthless in trying to debug it.
You should add project to your solution first; after adding project to your solution, you can reference it.
To add an existing project to your solution:
Add reference menu:
Add references dialog:
In order to add a project reference, the project has to be part of the solution.
For me issue was due to a difference in the types of projects. One was a C# Windows forms project and the other project was a C# Universal Windows project.
The Windows Forms project couldn't reference the Universal Windows project. The error was "Unable to add a reference to project "XYZ".
It appears you can have a library shared between both types of projects by folloing this answer: What kind of class library works with both Universal and Winform projects?
I ended up having a different solution. I had three projects in the solution which referenced a NuGet package which was no longer available. I had the library locally but I was unable to add it. I found that because of the BUILD ORDER and DEPENDENCY of my projects, I had to add it to the project that was built first, then I could add it to the projects that were dependent on that project.
I had this problem today and I looked at the configuration manager for the solution. The projects had different platform settings. I made them both Any CPU and rebuilt. Then I could reference the project.
I tried to created a .dll in TFS using VS2010 and use the .dll in a new project.
However, it keep on returning an error message saying the entity point for the method cannot be found.
To see if there is some error in the code of the class library, I created another class library project but not in TFS this time. This totally works well. This one can be referenced by C# using "using".
However, the one created in TFS cannot be referenced.
I would like to ask, what's the difference between these two .dll I created and what can I do so that I can successfully reference the .dll I created in TFS.
Many thanks!
Are you sure the error didn't say "Entry Point Not Found"? I have seen this many times when a project is set to build in x86 format when it should be building in x64 or AnyCPU. Right-click on the solution and go to Properties. Click Configuration Properties. Find your project and look at the Platform column. AnyCPU is usually your safest bet.