We Keep Coding

Replacing company and product name in namespace and library names

The standard recommendation for names of namespaces goes like this:
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
Similarly, for the names of assemblies Microsoft guidelines recommend:
<Company>.<Component>.dll
My place like many other small and medium sized companies went through several name changes as well as product name changes which make old namespace and assembly names obsolete. Changing it every year or two as marketing preferences change is quite a pain. Leaving the mix of the old and new namespaces is even bigger pain. In essence, I find the recommendation does not work well for many of us.
Anyone found a good way around it? Using 'technology' and 'component' instead of product name may help, but I am really struggling with what to use instead of company name?
Maybe I should accept that these names are dynamic and need to be 're-factored' just like the code...

I've had a similar situation. A couple thoughts...
Does your assembly naming matter? Is it visible to your customers? If your assembly names are visible, you could always change the name of the assemblies without changing the namespaces. Might be less of a pain. But if you're just deploying a server, and your customers will never see the assembly filenames, then maybe this isn't worth investing a lot of time in.
(And yes, it kills a little part of me to write that. Because I hate stuff like this. But sometimes it's just not worth it.)
Perhaps you could use a code-name for the product, and leave the company out. The codename could remain constant, or only change on major releases, when you would be updating references anyway.
This is a bigger change, but... I've had some good luck running a NuGet server for my project's assemblies. This may help manage some of the pain of changing - publish a new package with the new name, and upgrade all the users of that package. Still a pain? Yup. But maybe easier to pull off than managing assembly references directly.

C# using every namespace in the project

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.

C# visual Basics references not available

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?

Problem with recurring namespace-names

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();

Should I stop fighting Visual Studio's default namespace naming convention? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm working on an MVVM project, so I have folders in my project like Models, ViewModels, Windows, etc. Whenever I create a new class, Visual Studio automatically adds the folder name to the namespace designation instead of just keeping the project-level namespace. So, adding a new class to the ViewModels folder would result in the namespace, MyProject.ViewModels instead of just MyProject.
When I first encountered this, it annoyed me. My class names are pretty clear, sometimes even containing the name of the folder in them (e.g., ContactViewModel). I quickly found myself manually removing the folder name on the namespaces. I even tried at one point to create a custom class template (see this question), but I couldn't get that to work, so continued doing it manually.
I've begun to wonder, though, if this convention exists for a good reason that I'm just not seeing. I could see it being useful if you for some reason had lots of sets of identical class names organized into folders, but that doesn't seem like a particularly common scenario.
Questions:
Why is it common convention for namespace names to reflect folder structure?
Do you abide by this convention? Why?

Same as you - I fought this for the longest time. Then I started considering why I created folders. I found myself starting to create folders to represent namespaces and packages instead of arbitrary buckets.
For instance, in an MVVM project, it might be helpful to put views and view models in a separate namespace. MVC will have a separate namespace for Models, Controllers, and Views. It is also beneficial to group classes by their feature.
Suddenly, the project feels more organized. It is easier for other developers to find where features are implemented.
If you standardize on your namespace practices, all of your projects will have the same predictable structure which will be a big win for maintenance.

If you want some solid advice I'd recommend buying Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries which gives you all you need to know from the actual framework design team.
...the goal when naming namespaces is creating sufficient clarity for the programmer using the framework to immediately know what the content of the namespace is likely to be...
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
And importantly
Do not use the same name for a namespace and a type in that namespace
Fragmenting every 1/2 types into namespaces would not meet the first requirement as you would have a swamp of namespaces that would have to be qualified or used, if you followed the Visual Studio way. For example
Core
- Domain
- Users
- Permissions
- Accounts
Would you create
MyCompany.Core.Domain.Users
MyCompany.Core.Domain.Permissions
MyCompany.Core.Domain.Accounts
or just
MyCompany.Core.Domain
For Visual Studio's way it would be the former. Also if you use lowercase file/folder naming you're looking at renaming the class each time, as well as making one big namespace tangle.
Most of it is common sense and really down to how you would expect to see the namespaces organised if you were a consumer of your own API or framework.

i was annoyed by this as well but working with and refactoring projects with large codebases quickly taught me otherwise. Having embraced the concept i think that it's a very good way to structure your code "physically" as well as logically. When you have a large project and the namespaces do not match up to the folders it becomes difficult to locate files quickly. It's also that much more difficult to remember where things are...
Also, if ReSharper recommends it, then it's probably a good idea. E.g. R# will complain if your class' namespace does not match its folder name.

File system folders and namespaces both represent a hierarchy. I seems perfectly natural to me to match the two. I go even one step further and use a 1:1 relationship between files and classes. I even do so when I program in other languages such as C++.
Now that you question the relation between these two hierarchies, I seriously wonder what you would like to represent by the file system hierarchy.

One way of not following the convention is to create the file in the project root folder and then move it to the final sub-folder.
Anyhow, it is a convention I actually like. If I am splitting types into folders, then probably those types have some kind of conceptual grouping related to the folder. Therefore, it ends making some sense, their namespaces are also similar. Java takes this approach and enforces it with its package system. The biggest difference is that VS is only "suggesting" it to you, since neither the language or the CLR enforces it.

While I agree with everyone else, that a physical structure matching the logical structure is helpful, I have to say I also fight with Visual Studio's auto-naming. There are half a dozen reasons why I have to rename classes:
I use a root "src" folder to visually separate my code from embedded resources
I want different capitalization
I'll organize my code into subfolders for organization within a namespace
I like to separate interfaces from implementations and base classes
I feel like it
With thiose reasons, I've resigned myself to having to adjust those for every class I create. My strategy to avoid the issue is copying a file that has the namespace declaration I want, and then immediately delete the contents.

I think there are indeed valid reasons for having different structures for namespaces and project folders. If you are developing a library, the namespace structure should first and foremost serve the users of your API: it should be logical and easy to grasp. On the other hand, the folder structure should be primarily there to make life easy for you, the API designer. Some goals are indeed very similar, like that the structure should be logical, too. But there may also be different ones, e.g. that you can quickly select related files for tooling, or that it is easy to navigate. I myself for example tend to create new folders when a certain file threshold is reached, otherwise it just takes too long to locate the file I'm looking for. But respecting the designer's preference can also mean strictly following the namespace - if that is their preference.
So overall, in many cases it makes sense that both match, but I think there are valid cases to deviate.
What has been helpful in the past for me was creating a file (e.g. WPF UserControl) in one place to get the namespace right and then moving it to the "right" folder.

Before namespaces were introduced in C++ all C types were in the global namespace. Namespaces were created to segregate types into logical containers so it was clear what type is being referred to. This also applies to C#.
Assemblies are a deployment decision. If you look at the .Net framework a given assembly will contain multiple different namespaces.
Folder are to organize files on disk.
The three have nothing to do with each other, however, it's often convenient that the assembly name, namespace and folder names are the same. Note that Java collapses folders and namespaces to be the same thing (limiting the developer's freedom to organize files and namespaces).
Often we choose to organize files in a project into multiple folders because it's easier for me or my team to navigate the files. Usually this file organization has nothing to do with the namespace design we use. I wish the VS team would not default the namespace to be the same as the folder name or at least give the option back to not have this be the default.
Don't suffer, either change the template for new classes or correct the namespace after the new file gets created.

I also feel the pain with this 'by default' behaviour in Visual Studio.
Visual Studio also tries to set a namespace/directory match when you put your LinqToSql .dbml files in their own directory. Whenever I edit the .dbml, I have to remember to:
open the .dbml.designer.cs file
remove the directory/folder name from the namespace declaration
There's a way to stop this behaviour, though. It involves creating a custom class template.

While I agree that matching the namespace hierarchy to the folder hierarchy is handy, and a good idea, I think the fact that Visual Studio doesn't seem to support switching this feature off is disgusting. Visual Studio has a lot of applications, and there are plenty of coding styles and ways of structuring the source file folders that are perfectly fine.
Let's say there's thousands of files that belong in a namespace, but the programmer just wants to group them into folders to make the hierarchy easier to navigate. Is this really such a bad idea? Will this really make things so un-maintainable that it should be forbidden by the IDE???
Let's say I'm using Visual Studio to work with Unity. Now, all my scripts are in the "Assets.Scripts" namespace. Not only is there a useless Assets namespace which contains no scripts now, but "Assets.Scripts" is meaningless - it does not describe what project or part of project the source file belongs to. Useless.