What does this answer to another question mean?
Yes, creating a nested namespace is possible. However, I believe the
preferred methodology for something like this would be to create a
resource file
This gives you the added benefit of being able to change without a
code change, as well as to support multiple languages.
I am making a few namespaces and I want them to be all under one namespace (MyNamespace), but I don't feel like going and changing all the code to add nested interfaces, and naming them MyNamespace.N1 is not very compatible with intelli-sense.
Edit: My main problem is that namespace MyNamespace.N1 { } does not seem to work right with renames and stuff like that. Is it even a true nested namespace declaration?
Underlying Question: A namespace declaration with a period in it is two namespaces. Why, then, when I rename it, does it not act right with the rename. My question may be vague, but I have such a problem with it that I thought for sure a lot of other people would have run into it. If not, then just close it and I'll try to figure it out some other way.
I'm trying to figure out how to put all the namespaces in a project under one namespace. So you would access them using MyProject.MyN1.MyClass. If I declare the namespace like namespace MyProject.MyN1 { } and then try to rename it, the intelli-sense only looks at "MyProject" as the namespace, MyN1 is peripheral. But I'm really trying to rename "MyN1" and it doesn't like doing that.
Well, I tried that, and now I'm not sure what my problem was in the first place. As I described it it works fine. I think it was that if I try to add or remove a period in the namespace declaration it doesn't rename it right.
One way that would probably work is to using a global find and replace. What your actually trying to do is to rename two namespaces into one, and it's not going to let you.
Related
If I have a main project, call it MainProject, and a side project that's based out of MainProject called SideProject. Right now I've added a reference to MainProject in SideProject. but because almost all of the classes in SideProject reference some code from MainProject I have to prefix almost all of the classes in SideProject with
using MainProject;
I feel like there should be a better / more elequent way to do this that would let me state this once. Whether that's setting multiple default namespaces, or something in the App.xaml. I can't figure it out and I can't find the answer online. Does anyone know if there's an accepted convention for how to accomplish this?
No, the accepted convention is to use using MainProject; at the top of every single source file.
If you really don't like using directives at the top of the files, you could use the same namespaces in different projects or use subnamespaces. For instances, you could use the namespace MainProject.SideProject in your side-project.
I've inherited an old .NET 2.0 C# system in work, currently sifting my way through an enormous code base. As I am a graduate I'm interested in why the existing developers did certain things, certain ways. One particular habit the previous developers had was, instead of importing the references at the top of the class like so -
using System.IO;
They did this continually throughout - (rather than importing the reference at the top).
System.IO.File.Exists();
Could anyone shed some light what the difference(s) is/are other than having to type more code? The system I'm working on is a business object orientated system (CSLA), and with no prior experience to this methodology, could someone recommend a good way to approach learning a system which I've inherited. I appreciate you can't see the system I've got but a bit of insight from someone experienced would be appreciated.
Regards.
It's just a style choice. Some people like to use the full names to know that local type names won't conflict with system types.
using statements are just a way to help the compiler find the referenced types at compile time, there is no difference at runtime between;
using System.IO;
File.Exists();
and
System.IO.File.Exists();
Could anyone shed some light what the difference(s) is/are other than
having to type more code?
It's a coding standard / style choice as Joachim says.
I personally use usings for most namespaces but will use fully qualified names if it makes the code clearer in a particular case. Such as to avoid ambiguity.
Further, I've seen some teams use usings for .NET types and fully qualified names for types that they have developed or very specific scarse types that the team is not always aware of. Using fully qualified names states that this type is rare and this is the namespace it's in so you don't have to go looking for it.
Could someone recommend a good way to approach learning a system which
I've inherited
Don't try to understand everything up front. Learn what you need to know when you need to know it (when you are making changes). Gather a high level understanding about where things are so you can find them quickly when you need to work on them.
I usually prefer using statements but there are places where it will be ambigious to use it.
Consider the following
namespace MyNamespace
{
public class File
{
public static bool Exists()
{
return false;
}
}
}
Then use
using System.IO;
using MyNamespace;
File.Exist();//this is now ambigious
In such cases you've to use System.IO.File.Exist();
Or
using System.IO;
using MyFile = MyNamespace.File;
File.Exist();//this is call is not ambigious since File means System.IO.File only
Other than these I don't find any reason to use full name rather than using statements
Personally, I like using the full name if I'm only using something in that namespace once or twice in the class. This way, it doesn't clutter up IntelliSense, and it helps me focus on the namespaces I actually care about in that particular class.
I come from Java and see that package in Java is very convenient. When you move a class to another package, it will change automatically the package. (of course, by IDE such as Eclipse or Netbean)
But C# is using namespace and don't have my namespace renamed automatically like it does in Java. For example I have a file which namespace is com.app and I put it in com.app, but at later time, I move this file to com.lib folder and its namespace still be com.app. So, I find this is difficult to manage because I'm moving it manually.
Please give me help in how to fix my problem. (that namespace of file is named by folder it contains, and when I move to other, I will automatically change). Can we do it?
I fix the problem by using an IDE plugin called Resharper. (Among many, many useful features) it highlights when a namespace is wrong (based on the folder hierarchy and root namespace of the assembly) and can fix it for you.
Note that unlike in Java, there are sometimes very valid reasons for a class to be in a namespace other than the one inferred by the directory structure. A good example might be extension method classes, which need to be in scope in the class that is invoking them. Therefore it is common to have:
/myProject
/extensions
/MyExtensionMethodClass.cs
with a namespace like myProject (so that the extension methods can be used anywhere in myProject without a using directive)
Thats actually because C# has the concept of partial classes , that is , you can distribute your C# class along several files instead of just having it coded into a single file , like Java. For that reason , namespaces in .Net are distributed containers instead of centralized containers , defined by your namespace orperator.
In the past I've always gone and called my namespace for a particular project the same as the project (and principle class) e.g.:
namespace KeepAlive
{
public partial class KeepAlive : ServiceBase
{...
Then from other projects whenever i've called that class its always been:
KeepAlive.KeepAlive()...
I'm now beginning to think that this might not be such a good idea, but I'm sort of stumped what to actually call my namespace. What do other people do? Do you just have one namespace for all your projects?
We have this simple scheme:
CompanyName.ProductName
Then the application layer, e.g.
CompanyName.ProductName.Data
CompanyName.ProductName.Web
etc.
And inside divided per module and/or functionality, which normally correspond to folders
CompanyName.ProductName.Web.Shop
CompanyName.ProductName.Web.Newsletter
etc.
BTW: You can find answers to similar questions here:
.NET namespaces
Should the folders in a solution match the namespace?
Having the name of a class being the same as the namespace is a bad idea - it makes it quite tricky to refer to the right thing in some cases, in my opinion.
I usually call the project (and namespace) an appropriate name and then have "EntryPoint" or "Program" for the entry point where appropriate. In your example, I'd probably call the class "KeepAliveService".
CompanyName.ProductName.AreaOfSystem.SubAreaOfSystem
Never call them the same name as a class.
Our areas include things like:
Services
Smartcard
UI
Sub-areas are used sparingly but when relevant:
Smartcard.Mifare
Smartcard.DESFire
Ours don't correspond to folders because logically that may not be the case. To ease solution explorer navigation we might section off certain bits in folders but that doesn't necessarily mean the namespaces should follow the folder structure. Especially if there are only a few files in the folder (a namespace with few types is usually silly).
i name my namespaces with the common descriptor of all the things that go into that namespace.
I like the java package way: com.stackoverflow.Data (or whatwever the primary domain name of your company may be).
That way your namespaces won't be ambiguous.
we stick to the old
uk.co.company.system.layer
scheme that way we keep collisions down to a miniumum as we use a lot of MS Server products and it helps conceptual seperations.
eg.
uk.co.acme.biztalk.bizutils.
I am using an ASP.NET MVC project and everytime I add a class to a folder it makes really long namespaces.
Example:
Project = Tully.Saps.Data
Folder = DataAccess/Interfaces
Namespace = Tully.Saps.Data.DataAccess.Interfaces
Folder = DataAccess/MbNetRepositories
Namespace = Tully.Saps.Data.DataAccess.MbNetRepositories
Question:
Is it best to leave the namespace alone and add the using clause to the classes that access it or change the namespace to Tully.Saps.Data for everything in this project?
Leave them alone and add the usings. You're asking for trouble manually changing things like that (harder to debug, inconsistent with other projects, et cetera).
It is really up to you how you want to deal with it. If you are only going to be accessing a member of a namespace once or twice, then adding the "using" statement really doesn't do much for you.
If you are going to use it multiple times then reducing the namespace chain is probably going to make things easier to read.
You could always change the namespace so it doesn't add the new folder name if you are just looking to logically group files together, without creating a new namespace.
According to FXCop, and I agree:
Avoid namespaces with few types
A namespace should generally have more than five types.
also (and this applies to the "single namespace" suggestion -- which is almost the same to say as no namespace)
Declare types in namespaces
A type should be defined inside a namespace to avoid duplication.
Namespaces
.Namespaces help us to define the "scope" of a set of entities in our object model or our application. This makes them a software design decision not a folder structure decision. For example, in an MVC application it would make good sense to have Model/View/Controller folders and related namespaces. So, while it is possible, in some cases, that the folder structure will match the namespace pattern we decide to use in our development, it is not required and may not be what we desire. Each namespace should be a case-by-case decision
using statements
To define using statements for a namespace is a seperate decision based on how often the object in that namespace will be referred to in code and should not in any way affect our namespace creation practice.
Leave it. It's one great example of how your IDE is dictating your coding style.
Just because the tool (Visual Studio) you are using has decided that each folder needs a new Namespace doesn't mean you do.
I personally tend to leave my "Data" projects as a single Namespace. If I have a subfolder called "Model" I don't want those files in the Something.Data.Model Namespace, I want them in Something.Data.