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.
Related
If I recall correctly, in the good old C++ days MSDN used to be helpful in that it would show you not only the header file you needed to include to access a particular function, but also the DLL you needed to link to where that functionality was implemented. But these days, while MSDN tells you the namespace in which an object is defined, it doesn't tell you what reference you need to add to get at that object. Isn't or shouldn't there be a simple way to find all the .NET objects referenced in various answers posted about the web, mostly here on SO? How do you find which assembly contains an object? (I happen to be looking for System.ComponentModel.ExpandableObjectConverter at the moment.)
The information is visible on the documentation page for system.componentmodel.expandableobjectconverter.
Just below the inheritance hierarchy, near the top of the page, you can see this:
Namespace: System.ComponentModel
Assembly: System (in System.dll)
This is such a dumb question, but I can't figure out the lingo to ask Google.
In Java if I wanted to import all subclasses I would use something like
java.util.*
And all of util would be imported.
Firstly, what is the proper lingo for what I'm doing in C# so I can start using Google more effectively. Am I importing namespaces? Libraries? Subclasses? (Can you tell I'm new at this?)
Secondly, since I'm here, how is this accomplished in C#?
PS- I did click on every related question stackOverflow threw at me to see if the answer would pop up. No luck. I'm simply without words to describe what I'm looking for. The example should do just fine but... Anyone who can take a moment to either explain the lingo to me or perhaps simply point me at something that can (in a nutshell, I have a couple books for the long haul) that would be great.
Firstly, let's differentiate between assembly references and namespaces.
Assemblies are what you add references to in your c# project, they are the libraries that contain the actual classes you need, usually found as DLL files. The .net framework contains many such assemblies, and Visual Studio will try to reference the most commonly used ones in your project (e.g. for a WinForms project it will automatically add a reference to System.Drawing.dll).
Namespaces are logical partitions of the classes in an assembly.
Once you reference an assembly in the project, all classes in all namespaces are available for use, if you provide their full name.
This is where the using directive comes in.
It is simply syntactic sugar for not having to write very long names all the time.
For example, assuming your project references the System.Drawing.dll assembly, you would have to qualify a class from this assembly using it's full name, for example
System.Drawing.Imaging.BitmapData
Because this is tiresome and bloats the code, if you start your .cs file with
using System.Drawing.Imaging;
you could then instantiate a class using just the name BitmapData.
This will be true only for the .cs file in which you added the using directive, not for the whole project.
Also, it's important to note that using one namespace does not bring in all nested namespaces, you have to using each one individually.
You must brush up on your your Google-fu
http://www.harding.edu/fmccown/java_csharp_comparison.html#namespaces
It can be called importing / referencing/ using namespace.
Such a language feature is not available in c#.
A little explanation: Namesspaces can be spread across multiple libraries. so when you use a namespace it may refer to it from multiple referenced assemblies.
It's called namespace and it's imported by a keyword using. For example:
using System;
This statement enables you to reference all the classes that exist in that namespace. They, however don't enable you to reference any class in the subnamespace of declared namespace. You have to declare each namespace separately. For example:
using System;
using System.Text;
Of course, you need to have a proper references added to the project where you're specifying the using directive.
Within .Net, you first would need to ensure that there is a referenced assembly containing the namespace you would like to import. Once that reference exists, you can use the 'using' directive to bring that namespace into the class so as to not have to fully qualify all object names. You can find more information on this directive on MSDN.
If I misunderstood, let me know and I'll do my best to get you pointed in the right direction.
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.
I am using a third party .Net dll in my code and when I add a reference to this dll from a VB.Net application it shows different classes in intellisense and object browser than when I use it in a C# project. Why is there this difference?
Edit
If designer intended it that way I'd like to know how to do it in my own dlls.
Without knowing the specifics, it is hard to say. Some possibilities that come to mind are:
The designer made it that way on purpose
Parts of the library are not CLR compliant, and therefore not visible by languages other than the one it was written in.
VB.NET provides the option to "hide advanced members". Perhaps it's the "advanced" members you're not seeing.
One thing to remember here is that intellisense is an approximation of what's allowed and legal in the program. It's goal is to be very close to true but often isn't. There are several reasons why a particular type may or may not show up in intellisense but does in C#
One of the 2 projects may be friends with the target assembly
Intellisense filters may exist on the documentation files which hide them from intellisense
Attribute filters on the type
Certain classes may get hidden due to case only differences in the name
Given that it also doesn't show up in the object browser, my guess is that the class has either intellisense or attribute filters that cause it to be hidden for VB.Net.
I have got a dll placed in a shared folder over development server. Is there any way to use that dll without adding reference in my application and without installing the same in GAC.
Thanks in advance.
Assembly asm = Assembly.LoadFrom(path);
See MSDN for late binding, reflection etc.
Small edit: A variable with the keyword "as" is asking for trouble. So "Assembly as" changed to "Assembly asm" should be safer.
You may want to look at the Managed Extensibility Framework or at Assembly.Load... in the base framework.
Why would you want to do this, though? You'd need to call any code within the Assembly via reflection (hence the suggestion that the MEF may be what you're really after).
Yes, it is possible...somehow. Have a look at the Assembly-Class. With it you can load assemblies from a file without knowing what you exactly load.
Using Assembly.LoadFrom would be the only way to have zero references, but you'd still need to share contracts.
What's the problem with adding a reference?
What are you going to do when someone wants to work on a laptop and the WiFi goes down?
Yes,
you can call Assembly.Load() and then make use of Reflection to call into the public interface (lowercase "interface" - what I mean is the methods, fields and properties) exposed by the assembbly.
But in order to do that you need to know what methods to call. It helps if you can be certain that the assembly includes classes that do conform to a known .NET interface.
This idea is the basis for "plug-in" architectures in many tools, where the tool loads any assembly in its "plugin" directory, instantiates classes, casts the result to an ISomething, and then invokes methods via that interface.
I also would read Suzanne Cook's .NET CLR Notes.
http://blogs.msdn.com/suzcook/default.aspx
If this assembly is in a shared folder, you may find that .NET security restrictions stop you working with classes in that assembly in quite the way you'd expect.
Rather than storing on a shared folder, you may want to consider checking in the assembly to your source code repository. (I've seen a "/lib" folder used to good effect for this). Then you can reference the assembly directly.
(There are also repository solutions such as Maven that can more properly control this. However, they don't play well with .NET, unfortunately.)