Develop Reference

How can I know which assembly contains a given namespace? - C#

I am trying to do toast notifications in windows 10 in a WPF application. All the examples I see refer to a namespace
using Windows.UI.Notifications;
The only problem is that none of the examples I have seen explain what assembly contains that namespace and defines the classes I need.
In particular, I am looking for the ToastNotificationManager class.
In this case(or in general) how can I tell which assembly contains a given namespace?

You can not. Namespaces and assemblyx name have no correlaction. If you need to know which assembly - the documentation for a CLASS normally has that at the end.
Otherwise, you are free to put any class into any namespace regardless of assembly name.

For some assemblies made by Microsoft, you can search http://referencesource.microsoft.com/ (It is an amazing source for learning by the way). It will show the assembly in the tree.
Otherwise you should search the documentation and hope the author has put the assembly name there (MSDN documentation generally contains the assembly name).

You can use the Visual Studio Object Browser to identify assemblies containing namespaces by making sure you have View Containers selected instead of View Namespaces. Then, you can do a search for your namespace Windows.UI.Notifications.
From what I can tell, it is part of Windows Runtime in version 1.3, so it should already be available to your Windows Runtime application. I'm not sure if this is something that is part of the .NET BCL, which is why you might not be finding a specific assembly. Here is a great Msdn article on toast notifications as well.
You didn't specify what type of application you are building, but here is the article for doing this from HTML, and since that is possible, that means it is able to be done via COM in a non-Windows Runtime .NET application, or from another language even.

C# .net - Dll Naming Conventions in Interface / Implementation Scenarios

I need some suggestions for clever naming of dll and/or a hint if any naming conventions for the following scenario exist.
I have an interface definition and several types used by that interface definition encapsulated in one dll. Then I have an implementation of this interface in another dll.
The “special” thing about this situation is that I do not develop an application but more a collection of functionalities (aka framework) that is used by multiple applications of my company. These functionalities are accessed through its interface definition via MEF, so the user of this framework does usually not know, nor is it important to him, in which dll the implementation is (since he only needs to know and reference the dll containing the interface definition). Just in really uncommon cases he might want to know how the dll (the one containing the implementation) is named, because he wants to replace the implementation with his own.
I created some requirements for my dll naming:
The dll with the interface definition needs to be well named because this is the dll the user is referencing.
The namespace of the interface definition dll needs to be very well named (and be very intuitive) so the user really expects this definition in this namespace, where it would be the optimum that the namespace equals the solution structure.
The implementation dll must be named very clear, so the user can identify the dll in the working directory to remove it and install an own implementation.
The namespace of the implementation does not really matter since its only used internally.
The dll names should not be too long.
First, I came up with the idea to group all interface definitions of a specific type in one dll, that would create a very well named namespace since I can group for example all “services” in a dll called MyCompany.Services.dll, put all definition and types in that root (which creates the namespace MyCompany.Services), and therefore have kept the solution structure equal to the namespaces (which might be alo discussed here if this is useful or not).
But that generates a big problem:
If I signature the dlls and change something in my MyCompany.Services.dll, I have to recompile all implementation dlls even if this change only affects one of this n dlls. At that point I thought about putting each interface definition and ity types in an own dll (as described in the beginning of this post).

My 2 cents worth:
Use a common top-level namespace so everything that's part of your framework can be easily identified. You might not "need" it but it just seems silly not to.
Use descriptive names. Things like Basti.SpecialFramework.Interfaces.DataAccess.Customer would make a lot of sense to me.
Structuring the namespace around the structure / architecture of your system makes lots of sense.
Having a well structured namespace tree will help the interpretation of key works / terms in the same place, e.g: Basti.SpecialFramework.Interfaces.DataAccess.Customer vs Basti.SpecialFramework.BaseImplementations.DataAccess.Customer
Treat it a bit like developing Information Architecture or doing usability testing: come up with a draft set of names and see if your friends can figure it out. Do the eqivalent of a Card Sorting exercise - do you structure it: [Layer].[Interface / BaseImplementation] or [Interface / BaseImplementation].[Layer]? (I'm not sure exactly how you would do the card sorting exercise but I can see some strong parallels).
Descriptive names tend to be long, this goes aganist your last point; I agree long names might not be "easy" and "convenient" but if they clearly convey what I need to know I would be okay with that.
By the way: I'm sure naming conventions exist for DLLs and Assembilies - I just don't know them off the top of my head. I guess I could Google / Bing them but I guess you've done that already.

Use of Namespaces in C#

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.

assembly naming conventions

Assuming you have a namespace that is useful to more than one project in your company, in the format of "MyCompany.Core", would you have an assembly named exactly the same way or just "Core". Why or why not?

Use the standard .NET naming conventions, assembly names are covered here. I'll save you the (short) read:
Do choose names for your assembly DLLs
that suggest large chunks of
functionality such as System.Data.
Assembly and DLL names do not have to
correspond to namespace names but it
is reasonable to follow the namespace
name when naming assemblies.
Consider naming DLLs according to the
following pattern:
<Company>.<Component>.dll
Where <Component> contains one or more
dot-separated clauses.
For example, Contoso.WebControls.dll.

I believe it's best (opinion here!) to name the assembly after the root namespace it contains, in your case MyCompany.Core.dll. You never know if that file will make its way outside the company, and keeping track of it is just easier in general.
Imagine if Microsoft named System.Core just Core.dll (System.Core), then you had Core.dll (MyCompany.Core)....you imagine how that gets hairy fast.

I would name the assembly the same as the root namespace. This makes it easy to figure out what code is in which assembly, and prevents collisions with other projects (from other companies) that might also be using the ambiguious name "Core.dll".

I prefer MyCompany.ApplicationName.Core.DLL, this eliminates the chances of conflict if there are two or more applications from MyCompany.

if developing in a enterprise environment, this convention may be useful:
Namespaces follow the [DomainEntityName].[AssemblyName].[Purpose].[RelatedPurpose] format where the DomainEntityName is the root business functionality name and the AssemblyName is the functionally that is supporting the Business requirement.

Based on Microsoft DLL naming conventions, I prefer the following pattern:
<Company>.<AppName>.<FeatureName>.<Layer>.dll
For example:
MyCompany.Sandwichery.Ordering.API
MyCompany.Sandwichery.Ordering.Domain
MyCompany.Sandwichery.Ordering.Infrastructure

What is best thing to call your namespace in .Net

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.