In each my .cs file I have tons of "using" lines including other namespaces, like that:
using Game.Models.Main;
using Game.Models.DataStore;
using Game.Manager.MapManager;
using Game.Network.Player;
What if in the beginning of every new .cs file I include "using" statements for all existing namespaces in my code? Are there any downsides of that? Like performance or anything I can't think of?
Why I want that: in Eclipse you can press Ctrl+Space and you'll see the list of definitions starting with the typed characters. In Visual Studio however, you can see that only if the class you're typing is among the "using" namespaces. So when you write a new class you have to type every other class name in full.
It would probably slow down visual studio's intellisense, but as for a compiled product, it would not affect the resulting binary by having superfluous using statements.
If you want to remove superfluous using statements then you can right-click on the using statements, and go to "refactor" > "sort and remove"
There is not much downside except if you ever have classes with the same name in different namespaces (like Color in System.Drawing.Color and System.Windows.Media.Color) than adding all namespaces can either cause compile errors or complete change of behavior of the code.
Normally you only want to include the namespaces you are using. This way you can avoid naming collisions and programmer confusion.
As far as IntelliSense is concerned, if you want something from another name space just start typing in the namespace, IntelliSense will list the namespaces and so you can drill down to what you are looking for.
Related
we are changing the name of our product, so i also want to rename the namespaces of our
framework-classes. But now i have the problem, that i don't know in which programms and scripts our namespaces are used. Is there a way in c#, to locate the same class in two different namespaces?
I know the solution, that i could inherited from my classes in the new namespace, but this is a very bad solution i think. So I have no idea how to solve this problem, because simply renaming all namespaces doesn't help and will cause a lot trouble.
Thank you!
If external scripts are referencing your assembly using the old namespace names then those names will have to remain in your assembly in you wish to continue to use those scripts. If you also want to create new namespace names to reflect the new name of your product, those names will also need to be hardcoded into your assembly. This will inevitably lead to problems!
I would recommend one of the following:
Leave the namespace names as they are.
Rename the namespaces in full and update the Python scripts at the same time.
I would definitely not recommend the faux 'inheritance' method, or any other solution which results in duplication within the assembly.
You could search the whole project / solution of course, but that seems sort of messy and time-consuming too, if you've got more than a trivial project.
Are you using Resharper? For this type of task, you definitely should be. If so, there is a chance this could at least help you on your way:
Rename the folders your source files are in in the Visual Studio Solution Explorer (this should in theory be easier than looking at each source file one by one, right?).
Now open one source file that you know will have the wrong namespace due to a renamed folder. It should appear with a blue squiggly line, as in the picture below.
Use the Resharper tip (pyramid to the left, or Alt + Enter) to open the context meny thingy also shown below.
Select Find all issues of this type in scope, and select Solution as your scope. That might at least help you get an overview of which classes you need to change the namespaces for, and go through them and change them systematically.
As for your scripts, I would guess that you best bet is to do a plain text search for the old namespaces - possibly a search and replace. Perhaps you can include your scripts in a VS solution, and use the built in search there to scan and fix them. That might at least ease the pain a little..
I can't even get off the ground.I DO KNOW HOW TO ADD REFERENCES, (this."""mshtml""" NOT[working])
using System;
using system.text;
using mshtml; // i cant seem to access this
I'm confused on why when I type mshtml it's in capitals, MSHTML. The problem I'm having is I'm just using a variety of tutorials but can't seem to even start them as this is my first problem.
I have manually browsed when adding references to my application but it doesn't seem to work. I keep getting the capital letter version, except there is no capital letter version of MSHTML.dll in my directories on my PC. If for some reason I don't have this file can it been downloaded for free safely or are my tutorials just too old?
Also just to let you know I understand where these files are meant be, in regards to folders locations ect. I thought if I just add the reference in to my project it should just be there.
Thank you for pointing out that this is your first C# program. It helps us understand the level at which to try to answer.
First, I'd like to address a statement you made:
there is no Capital letter version of MSHTML.dll in my directories
It seems that you're confusing Namespaces with .dll names, which is something I struggled with myself at first. There's a full explanation here, but it may be too technical for beginner level developers.
In a nutshell, at the top of the file where your "using" statements are, you're telling the compiler where to look for certain classes and code by Namespace.
A Namespace is a logical grouping of code. For convenience and clarity, developers group similarly functioning code into Namespaces. For example, Data Access code is in the System.Data Namespace.
When adding a .dll you're adding an actual file reference. In a less-confusing world, .dlls would be named to reflect the Namespaces contained within them. However, it's not always that simple. It' is perfectly possible for me to create a dll named "DaveStratton.dll" that contains Booyah.Encryption, Simple.Functions or any other Namespace I want. There really is no correlation except by convention, and it's not enforced."
For example, if you look in the MSDN Library at the System.Data.SqlConnection class.
The Class name is actually SqlConnection, and it lives in the System.Data Namespace. The System.Data Namespace is contained in the System.Data.dll. (because the developers were following convention and did it this way for clarity.) Screenshot below:
If you look at other classes, you may find discrepancies.
For example, the System.Configuration.SettingsBase class: The SettingsBase class in in the System.Configuration namespace, but if you look at the assembly information, you'll see that it's in System.dll. And the System.Configuration.ConfigurationManager is in the System.Configuration.dll.
So, long story short, you need to know the Assembly (.dll) name when adding a reference in Visual Studio, but you need the class/assembly name when writing your code. In your using statement, you need capital letters because the Namespace is capitalized, ewven if the .dll isn't.
I think you have a misunderstanding by your terms 'capital letter version'.
The name of a dynamic link library, although usually indicative of its purpose and aptly named, isn't strictly tied to the contents of the assembly. You can call it what you want (within reason and limits of the system) and the code inside remains the same.
If you've added a reference to a 'MSHTML.dll' file, then it is very probable that a namespace of 'mshtml' is defined - I didn't say ideal, but probable. Casing within the code does matter though - so if, for instance, Intellisense is showing you a case-variant version of what you're typing then it's probably that. Either way, it won't be what you've been typing if you ignore it.
If you could reference the tutorials you were following then it would likely be easier to see what the actual problem was. Other than that, go ahead with the code that it provides.
As an aside, I'd recommend some reading up on Assemblies in .NET.
it sounds like you need to add a reference to your project first. Open up your solution, in the right project explorer, expand references, right click references to add a reference. Now find the Microsoft.mshtml and add that as a reference.
See here for your using problem, you need to add a reference (right click project, add reference) to this particular COM lib 1: How do I use MSHTML in VB.NET?
I have a class named AppVisum.Membership.Views.AppVisum.Membership.Controllers.Membership._Page_Views_AppVisum_Membership_Controllers_Membership_Validate_cshtml. Yeah, I know it is hidious, but I rather think it has to be named that, and as for the namespaces, those are unnecessary, but the class is generated by a tool, and the folder needs to be named AppVisum.Membership.Controllers.Membership, so I don't know if I can change the namespaces. However, hideous names isn't the real problem, the main issue is getting to the class AppVisum.Sys.AppSys. The ide tells me that it can't find AppVisum.Membership.Views.AppVisum.Sys.AppSys, so how can I tell it that I want the root one?
[Edit]
Sorry I wasn't specific enough as I thought this would be a simple problem to solve. The global:: would've worked perfectly if this had been a normal .cs file, however, it's a razor-file and razor don't quite like #using global::AppVisum.Sys (that just translates to using global, which doesn't make any sense). I've found 2 possible solutions, the first is to simply change the rule that search for files to search for folders with _ instead of .. Then I'd get paths like AppVisum.Membership.Views.AppVisum_Membership_Controllers_Membership._Page_Views_AppVisum_Membership_Controllers_Membership_Validate_cshtml. This would probably work just fine, and unless someone comes up with a better alternative I think I'm going for that. Another option is to rewrite the custom-tool that generates the classes (it's opensource, so I think I should be able to do that too fairly simply). Hope that clarifies things.
Add the global:: prefix to the namespace.
try:
using Sys = AppVisum.Sys;
or:
using AppSys = AppVisum.Sys.AppSys;
Basically, you can reduce ambiguity by aliasing types and namespaces in your using directives. (And the aliases don't need to be the same as the type/namespace names, they just are in my examples.)
As SLaks mentions in a comment, you should basically fix your project's default namespace - either that, or avoid creating the folder hierarchy. You've tagged this question with C#, but is your generated code actually in VB? While the VB compiler prepends the project's namespace when compiling, I don't believe the C# compiler does, so I'm surprised you're getting this namespace to be honest.
I disagree with your claim that "hideous names isn't the real problem" - I'd say it is the real problem, and making it hard to get at a particular namespace is one consequence of the problem. Fix the real problem (the bad namespaces) and the rest will go away. Using global:: etc is just a workaround, and one that you'll need to apply all over the place. It would be better to sort this out once and for all.
Basically if you can tell us more about how you've got into this situation, we're more likely to be able to help you get out of it.
maybe you can simplify by adding an using alias :
using AV = AppVisum.Membership.Views.AppVisum;
and in the code :
var s = new AV.Sys.AppSys();
edit typos
Hi,
This is possibly a moronic question, but if it helps me follow best practice I don't care :P
Say I want to use classes & methods within the System.Data namespace... and also the System.Data.SqlClient namespace.
Is it better to pull both into play or just the parent, ie...
using System.Data
using System.Data.SqlClient
or just...
using System.Data
More importantly I guess, does it have ANY effect on the application - or is it just a matter of preference (declaring both the parent and child keeps the rest of the code neat and tidy, but is that at the detriment of the application's speed because its pulling in the whole parent namespace AND then a child?)
Hope thats not too much waffle
It doesn't make any difference to the compiled code.
Personally I like to only have the ones that I'm using (no pun intended) but if you want to have 100 of them, it may slow down the compiler a smidge, but it won't change the compiled code (assuming there are no naming collisions, of course).
It's just a compile-time way of letting you write Z when you're talking about X.Y.Z... the compiler works out what you mean, and after that it's identical.
If you're going to use types from two different namespaces (and the hierarchy is largely illusional here) I would have both using directives, personally.
Click Organize->Remove Usings and Visual Studio will tell you the correct answer.
Firstly, it has no effect on the application. You can prove this by looking at the CIL code generated by the compiler. All types are declared in CIL with their full canonical names.
Importing namespaces is just syntactical sugar to help you write shorter code. In some cases, perhaps where you have a very large code file and are only referring to a type from a specific namespace a single time, you might choose not to import the namespace and instead use the fully-qualified name so it's clear to the developer where the type comes from. Still, though, it makes no difference.
Express what you mean and aim for concise, clear code - that's all that matters here. This has no effect on the application, just on you, your colleagues and your future workers brains.
Use whatever happens when write your type name and press Ctrl + .,Enter in VS.
As I get more and more namespaces in my solution, the list of using statements at the top of my files grows longer and longer. This is especially the case in my unit tests where for each component that might be called I need to include the using for the interface, the IoC container, and the concrete type.
With upward of 17 lines of usings in my integration test files its just getting downright messy. Does anyone know if theres a way to define a macro for my base using statements? Any other solutions?
I know I shouldn't say this out loud, but, maybe reconsider your design.
17 usings in 1 file = a lot of coupling (on the namespace level).
Some people enjoy hiding the usings in a #region. Otherwise, I think you're out of luck. Unless you want to put the namespace on all your referents.
Can't stand Resharper myself. But I also can't stand messy using statements. I use the Power Commands add-in for VS, which has a handy 'Remove and Sort' using statements command (among other good things).
There are four possible problems here;
The namespaces in your code are dividing your classes too finely. if you have, for example;
using MyCompany.Drawing.Vector.Points;
using MyCompany.Drawing.Vector.Shapes;
using MyCompany.Drawing.Vector.Transformations;
consider collapsing them to the single MyCompany.Drawing.Vector namespace. You probably aren't gaining by dividing too much. Visual Studio Code Analysis/FxCop has a rule for this, checking the number of classes in a namespace. Too few and it will warn you.
You are putting too many tests into the same class. If you are referencing System.Data, System.Drawing, and System.IO in the same class, consider writing more atomic tests -- some which access databases, some which draw images, and some which access the file system. Then divide each type across three test classes.
You are writing tests which do too much. If you are referencing a lot of namespaces, your tests may be coupling too many features together. This kind of coupling can often be buggy, so try to break big, wide-ranging functions into smaller parts, and test these in seperate files.
Many are redundant. Are they all used, or are they just copy-pasted from other files. Right-click on the code editor and choose from the 'Organise Using' options to remove unused statements.
Does anyone know if theres a way to
define a macro for my base using
statements?
Do you mean that namespaces you use often are automaticly added to each new class? If yes, Resharper can do that too. Additionaly it has a feature to put the usings in a region on code clean-up. Resharper may be the way to go (you won't regrett it as I can say from my own experience).
VS2008 added an "Organize Usings" context menu, which has a Sort, Remove, and "Remove and Sort" option which will do what you want per file. The Visual Studio Power Commands add-in adds a context menu in the solution explorer for projects and solutions which is a "Remove and Sort" for all files in the project and all projects in the solution, respectively.
If you want to change the default using statements that are done when you create a new file, take a look in the C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Code\1033 directory. It contains a bunch of zip files that you can modify to change the templates for Code files (Obviously move up the directory structure to change other languages or other types of files).
See here for more information.
It may help to use aliasing. Not sure it it's worth it, but instead of:
using System.Web.UI;
using System.Web.Mail;
using System.Web.Security;
... Control ...
... MailMessage ...
... Roles ...
you can use:
using W = System.Web;
... W.UI.Control ...
... W.Mail.MailMessage ...
... W.Security.Rolse ...
Resharper - the add-in for Visual Studio - has a feature that strips unsued Using's from a file, but I don't know anything that does quite what you describe.
In VS2008, you can right click on the CS file and choose 'Organize Usings'. It will strip unused using and sort them for you too. Other than that, I would just use #region. Also, CTRL+M+O will collapse all your regions functions, etc at design time. I use this shortcut A LOT!