I'm trying to figure out how to properly use namespaces when creating a public API out of a large heap of implementation code.
I'm writing an API to put a friendly public face on all of the code my company has created in order to hack around problems in our most frequently used framework.
The root namespace of my new project is called 'FrameworkSDK'.
Under FrameworkSDK, I have FrameworkSDK.CompanyNameLibrary, which is where all of the implementation code my company has created resides.
I'm attempting to write PublicFacingAPI, which would ideally put a nice face on top of FrameworkSDK.CompanyNameLibrary, so that new developers could start using it instantly, etc.
In what namespace should I put my new PublicFacingAPIcode?
Should it be place in FrameworkSDK.CompanyNameLibrary.PublicFacingAPI? Then whenever developers import this dll, that would be an absurd using statement.
I could place the code in the FrameworkSDK namespace, but then all of my public classes would need to include the using statement using FrameworkSDK.CompanyNameLibrary or using FrameworkSDK.CompanyNameLibrary.SubNameSpace.
Where should this code go?
Thank you
I don't find SDK.CompanyNameLibrary.CompanyInternalAPI to be so ridiculous. It's a bit long, but it's descriptive and anyone using the dll will know exactly what they're getting.
I don't see why you need a different namespace for the public-facing part. Make everything as friendly as you can, and for bits that really ought to be hidden, keep them as internal types.
I would then drop the "SDK" part, and change to something like:
CompanyName.BclPlusPlus
or some similar project name which gives the impression of enhancing the core .NET framework. I would definitely separate out the company name as a "root".
Related
I have (a lot) of legacy code that references one of my static classes, called AppContext. Sadly, references to this class have all been resolved in this legacy code by a namespace using declaration throughout. For the sake of argument, let's say the namespace is "MyNamespace" (it isn't, but it's just as bad)
Therefore, I have many, many modules that start off looking like this:
using System;
using MyNamespace;
My problem now is that Microsoft, in their .NET Framework 4.6, has introduced a new System.AppContext class. Obviously, all of my code uses System.
Now whenever I get to a line of code that looks something like this:
if (AppContext.MyProperty == "some value")
... I will get an error telling me that MyProperty is not a recognized member of AppContext.
Now as my users roll out Windows updates containing .NET 4.6 (or .NET 4.6.1) I find my distributed code is breaking all over the place.
I know that my brute force solution to this is to go to every place where I reference my class and apply an unambiguous namespace. This is a sensible thing to do and I will do it going forward. My problem is that I have a big installed base and fixing this everywhere for everyone will take a lot of time and a lot of work (especially considering regression testing/moving to production, etc.)
Is there any way to resolve the name conflict, short of adding an unambiguous namespace to each reference of my class?
I'd really like to know if there is a quick/short term solution that I can use to keep my users from breaking my system with Windows updates until I can get a proper solution rolled out everywhere.
Add using AppContext = MyNamespace.AppContext to the top of every file.
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.
I've got a bit of a conundrum on my hands.
I'm currently compiling a load of 'code snippets' into reusable libraries that I obviously intend to use in multiple applications.
I'm having trouble deciding on an appropriate namespace and assembly name.
Basically, I've currently got JasonSummers.Validation as an example for my validation library, since I have no 'company' and no specific project which the code applies to.
However, later on, when I come to use said namespace in a client's project, I don't think it's really appropriate to have my name referenced in code which they will probably own the IPR for.
I would just use 'Validation' as the namespace (after all, StructureMap is StructureMap, not JeremyMiller.StructureMap) but this may cause confusion for future developers as 'Validation' is used in the 'System' set of namespaces provided by .net
All comments greatly appreciated.
You can always use name from biology e.g Tribulus. or any other for your root namespace. So your code goes into e.g Tribulus.Validation or Tribulus.Utilities etc. Toplevel namespace need not to be a functional name. It can be just a signature of a company or just a unique interesting name as i mention.
In my personal experience, I maintain a code base for that useful functions at source level, i.e., I copy every function I need in every project, under my client brand and assembly name.
I didn't found be useful to keep that functions at assembly level, exactly because that: it'll contain some names which can generate confusion and for an extra reason: a client paid for some functionality, but not for another (include in a general assembly). So, I just pack what he/she bought.
An option could be to use a neutral name, like Reusable and to merge your utility assembly by using ilmerge framework command.
Take a look at Microsoft's Namespace Naming Guidelines
I got it as an answer from Konamiman to my question which is related to yours.
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.