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.
Related
I was under review of team code. I observe they had used class ClassAby writing using AAA.BBB; at the upper portion of the class; also they have sometime used class ClassB by AAA.BBB.ClassB. There are two basic questions.
Is there any performance issue while using above scenario. What is recommended
When I declare namespace; are all classes get loaded of that namespace or not.
Please assist here. Thanks.
I'll answer these as best as I can, I don't have any sources on hand, just experience (maybe someone can help with that).
There is no performance issue with importing a namespace versus calling it directly. When the compiler runs through it, you can think of it as always being fully qualified in the end. The using statement for namespaces is more to assist the developer so they don't have to fully qualify it each time. In fact, for your ClassB example, it could be that there is a collision with multiple namespaces defining the same class name. For example, the Calendar class is both in System.Globalization and System.Web.UI, so you have to fully qualify one or the other when using them.
Generally, all code is compiled into an assembly by the project it's under. Referencing any code inside of the assembly will load all of the associated code. Note, however that the code isn't necessarily compiled for use by the JIT until it's actually called.
Namespaces are for organizing your code (while preventing name collisions). They have no bearing on performance at all.
Fully qualified names in code are distracting and noisy. I prefer to never have them. If there is a namespace conflict, a using alias can resolve that.
only for places where there is a conflict with there being two Class defined in different namespaces, and, even then, I'll still rather use a using to differentiate them:
using MyClassB=AAA.BBB.ClassB;
// :
var myClassB= new MyNS();
in terms of performance, you can see the answer here:
The using directive is only syntactic sugar that disappears during
compilation. Whether or not the namespace was included via using or
mentioned in a fully-qualified type name is totally irrelevant in the
resulting bytecode. Hence, there is no performance benefit at runtime
by using one or the other.
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".
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 was wondering, what the purpose of Namespaces in C# and other programming languages is...
As far as I know, they are used for two things:
To structure the project into meaningful pieces
To distinguish classes with the same name
My Question is: Are there any other things to consider when using namespaces? Do they have an impact on performance or something like that?
As far as I know, they are used for two things:
• To structure the project into meaningful pieces
• To distinguish classes with the same name
That's basically it. I would add to your first point that namespaces provide structure larger than just that of the project, since namespaces may span projects and assemblies. I would add to your second point that the primary purpose of namespaces is to add structure to libraries so that it becomes easier to find stuff you need and avoid stuff you do not need. That is, namespaces are there as a convenience for the user of a library, not for the convenience of its creators.
A secondary purpose is to disambiguate name collisions. Name collisions are in practice quite rare. (If the primary purpose of namespaces was to disambiguate collisions then one imagines there would be a lot fewer namespaces in the base class libraries!)
Are there any other things to consider when using namespaces?
Yes. There are numerous aspects to correct usage of namespaces. For example:
violating standard naming conventions can cause confusion. In particular, do not name a class the same as its namespace! (See link below for details.)
using a namespace can bring extension methods into play that you didn't expect; be careful
where precisely the "using" directive goes can subtly change resolution rules in a world where there are name collisions; these situations are rare, but confusing when they arise
collisions often arise in contexts where machine-generated code is interacting with human-generated code; be careful in such situations, particularly if you are the one writing the code generator. Be very defensive; you don't know what crazy name collisions the person writing the human-generated half is going to create.
See my articles on this subject for more details:
http://blogs.msdn.com/b/ericlippert/archive/tags/namespaces/
And see also the Framework Design Guidelines for more thoughts on correct and incorrect conventions for namespace usage.
Do they have an impact on performance or something like that?
Almost never. Namespaces are a fiction of the C# language; the underlying type system does not have "namespaces". When you say
using System;
...
class MyException : Exception
...
there is no class named "Exception". The class name is "System.Exception" -- the name has a period in it. The CLR, reflection, and the C# language all conspire to make you believe that the class is named "Exception" and it is in the namespace "System", but really there is no such beast as a namespace once you get behind the scenes. It's just a convention that you can sometimes omit the "System." from the name "System.Exception".
According to MSDN a namespace has the following properties:
They organize large code projects.
They are delimited with the . operator.
The using directive means you do not need to specify the name of the namespace for every class.
The global namespace is the »root« namespace: global::System will always refer to the .NET Framework namespace System.
Secondly namespace has nothing to do with performance but if you have created your own namespace so you should follow the conventions across the project.
It doesn't affect performance. But for code readability, I would recommended remove unwanted using statements
Namespaces are a concept pulled from earlier technology, like XML. THe namespace gives context to your classes, allowing you to have say a CUstomer object in your domain and in your data code.
You can also use namespaces to alias, which still does the above, but allows shorter naming for the particular object.
domain.customer
versus
data.customer
You've touched upon the two main reasons. This is an old article from MSDN but it still applies: Namespace Naming Guidelines
In the Java world the naming practice is to reverse the domain name of the company who owns the product and include the product's name after that. So com.example.product might be a valid namespace, but you don't really see that in .NET so much.
Those are the big ones right there.
There aren't really performance benefits. At least, not directly. without namespaces framework would have to search the a lot more places to find the code you are trying to include - It would almost be like needing to load up the ENTIRE .NET framework for every project. Well, not really, but its close enough for this discussion.
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.