So, I have a class library that I know will be used by websites and I need to access the config settings. I added a reference to System.Configuration, but I cannot find ConfigurationManager in the class library. A couple of things, one when I added a reference to the System.Configuration, it shows up as "System.configuration" with a lower case 'c', which I thought was odd. Another thing, when I access System.Configuration, the closest thing to ConfigurationManager is "ConfigurationSettings". I viewed the properties of the reference in a web app that allows me to use ConfigurationManager and this class library and they both point to the exact same file. Do I need to do this another way?
Here is a SS of my reference to it:
See https://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager%28v=vs.100%29.aspx
It lies in System.Configuration namespace and assembly System.Configuration. Make sure you go to Framework tab in Add references and select System.Configuration
As of Visual Studio Community 2017, I was not able to find the DLL using any of the methods that are listed here in this answer nor in any of the more antiquated responses on this site or others.
I had to find this NuGet package, which was a little nerve-wracking for me as I've never used NuGet, and then installed it using NuGet which is shipped with Visual studio.
You can install version 4.4.1 via the command line using:
Install-Package System.Configuration.ConfigurationManager -Version 4.4.1
Or, by searching for "System.Configuration.ConfigurationManager" in the Nuget Package Manager.
For me, I was getting this even with the reference added. I tried shutting everything down and re-opening the project and still it wouldn't resolve what I had typed in.
Finally I just deleted my lines of code and typed in the fully qualified "System.Configuration.ConfigurationManager.AppSettings", and it "found itself". No real explanation for why that worked. It even figured out that the "using" reference at the top of the code was there so I didn't need to qualify it any longer. Weird!
I think it just comes down to some quirkiness in VS when doing some references. No real explanation to it.
Related
A little background. I'm relatively new to the NuGet package manager system, but so far I have installed a few packages.
The question I have regarding NuGet is how do we know how to reference the installed package using the using directive?
I know that NuGet packages have a descriptions in the NuGet package manager. However, they don't always show how to import the packages. So I mostly end up Googling for examples of the package that I install to see if there is an example that shows what the using directive is to import that package.
Recently I have installed the package Selenium.WebDriver.PhantomJS.Xplatform I have difficulty finding examples online that show where the package resides and how to import it.
The problem is that a NuGet package can contain zero or more assemblies that can be added as references to the project in which you install it. So there is no one-on-one relationship between packages and assemblies; neither is there between namespaces and assemblies (an assembly can contain multiple namespaces, or the same namespace can be used by multiple assemblies), so neither is there between package names and the names of the assemblies therein nor the namespaces therein.
So: you have to know what you're doing. There is a reason you chose to install Selenium.WebDriver.PhantomJS.Xplatform. Somebody must have told you to, or you must have read it somewhere that you should do that.
When you do come along a situation where you hear or read "You should install package Foo!", then that source should also give you examples for how to use the types contained within those packages. And that's where you should read which namespaces to import in order to do so.
Some libraries also don't need any code to function; they're plugin-like additions to other libraries that you should already have in place in order to use them.
Usually nuget packages have a github repository or maybe a website.
Sometimes you can find examples, sometimes you have to go through source code.
I went to their Github repository and found that one of the namespaces they use is: OpenQA.Selenium.
You can check their source code here.
when I put that using directive it tells me The type or namespace
name...
All above describes the details about how to know using directive, so add some details to clarify why nuget not responsible for it, what in VS responsible for it and what the Intellisense(the option ) can do for us.
NuGet packages how to know their using directive?
Nuget in VS is just a Package Manager, it won't know the using directive.
For the most nuget packages, they contain at least one assembly, when you consume the package, actually you add reference to the assemblies from the package. So it's equivalent to that you have some assemblies developed by someone, then you reference them locally(add=>reference=>browse) in your project. So in this situation Nuget won't know how to use the assemblies with using...
(Here we just talk about the assemblies in package, nuget package has much more advantage from its install.ps1,build content...)
What actually do this in VS for you is Intellisense, it's responsible for recognizing your using statement in code editor,and help provide quick-info suggestions.(add using namespace,import reference...)
The function you're talking about is Intellisense, not Nuget, and Intellisense is used to check if your using directive is correct, it will search whether the namespace you use exists in referenced assemblies, but it will only display wrong(if can't find) or right, it won't tell you how to use the assemblies and what namespace defined in them! That's something you need to go through source code or research the example, like Vyacheslav and CodeCaster answered.
Not much other information other than I'm trying to copy this:
https://learn.microsoft.com/en-us/windows/uwp/contacts-and-calendar/managing-appointments
And it's telling me that it can't find the type or namespace "Windows". Anyone know how to fix this or if there's a work around? It seems to be having the fit at "Windows" not the rest of it.
I've already checked the references, etc. Nothing seems to be working.
There are several ways to solve missing assembly.
If you know what DLL it is, you can import it directly by adding it as reference.
Make sure that the DLL you added as reference CopyToLocal property is true.
If the assembly came from Nuget Package and you just freshly downloaded the project from a repository like git, try right clicking the solution and select Restore Nuget Packages.
If your project does not have the right reference, try download it from the Nuget Package. Make sure that you install the correct version to your project.
In this case, it seems that your project is looking for a Windows.ApplicationModel namespace. Seems like you missed something in your setup. Please check this setup process of microsoft for UWP app development:
https://learn.microsoft.com/en-us/windows/uwp/get-started/get-set-up
With reference to questions/26393157/windows-update-caused-mvc3-and-mvc4-stop-working. The quickest way to resolve the warning below?
Assuming assembly reference 'System.Web.Mvc, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' matches
'System.Web.Mvc, Version=4.0.0.1, Culture=neutral,
PublicKeyToken=31bf3856ad364e35', you may need to supply runtime
policy.
I've had this happen with my NuGet packages every once in a while. I haven't been able to identify exactly how it happens. (I assume user error.)
I didn't need to upgrade anything to solve it, just clear the NuGet cache:
I use the nuget command line tool found here.
You can clear all caches with this command:
nuget locals all -clear
See: https://docs.nuget.org/consume/command-line-reference
You'll probably need to restart Visual Studio if it is open.
As per the best answer to the question....
Update MVC package (Visual Studio > Right click project/solution > manage nuget packages > Updates > Microsoft ASP.NET MVC > Update)
Manually add the compilation assembly
but then
Find - System.Web.Mvc, Version=4.0.0.0
and replace with - System.Web.Mvc, Version=4.0.0.1
Which will find all the hidden references in the Views/Web.config files.
Every time I have had this issue I always start by doing a rebuild which will clear your bin folder. You likely do not need to close and open visual studio, as I never have, and it should work.
If this doesn't work then try more complicated solutions like those above but this could be a quick, clean fix.
I was getting this warning in RoslynPad because one of the dll's I was referencing (for me it was mscorlib.dll) used a different version than the retrieved version via NuGet. As the warning states, you can solve it with solve it with a runtime policy with a link to the dll of the version you want to be using. Just add something like this to the top of your file:
#r "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll"
Sorry for the late reply but in my case this warning was showing up because I was using different versions of Microsoft.AspNet.Mvc across my Visual Studio solution. I was able to get rid of it by upgrading the older packages to the same version.
Hope this helps someone.
What worked for me after trying severally is to update application insights and all packages from NuGet. Then I ensured that there were no version conflicts on the App insights and it worked fine.
Don't refer NuGet Package Components and interfaces directly from your cshtml code. Instead, write your own components, extesion methods and view models referencing them from plain C# code placed in cs files. First, then you wouldn't obtain CS1702 warning. And secondly, this will facilitate future migrations to newer versions of the NuGet package or even another package: All necessary fixes will be shown you by the compiler.
This is probably the desired change in your run-time policy.
After tested all propositions, I finally succeeded to get rid of the warning by editing the .csproj of my web application and set the property MvcBuildViews to false.
Maybe this could help some of you.
I have a solution with 3 projects:
ParsersBase, that defines an interface IParseRule
ParsersLibrary, that has a reference to ParsersBase and defines a class HtmlImageUrlParseRule : IParseRule
ParsersLibraryTest, that has a reference to ParsersBase and ParsersLibrary and defines a test class with some test methods
When I'm trying to build it, I get a warning:
Reference to type 'AVSoft.ParsersBase.IParseRule' claims it is defined in 'c:\Users\Tim\Dropbox\projects\Image Downloader\ParsersLibrary\bin\Debug\ParsersLibrary.dll', but it could not be found
Why is VS trying to find AVSoft.ParsersBase.IParseRule in ParsersLibrary.dll? ParsersLibraryTest has a reference to ParsersBase; it just doesn't make any sense.
Another way this could happen is if you're using several NuGet packages where one, probably central, package has been updated but some additional functionality packages haven't been.
To work through my recent example - the error was "Reference to type 'ConsumerSubscriptionConfigurator<>' claims it is defined in 'MassTransit', but it could not be found". This is because we had updated MassTransit from 2 to 3, but we had not updated some of the other optional packages (MassTransit.log4net and MassTransit.Autofac) to the same version number. It appears as if assembly redirection had kept everything working until we tried to use one more additional feature.
This error seems to cover a variety of scenarios. In my case, closing and re-opening Visual Studio was the trick. After restarting Visual Studio, I was able to build the project as expected.
I had a similar problem. The site was running a cached version of the dll and not the one I had deployed to the bin directory. I cleared the temporary asp.net folder contents and this solved the issue.
It was my fault, I had a ParsersLibrary project at the start and then renamed it to ParsersBase, but I didn't rename an assembly name, then I added a ParsersLibrary project again.
So, two projects had the same assembly name and it's not very good, is it? :) Assemblies overlap each other, so I have this error.
I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. The problem was following: my solution had Target Framework = 3.5 and I added a reference to Microsoft.Practices.Prism v 4.0 which is built against the framework 4.0.
After changing target framework to 4.0 it worked
It looks like things are a bit easier now than they were before.
As other answer(s) have basically already stated, this error can result from an older version of the same NuGet package not having some of the newer types in it. While in production, this is generally managed through proper versioning, in development, you may end up reusing the same version number when making changes. And that's a likely place where this problem can arise.
To fix this, you can often just clear the cache by doing the following:
In Visual Studio, go to Tools > NuGet Package Manager > Package Manager Settings.
In the pop-up menu, navigate to NuGet Package Manager > General.
In the options on the right, click Clear All NuGet Cache(s).
I hit this exception today. The problem in my case was I had some.package v2.1installed in my host and some.package v2.3 installed in other projects. Update-Package on the host project to v2.3 fixed the issue.
I my case, I tried to test a WPF project with a .NET Core (3.1) test project which could not reference the needed WindowsBase.dll.
Updating/consolidating packages didn't help. Even a clean repo and a restart of Visual Studio didn't solve it for for me.
But rebooting did fix the problem!
#binki's comment helped me;
deleting all .vs, bin, and obj folders, and then reopening the project
ParsersLibraryTest needs to reference ParsersBase. The second part of the error should read "You must add a reference to assembly 'ParsersBase..."
I tried all of the above answers but none resolved my issue.
In the end, I checked in my latest code (GIT), then recloned the repository in a different location.
Not ideal, but at least problem solved.
I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. I have a lib of .Net 4 that was referenced by a .Net 3.5 program. After upgrading both to 4.61 it worked.
Seems like Func<T> is missing in .Net 3.5 and just upgrading that sample app would have been enough.
Further exp: Someone had added a signature in the library project (.Net 4) that uses a Func<T> parameter. But the sample program (3.5) already existed and ran fine so far. But at time of recompilation a dependency of a dependency clashed. Because mscorelib-3.5 had been already loaded. All happens at compilation time.
The only way I could overcome this error was to force uninstall of all nuget packages related and then reinstalling them. Sad but true.
I've just struggled with this error for a while now and finally get around it.
This is how to re-produce it and how I fixed it.
The problem was:
The packages were referenced by Right clicked -> add refernece -> Browse (choose). Then were added again as NuGet packages.
The solution was:
Remove the added references.
Remove the installed packages from .csproj.
Re-install the required packages from NuGet package mangager.
Close Visual Studio and re-open it.
Clean Project.
Build Project.
Note: If you couldn't remove the referenced files (no Remove option on right click) try close Visual studio and re-open it. Or delete or move the dll that were referenced then try again.
For me, I had chosen incorrect project, I was creating a class library project, I had to chose "Class Library (.Net framework)" but I had chosen "Class Library (.Net standard)"
Replacing the same resolved the issue.
The problem was following: my solution had Target Framework = 3.1 and I added a reference to Microsoft.EntityFrameworkCore.SqlServer v 2.0 which is built against the framework .
I had this problem with one of my library projects inside of a solution, after I switched from .NET Framework to .NET Standard. Eventually I just removed the project reference and added it again inside the application project that was reporting the problem. Oddly enough, the only thing that changed was project GUID switching to lower case from the previous upper case.
When I add a reference to my dll in Visual Studio project, I am able to use it, but when I compile my code or try to run it, I get an are you missing a using directive or an assembly reference?_ Error. I am able to confirm that I have the right using statement for my namespace and I am able to confirm that the dll is correctly loaded.
Anyone have any idea what I may not have right in this?
Go to project settings and make sure that you are not compiling the project for a .net version that includes the text "client profile".
I had just had an issue precisely like this, even if this is an old question thought I would add my 2c on what fixed it as none of the other answers helped:
For whatever reason, when I built the solution top to bottom a certain dll was not getting updated and output that held changed code. So while my solution had no visible errors, when you attempted to build, it was still referencing the old dll and started complaining.
It was simply a case of directly re-building the offending project and after that it picked up the latest dll and built happily.
This seemed to be a freak accident as no configuration had changed between when it worked / when it didn't.
Sometimes, JUST REBUILD THE SOLUTION.
The location of the DLL is important.
If you add a reference on your local machine to a DLL that is outside of your Visual Studio solution, it isn't necessarily copied into your solution files (depends on the type of solution/project).
If this is your problem, then you need to either put the DLL in the same path on the other machine, or copy it into your solution so it gets deployed along with the solution files, and change the reference.
You can also handle this with build instructions, but that might be beyond your aspirations at the moment.
Most likely your dll is referencing another dll that the client project is not referencing and your dll code is exposing a type or an interface from the 3rd dll to the client code.
If you post the exaCt message, we'll be able to help better.
Are you using .net 4.0?
If yes, this dll is probably not compatible with .net 4.0
In my case, the main project (WinForm) was configured Framework Target: FW 4.0 "client profile". I change to FW 4.0 and work perfect!!.
At first time i was looking in the referenced projects and they were ok, but de main project doesn't. I hope this help. Thank you.
In my case this compilation error has gone after adding the reference to Microsoft BCL Build Components via "Manage NuGet packages" context menu on problem project.
Before: I had project Main (console application) referencing project A (class library).
Project A had dependency on Microsoft BCL Build Components.
After: I started refactoring where I picked out several classes to the separate project New. It also depended on A. But the compilation error occurred on project New as if there was no reference New -> A (although Visual Studio didn't highlight allegedly not found interfaces and classes listed in the error list of compilation).
So I checked project A's dependencies and found there Microsoft BCL Build Components.
After adding it to New's dependencies everything worked fine.
The most interesting thing is that Main did not contain this dependency and it didn't need it.
Hope this helps.
You just Have to check your namespace of that class file again...it will work