I've encountered a strange phenomenon today as I added a reference of a project to another project and trying to use an interface of the referenced assembly:
Situation:
The class MySampleApplication is in the project MyApplication.
The interface IMySampleApplication is in the referenced project MyApplication.Interfaces.
When I do this:
public class MySampleApplication : IMySampleApplication
Resharper adds the following using:
using global::MyApplication.Interfaces;
Question:
Why is it adding the global:: prefix and how can I avoid this?
Thanks in advance
You'll have two occurrences of MyApplication somewhere in your code, eg you'll likely have a class called MyApplication in your local project as well as the namespace in the MyApplication project.
The local MyApplication will take precedence over the namespace in your MyApplication project, so MyApplication.Interfaces will not be found. To get around this, the special alias global:: can be used to tell the compiler that in this case MyApplication refers to a base namespace and so MyApplication.Interfaces can then be correctly identified.
As to how to avoid it, that's easy to say, but it may be harder to achieve: rename one of them to remove the name conflict...
You probably have another entity called MyApplication in your project which is hiding the namespace.
See: "How to: Use the Global Namespace Alias (C# Programming Guide)"
Background: I am a novice in C#, and use Visual Studios 2010 Express.
I have a class (let's call it myclass) which I want to use in multiple projects. I used to add classes with Project->Add Existing Item... Which creates a copy of myclass.cs.
Now I just found out that when I build the original myclass.cs it creates a myclass.dll and places it in the release folder of my project.
But when I try to use this DLL, I get the following error:
The type or namespace name 'myclass' could not be found(are you
missing a using directive or an assembly refference?
Which is weird to me, because I already have referenced it (it is also in the Reference folder of my Solution Explorer). And I already have added this to my code:
using myclass;
So what am I doing wrong?
Update: When I tried my old method (add existing item -> myclass.cs) the error message goes away. So it's not a matter of spelling things correctly.
Add the dll first:
Click on references in your project-explorer in visual studio and add your dll then you can use it as you expected it.
Add the reference in your project and check that the target Framework version of that assembly fits the project.
Check the namespaces inside the assembly and then use them like:
using YourAssemblyNamespace.class
Okay so I found the answer myself. It turns out that when you use the using function, it automatically searches for all public classes in the namespace you want to use.
If it can't find a public class, it refuses to recognize the DLL.
Furthermore, not specifying a class makes it internal.
So:
class myclass // internal!
private class myclass // private!
public class myclass // only this makes it visible for others!
Everything was okay after changing class myclass into public class myclass.
I have to store some strings in the Settings file of my project. However, I am not able to access the Settings file to store the strings.
I definitely have accessed Properties file in an earlier project without facing any problems to store values.
Properties.Settings.Default.test = ...
MyApp.Properties.Settings.Default.test = ...
But here in the current project, I am constantly being driven mad by getting the Properties does not exist in the current context
Is there any setting or something that has changed because of which Properties does not appear in Intellisense?
I had this same problem occur when I had been copying and pasting code for plug-ins. It turns out that I had accidentally left the namespace of the other project in place when I copied. By changing the namespace back to the appropriate project, I was able to use the Properties.
at compile-time, Visual Studio generates a c# class which allows access to user and application settings. the generated class is defined in the default namespace specified in the project settings.
you may have to prefix any access to the Properties namespace with the default namespace defined in the project settings;
or you may change the default namespace: go to project settings, application tab, and edit the default namespace of the project.
Make sure your project has a settings file by going to the project properties and clicking on the Settings tab. If there is no settings file, it will tell you so and provide you with the option to create one.
I had this error when I accidentally had the wrong namespace as the Default namespace in the project properties.
To choose the default namespace, right click the project in the Solution ExplorerProperties->Application tab->Default namespace and check that it matches the namespace of your .cs files:
[...]
using System.Text;
using System.Threading;
namespace Correct.Namespace //<-- should match Default namespace field
{
static class Program
{
[...]
In my case, i have referenced a resource that has an Internal/Public access modifier. I have changed its access modifier to Public and the problem was gone.
First, try to recreate your project from scratch, if it's your testing environment. This step will recreate default namespace properly. You may skip this step if you are confident with your namespace configurations.
Second, if you still get Properties unrecognize as in my example where im trying to get data from sqlCon.
string connectionString = Properties.Settings.Default.sqlCon;
go to Project -> EventsandDelegates Properties as shown in the picture below. Make sure to create default settings file.
As soon as you create default settings under your Application settings, in my case it's SQL connection variable. Properties error will go away.
I just had the same problem. But the problem occured when I added a new setting to an already defined settings file (created a long time ago). Somehow adding a setting to the settings file made Visual Studio change the setting's namespace to the project default namespace (which had changed since the settings where modified last time).
So, because the settings access modifier was set to Internal, and the class trying to access the settings still where in the old previous namespace (still in the same project though), the settings became invisible from that class.
Quickest Solution i can offer is to double click on your resources.resx file if it exists, than change the Access Modifier Property at the top of the window from Internal to Public, Rebuild, which should compile successfully, then switch it back to internal and rebuild again. Should be fine after that.
In my case I was referencing one project (A) from another (B). Both in the same solution.
A has a public class (AClass) with a public static method. (AMethod)
I wanted to Test the results of this AClass.AMethod(...)
Visual Studio "colored" AClass in the call AClass.AMethod(...)
and I could right-click AClass and "Go to Definition",
which took me either directly to the source if I added referenced to the "Solution" project
Or to the DLL "outline" if I added reference to the DLL created by building Project "A"
But when I tried to build project "B" I got the error "AClass does not exist in current context"
It turns out Project B was targeting 4.5 and Project A was targeting 4.5.2
This answer helped: https://stackoverflow.com/a/15556365/1175496
Make sure you can see your setting in Settings.Designer.cs file. If not, try deleting and reentering the setting. For some reason, sometimes, the code auto generated by the tool does not include your setting. In that case, the setting wont be available in intellisense.
Funny, but in my case, I had defined the Properties in one project in the solution and was trying to access from another.
Hope this might help someone.
My issue with the "does not contain a definition for 'Properties'", was caused by adding a class to the namespace (JsonBreaker), with the same name as the namespace (ie JsonBreaker.JsonBreaker). Its notable that it was breaking compilation, as it seems some other folks are having a different experience.
namespace JsonBreaker {
public class JsonBreaker {
private readonly Options _opt = null;
...
I just changed the classname (and .cs filename) to Breaker, and my JsonBreaker.Properties.Settings.Default["InteractiveMode"] call started compiling again.
namespace JsonBreaker {
public class Breaker {
private readonly Options _opt = null;
...
I had this problem when running my web project in Visual Studio 2019. After unsuccessfully trying some of the solutions here, I closed VS2019 and re-opened the project from VS2017. Now the Properties namespace is being recognised.
My case:
I added a new database in the Solution Explorer
I tried:
string connectionString = Properties.Settings.Default.SlovickaSQLConnectionString;
My error:
I get:
Properties does not exist in the current context
Here is why:
I forget to add a new dataset in Data Sources panel.
This dataset has to be connected to the previously added database.
And now it works..
I have a class lib and I referenced it to another windows project. I added its namespace to my Form.cs (using SaglikNetClassLib;). they are seem unknown when I want to access to classes. I can see their properties and methods. But the complier says "Error 7 The type or namespace name 'SaglikNetClassLib' could not be found (are you missing a using directive or an assembly reference?), Do you have any suggestion?
KR,
Çağın
Are you targeting the .net Client Framework? Visual Studio let's you add references to incompatible assemblies, but then gives exactly that error.
Check your project settings to make sure you're targeting the full .net framework.
Also, check that the Ilalcar class is public and not internal (which is the default if it's only declared as class without any modifier)
You probably need an using statement to put the class into scope.
using SaglikNetClassLib;
C# won't auto suggest it if the project has not been rebuild. Also make sure the class library project has been build before using it in code.
Intellisense seems to lag behind a bit at times. Simply pressing f5 (run) sometimes rebuilds the project completely and simply runs or gives a better error message.
I'm getting this error
The type or namespace name 'DataVisualization' does not exist in the namespace 'System.Windows.Forms' (are you missing an assembly reference?)
Here is my using section of the class:
using System;
using System.Collections;
using System.Collections.Generic;
using System.Windows.Forms.DataVisualization.Charting;
using System.Windows.Forms.DataVisualization.Charting.Borders3D;
using System.Windows.Forms.DataVisualization.Charting.ChartTypes;
using System.Windows.Forms.DataVisualization.Charting.Data;
using System.Windows.Forms.DataVisualization.Charting.Formulas;
using System.Windows.Forms.DataVisualization.Charting.Utilities;
namespace myNamespace {
public class myClass {
// Usual class stuff
}
}
The thing is that I am using the same DataVisualization includes in another class. The only thing that I can think that is different is that the classes that are giving this missing namespace error are Solution Items rather than specific to a project. The projects reference them by link. Anyone have thoughts on what the problem is? I've installed the chart component, .Net 3.5 SP1, and the Chart Add-in for Visual Studio 2008.
UPDATE: I moved the items from Solution Items to be regular members of my project and I'm still seeing the same behavior.
UPDATE 2: Removing the items from the Solution Items and placing them under my project worked. Another project was still referencing the files which is why I didn't think it worked previously. I'm still curious, though, why I couldn't use the namespace when the classes were Solution Items but moving them underneath a project (with no modifications, mind you) instantly made them recognizable. :\
You are very likely missing a reference to the DataVisualization DLL. Note that although they share the namespace of System.Windows.Forms.dll, they aren't actually contained within it.
Solution items aren't used by compiled assemblies.
http://msdn.microsoft.com/en-us/library/1ee8zw5t.aspx
"They can be referenced by projects, but are never included in solution or project builds"
As far as I know, solution folders/items are really just meant for organizing things.
Are you getting actual build errors or just squiggles? Try building and look at the output window, does it succeed or fail?
In VS 2008 SP1 C# introduced a top level error squiggling feature. It's possible that if you open the solution item version of the file it will squiggle because of a lack of default references. The solution should still build correctly though.
If this is not the case try adding the file directly to the project (no link). See if that eliminates the error. If so then we know it has to due with a linked file and it can help track down the problem.