I have created a project library dll and it resides in the bin directory of the solution. I've got a second solution that references that dll. In the VS2013 IDE my 'Using' directive is happy and down n the code when I reference a class in the dll the code is happy. If I view the object reference in the object browser all look ok. I've also looked in the csproj file and the correct reference is in there. When I try to build the project I receive the type or namespace for my dll could not be found error message. I've tried cleaning first, I've also closed VS2013 and restarted all to no avail. I've also tried copying the dll to the local bin directory for this solution and re-referencing and still no joy
Ok, I found the solution. The project that I am referencing is targeting .net4.5.2 of the framework. THe project that was referencing it was only referencing .net4.5 I have set this to .net4.5.2 and it now builds.
Thanks
For all the input
Related
We use the CodeDomProvider to compile C# and VB code in our app. We have been using Roslyn ever since it came out for this purpose. We are currently using version 1.0.8 of Roslyn. Recently, we started getting this error:
Metadata file
'C:\Windows\system32\config\systemprofile\AppData\Local\assembly\dl3\8GTGDQKQ.4QR\V42JN801.7NM\36a4366e\f1f27652_1972d301\System.Runtime.dll'
could not be found
I'm not adding this reference manually. Roslyn seems to be adding this reference in arbitrarily. I've tried adding a reference to System.Runtime.dll inside our app's bin folder, but the problem does not go away.
I've logged a bug with the repo here, but not response:
https://github.com/dotnet/roslyn/issues/24630
Has anyone else seen this bug? Is there a workaround? Why is the compiler looking for System.Runtime.dll at this path? Why won't it just use the DLL inside our bin folder?
I found a workaround. If I copy the file System.Runtime.dll from my bin folder to the path C:\Windows\system32\config\systemprofile\AppData\Local\assembly\dl3\8GTGDQKQ.4QR\V42JN801.7NM\36a4366e\f1f27652_1972d301 the assembly compiles fine.
So, Roslyn is ignoring the path I am telling it that System.Runtime.dll is in and expecting to find the DLL in a hard coded path instead. This does seem like a bug to me.
I have two C# projects, A and B, in VisualStudio 2010. Project A is a class library. Project B is a ReSharper-Plugin project that references project A (ProjectReference). Both projects compile and worked property when I ran project A in the Experimental Instance.
Now, recently I renamed a static class, with some extension methods, in project A. Both projects still compile. But when I run project B I get an TypeLoadException for the new class name. When I change the class's name back, everything works fine again.
My guess is that project B is compiled against the new code, but run against an outdated dll. I tried everything from clear, over rebuild, to restart, but to no avail. I also manually checked that a fresh dll from project A is placed in project B's bin/Debug folder, which is the case. And I copied over the dll manually, after building project A. The problem persists.
Now I ask myself whether there is another location where the dlls are copied to before running the Experimental Instance. Is this the case? If so, where to? Are there any other places where the old version could come form? Or is there even something completely different that could cause the problem?
Thanks in advance!
Ok. Did you reference the DLL or the Project? In a Visual Studio Solution you can reference projects. If you reference project A in project B then B should always use the latest code from project A.
I managed to figure it out myself, thanks to the right keywords on Google (MissingMethodException and ProjectReference) that led me to a blogpost about a solution to the same symptom. In my case it was not the GAC that caused the problem, but the cached assemblies under
C:\Users\{name}\AppData\Local\Microsoft\VisualStudio\10.0Exp\
This is the location where all the assemblies of the Experimental Instance go. Here lay an outdated VsExtension that depended on project A and within it there was an outdated copy of project A that was loaded. The loading of the new version from the project reference was simply skipped, since a copy of the assembly (with the same version) was already loaded.
So the problem was ultimately caused by the removal of the extension from my solution. From this point of the extension was no longer updated by VS, but it was also not removed! Lessons learned: After major changes of your infrastructure you may want to delete all cached assemblies below the above path...
Thanks for the help, everyone!
I'm having an issue building a project that references a DLL located in the project's bin folder, which up until yesterday was building and running without issue.
The error I'm getting is fatal error CS0009: Metadata file 'c:\MyProject\bin\myClient.dll' could not be opened -- 'Error importing module 'myClient.netmodule' of assembly 'c:\MyProject\bin\myClient.dll' -- The system cannot find the file specified.' Intellisense is similarly complaining that The type or namespace 'Api' does not exist in the namespace 'Client' since it can't find the DLL.
Let me know if you think this is a duplicate, but I've viewed several similar posts and the solutions did solve my problem. Here are some examples:
Visual Studio 2010 — are you missing a using directive or an assembly reference?
VS2010 - Getting “type or namespace name could not be found” but everything seems ok?
Stymied by ASP.NET Compilation Error CS0009
Metadata file '…\Release\project.dll' could not be found in Visual Studio
Visual Studio 2010: Metadata file “…/Debug/Graph.dll” could not be found
Metadata file … could not be found error when building projects
Specifically, I've tried the following solutions (and combinations of these):
Cleaned and rebuilt my project.
Made sure that the target framework is not a 'client profile' version of .NET
Verifyied that the dll has been added as a project reference
Removed and re-added the project reference
Verified that the project is showing the DLL in the References section in Visual Studio
Repaired .NET
Verified the location of the DLL (it is in the local project's bin folder as given by the error)
Tried other versions of .NET
Closed and restarted Visual Studio
Rebooted my machine
Verified there are no hidden characters surrounding the 'using' statement
Removed all code changes since the last working build
Verified the settings in Configuration manager, including that 'Build' is checked
The project calling the DLL is a small class library that resides in a solution with one other small project (a console application). The DLL is an external DLL that I've been using successfully for several weeks in this project/solution. The error arises regardless of whether I build the project from the solution or by itself.
Any ideas about what could be going on?
Have you included bin folder in your project accidentally? If yes that might cause the issue. You can't include bin folder in your project as the bin folder will be created by the VS. If you accidentally include bin folder in your project, the bin project will be set to Copy to output which when you compile, the file is deleted and copied to output by Visual Studio that trigger weird behavior that some file is missing.
Hopes this help
Well I'm not sure exactly what happened here, but here is what finally resolved the issue:
A good-old-fashioned delete every single file and rebuild the project from those files from scratch. I gave +1 to some of the responses because they were useful to consider, and because there was probably a messed-up reference some where as Jonathon Wood suggested.
I am on .NET Framework 4.0, building a C# web application in VisualStudio 2012. I have Microsoft.VisualBasic added as a reference to the project. I am having trouble with the following line of code:
using Microsoft.VisualBasic.FileIO;
Building the solution returns the error: The type or namespace name 'FileIO' does not exist in the namespace 'Microsoft.VisualBasic' (are you missing an assembly reference?)
I have removed and re-added the reference to the assembly Microsoft.VisualBasic, but still get the error. Microsoft.VisualBasic is in the GAC, as well as Microsoft.VisualBasic.Compatibility, Microsoft.VisualBasic.Compatibility, Microsoft.VisualBasic.PowerPacks.Vs, and Microsoft.VisualBasic.Vsa.
Please let me know how to get VS2012 to recognize the FileIO namespace.
Right-click on your project and select Add Reference...
In the Reference Manager, expand Assemblies and select Framework. Then check the box for Microsoft.VisualBasic and click OK.
I had similar issue, fixed by change TargetFramework (in .csproj) from netstandard2.0 to netcoreapp3.0.
Application references are not available to uncompiled files in your application (aspx, ashx). There are two solutions to this issue as follows:
1) Move your code to a compiled part of the application (cs/vb file)
or
2) Add the reference to the web config
My reference was in an ashx file. I simply copied the code from the ashx file to the clipboard, deleted the file from the project, added a new Generic Handler (right click in Visual Studio > Add > Generic Handler), entered the same name as before, and pasted the code from the clipboard into the cs file editor that Visual Studio opened. I now have a cs file that will compile with the project and use the project reference. The file name is the same, so there is no need to update anything else -- just rebuild and deploy.
I made some changes to my solution which contains a couple of project and wanted to compile it again .. now it says Metadata file C:\myproject\bin\myproject.DLL could not be found...
I closed the VS and opened again and also deleted the bin and obj folder of that project, but still the same compile error...
Remove and re-add your reference.
There is something somewhere in your projects that tells the build to look for that dll. Most probably you have a reference in one of the other projects that doesn't reference the project, but references the project output directly.
This usually means one of the projects that other projects depend on in your solution isn't building correctly. Make sure you fix all errors and 'rebuild all'.