From what code are you trying to access the item?
There are essentially two steps that need to be taken to reference a class:
- Add a reference to the class' assembly in the project.
- Add a
using directive to the class' namespace in the code file.
It sounds like you're performed the first step. What about the second? That's what this error means:
The type or namespace name 'HttpCookie' could not be found (are you missing a using directive or an assembly reference?).
To perform step 2 above, you actually have a couple of options:
- Fully-qualify the class name. So, instead of using
HttpCookie you would use System.Web.HttpCookie.
- Add a
using directive to the code file. At the top of the file (and this would need to be done for any file which uses classes in this namespace), you would add using System.Web. Then you could just reference HttpCookie directly.
Additionally, the first part of your question brings up a separate issue entirely:
The name Response does not exist in the current context
This again goes back to my question about where you're accessing this value. When you're writing code in, say, the code-behind for an ASPX page, you have access to the various bits of ASP.NET web contexts by default. These are provided by the base Page class. Things like Request and Response are readily available.
However, if you're trying to access these objects from outside of that context (such as from a custom class or another assembly), you'll need to reference that context manually. This can be done by using a factory on the System.Web.HttpContext class:
Request becomes System.Web.HttpContext.Current.RequestResponse becomes System.Web.HttpContext.Current.Response
This is because Request and Response aren't actual classes. They're properties on the current web context which are of type HttpRequest and HttpResponse. Those properties are mapped for you when you're in the same context, but outside of that context you'd need to reference them fully as demonstrated above.
One thing to note is that it's not generally considered good practice to have dependencies on the web context outside of where it's already available. So if you're creating a custom class or another assembly then you might want to take a step back and think about the design.
If your custom classes depend on the existence of a current instance of HttpContext then that code can never be used outside of a fully-aware web application context. So the code is less re-usable. So, depending on what you need from that context, you can re-factor the code to not need the context itself but only to require that the necessary items from the context be provided.
This isn't necessary to get you past your current issue, but it's something to keep in mind going forward.
