We Keep Coding

Why can't enumerations from different DLLs be accessed through late binding?

I was trying to find out how I can access Excel's enumerations through COM interoperability using C#.
Its simple to do it using early binding but with late binding I only found out that I can access enums in the same file.
If the enumerations are in a different DLL they can't be accessed. So either I use the integer values or create my own enums.
Is it really not possible to access them through late binding? If so, why? I would expect that early binding is late binding code made easy by the IDE or so.

If the enumerations are in a different DLL they can't be accessed. So either I use the integer values or create my own enums.
It is by definition, not possible to access pre-defined enums via late-binding. Obviously they will appear as "integers" to .NET. Sure you could cast some int to an enum that you have defined or perhaps a constant but such code is only for your benefit and does not represent the strong contract the COM library usually publishes.
Is it really not possible to access them through late binding? If so, why? I would expect that early binding is late binding code made easy by the IDE or so.
Early-binding makes use of either COM Type Libraries or COM Interop libraries. These are essentially .NET wrappers around COM types by providing C# or VB.NET-familiar types. With it you get intellisense in the form of statement completion; parameter help; and method help. The compiler will help you in any mistakes you might make at compile-time. Early-binding only works if the type library or COM interop library is present.
Late-binding gives you nothing in the form of intellisense. There is no indication of what objects are available; what methods are present; nor what parameters to pass. Your code may compile but you could still get runtime errors. Late binding does not use nor require type libraries nor COM interop libraries.
In addition, the term late binding means something quite specific to COM. It generally involves the invoking of IDispatch to get a list of method names. I'm not sure that .NET's enumType.GetField("Bar").GetValue() qualifies.
Late Binding Example
Late binding C# code:
// You will get no intellisense help here
var progId = "Excel.Application";
dynamic excelApp = Activator.CreateInstance(Type.GetTypeFromProgID(progId));
excelApp.Workbooks.Add = true; // VS happily lets me type all this
dynamic workSheet = excelApp.ActiveSheet; // hope this all works at runtime
Late binding or not
Isn't this example accessing an enum via late-binding with reflection? The difference is that it only works for the same file
Perhaps, it's a form of late binding. I would probably use the term decoupled.
Late-binding in the COM world is generally used in one or more of the following scenarios:
a) don't know what you will be interfacing with ahead of time
b) you do know, but you don't have access to any type library either because its not installed or the developer never created it
c) want to decouple your app from any specific version of the COM library
The example you supplied which uses enumType.GetField("Bar").GetValue(null); tells me a few things:
you know you are dealing with Excel
you have access to a form of "type library" - one that contains definitions. In this case enum constants
You are somewhat coupled to Excel
With this in mind, I'm not sure why you want to follow a late-bound route. You seem to be taking the harder approach.
Tell me more
C# create excel sheet late bound

Getting "Argument type 'StreamSocket' is not CLS-compliant" warning on build

I'm developing a UWP library which has public properties and method parameters of StreamSocket class. However, I'm getting "StreamSocket is not CLS-compliant" warning. What's so special there that Microsoft decided to leave the respective assembly non-CLS-compliant and are there any potential issues I should know about when using/distributing this library? Maybe CLS incompliance will somehow limit the ways my library can be used by other developers?

Well, from the documentation:
If you design a CLS–compliant class library, your library will have a guarantee of interoperability with a wide range of programming languages; therefore, your library is likely to have a wider customer base than a version that is not CLS-compliant.
So the [obvious] answer is that they did not have "programming language interoperatibility" in mind when they coded that thing.
I am not surprised to be honest, MS is not exactly known for strictness (IE anyone?)
Read more here: https://msdn.microsoft.com/en-us/library/bhc3fa7f.aspx
UPDATE:
I will try to demystify this a little bit based on the comments.
The CLS (Common Language Specification) defines the features that any language that targets the .NET Framework MUST support. Hence, you should only care about it if your libraries are going to be consumed by a .NET language.
For instance, there is a restriction in the CLS that says that class and member names cannot differ only by case. You can't have one property named MySocket and another one named mySocket. This is important for languages like VB .NET which are not case sensitive.
In the case at hand, your library is exposing StreamSocket, which is not marked as CLS Compliant. What if this class has methods like the samples above and you try to use your library in some VB.NET project? This is what the compiler is warning you about.

COM Object Registration--Multiple allowed?

I have two COM objects with different GUID values, but the same name. One is a newer version of the other. What happens when I register both using Name.exe /regserver? I've looked in the registry, and they both show up with the same ProgID, but their respective GUID values are different. They point to their separate locations on the hard drive. Is this a problem?
I'm trying to get the old version of a project to work alongside the new version of a project (but not running at the same time), and I think these two things are fighting.
The COM objects were created in VB6. The code that uses them is C#. They are added to their individual C# projects as references. When one is registered, I can't compile the other (nor run successfully).
What other information would be helpful while investigating this issue?

Converting my comment into an answer:
You have created a new version of a component which is not backward compatible with the old version.
You really should change the ProgID to indicate that this is effectively a new component. Client apps will have to explicitly target either the new component or the old one. People often just append a version number (e.g. 2) to the ProgId.

You are violating hard COM rules. Either your replacement must be an exact match with the component you replace. Or you must generate a new version that:
Uses a different [Guid] for the coclass, you did that correctly.
Uses a different ProgId, you didn't do that. Boilerplate is to include a version number in the ProgId itself. So a Foo.Bar becomes Foo.Bar.2
Uses different [Guids] for the interfaces implemented by the class. This is easy to overlook since they are hidden so well in a VB6 component. Crucial however whenever the class is used from another apartment. COM needs to find the type library for the component so it knows how to marshal the interface method call. Be sure to declare your interfaces explicitly in your C# code.
The best way to double-check all this is by running OleView.exe, File + View Typelib command. That decompiles the type library content back to IDL, you will see the guids and interfaces. If you want to create an exact substitute for the old component then everything must match exactly. Exact same guids, exact same interfaces with the exact same order of methods and exact same arguments.

I haven't ever accessed VB6 ActiveX exes from .NET (just dlls), so this is a shot in the dark (and is weak enough to be just a comment except it is too long).
Perhaps you can create / export a .tlb each for the two VB6 components to compile your C# against. You shouldn't need the exes to compile.
Next manually add the registry entries as if they had separate Programmatic IDs (say MyComponent.ServerClass.1 and MyComponent.ServerClass.2) and then load them by name in your C#.

What is a dynamic language, and why doesn't C# qualify?

Listening to a podcast, I heard that C# is not dynamic language while Ruby is.
What is a "dynamic language"? Does the existence of dynamic languages imply that there are static languages?
Why is C# a dynamic language and what other languages are dynamic? If C# is not dynamic, why is Microsoft pushing it strongly to the market?
As well why most of .NET programmers are going crazy over it and leaving other languages and moving to C#?
Why is Ruby "the language of the future"?

What is a dynamic language?
Whether or not a language is dynamic typically refers to the type of binding the compiler does: static or late binding.
Static binding simply means that the method (or method hierarchy for virtual methods) is bound at compile time. There may be a virtual dispatch involved at runtime but the method token is bound at compile time. If a suitable method does not exist at compile time you will receive an error.
Dynamic languages are the opposite. They do their work at runtime. They do little or no checking for the existence of methods at compile time but instead do it all at runtime.
Why is C# not a dynamic language?
C#, prior to 4.0, is a statically bound language and hence is not a dynamic language.
Why is Ruby the language of the future?
This question is based on a false premise, namely that there does exist one language that is the future of programming. There isn't such a language today because no single language is the best at doing all the different types of programming that need to be done.
For instance Ruby is a great language for a lot of different applications: web development is a popular one. I would not however write an operating system in it.

In a dynamic language, you can do this:
var something = 1;
something = "Foo";
something = {"Something", 5.5};
In other words, the type is not static. In a statically typed language, this would result in a compiler error.
Languages such as C, C++, C#, and Java are statically typed.
Languages such as Ruby, Python, and Javascript are dynamically typed.
Also, this is not the same as "strongly or weakly" typed. That is something different all together.

I'm stunning at the way c# it's embracing a fundamental set
of programming paradigms.
We can say that c# alows a rich object oriented programming,
a rich component oriented programming,
a well integrated functional programing,
a complet set of query operations over differents types of data sources (linq),
a elegant aproach of cocurrent programming through pLinq and parallel extensions,
in the next release (c# 4.0) will have powerfull dynamic capabilities,
and it's almost sure that in c# 5.0 will have a solid set of meta-programming
features.
With just can say that c# it's doing a great job of integrating all this powerfull
stuff in just one tool box. That's in my opinion it's the way it must be,
because skipping from one programming language to another it's almost always very painfull.

C# is a statically typed language, because the type of every object you're working with needs to be known at compile time. In a dynamic language you don't need to know what type an object is at compile time. Maybe you import some classes that you don't know before hand, like you import all classes in a folder, like plugins or something. Or maybe even the type of an object depends on user-interaction.
You can achieve a similar effect by using interfaces or base classes, but it's not completely the same because you are limited to using classes that explicitly inherit from or implement that interface.
In dynamically typed languages it doesn't care what the type is when you compile it, it'll try to call the method you specified by name, if that method doesn't exist on the object it'll throw a run-time exception, so it's up to the programmer to ensure that that doesn't happen or handle it appropriately. You gain flexibility, but lose out a little on compile-time error checking.

Looking at the Wikipedia entry, we see that a dynamic language is one that does things are runtime that most do at compile time. Typically, in a dynamic language, a variable could change types quickly and easily, and there typically is no separate compile step (but rather either interpreted execution or really fast compiling). C# is a more conventional language, using variable declarations and being compiled.
The Wikipedia entry lists numerous dynamic languages.
"X is the Y of the future", on the other hand, means that somebody's trying to sell you something. (Not necessarily literally, but trying to influence your beliefs in a way convenient to the speaker.)

Did you know that VB6 is both static and dynamic?
If you declare variables with a given type, then you get static behaviour:
Dim name as Label
You can now only access members of name that are Labels and intellisense knows that.
If you have a class and add the implements keyword, then your class can implement methods of another class. This is inheritance of interface that VB6 allows. You can get some runtime polymorphism.
You can also declare variables like this:
Dim proxy As Object
Now intellisense doesn't give you any help and VB6 will allow you to do anything you like with proxy:
proxy.foo()
This line can sit inside a compiled and running program and cause no offence, especially if its not run itself. Its only when the line is run does the lookup take place.
You can also perform:
set proxy = <any instance>
and this will run. It doesn't matter whether <any instance> has a foo method or not.
And then any instance of any class that does implement foo can be assigned and the method called and VB6 will be happy.
Note that there are run-time performance penalties as you become increasingly dynamic.

In C# 3.0, the types of everything needs to be known at compile-time. It's a static language. A dynamic language uses dynamic dispatch at runtime to decide the type of things and what methods to call on those things. Both types of languages have their advantages and disadvantages. C# 4.0 will add dynamic capability. Anders Hejlsberg gave a great talk on static v.s. dynamic languages and C# 4.0 at PDC.

A dynamic language is generally considered to be one that can dynamically interpret & generate code at runtime. C# can't do that.
There are also dynamically typed & statically typed languages. Dynamically typed means that the type of a variable is not set and can change throughout the program execution.

The words static and dynamic are not cleary defined.
However, what is most often meant is two issues:
1) In static languages, the type of a variable (that is, the type of value the variable can contain or point to) cannot change during the course of a program. For example in C#, you declare the type of a variable when you define it, like:
int a;
Now a can only ever hold an int value - if you try to assign a string to it, or call a method on it, you will get a compile type error.
2) In static language the type of an object cannot change. In dynamic languages, an object can change in that you can attach or remove methods and properties, thereby basically turning it into a completely different object.

c# is statically typed, ie int i =0; try setting i to be a string. the compiler will complain,
where as python a variable that used to hold an integer can then be set to hold a string,
Static: Types are final,
Dynamic: Types can be changed,
c# is trying to add more dynamic like features, var for instance

There is no true "language of the future".
Different languages have different purposes.
At most, you could say Ruby is a language of the future.
According to Wikipedia:
Dynamic programming language is a term
used broadly in computer science to
describe a class of high-level
programming languages that execute at
runtime many common behaviors that
other languages might perform during
compilation, if at all. These
behaviors could include extension of
the program, by adding new code, by
extending objects and definitions, or
by modifying the type system, all
during program execution. These
behaviors can be emulated in nearly
any language of sufficient complexity,
but dynamic languages provide direct
tools to make use of them.
Most dynamic languages are dynamically typed, but not all.
Ruby is a dynamic language and C# is not, since Ruby is interpreted and C# is compiled. However, C# does include some features that make it appear dynamic.

A language is dynamically typed, that means a variable in that can be used for anything.
Variables are not typed, values are. A variable can have the value of any primitive type, or it can reference to any object.

What are major differences between C# and Java?

Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I just want to clarify one thing. This is not a question on which one is better, that part I leave to someone else to discuss. I don't care about it.
I've been asked this question on my job interview and I thought it might be useful to learn a bit more.
These are the ones I could come up with:
Java is "platform independent". Well nowadays you could say there is the Mono project so C# could be considered too but
I believe it is a bit exaggerating. Why? Well, when a new release of Java is done it is simultaneously available on all platforms it supports, on the other hand how many features of C# 3.0 are still missing in the Mono implementation? Or is it really CLR vs. JRE that we should compare here?
Java doesn't support events and delegates. As far as I know.
In Java all methods are virtual
Development tools: I believe there isn't such a tool yet as Visual Studio. Especially if you've worked with team editions you'll know what I mean.
Please add others you think are relevant.
Update:
Just popped up my mind, Java doesn't have something like custom attributes on classes, methods etc. Or does it?

Comparing Java 7 and C# 3
(Some features of Java 7 aren't mentioned here, but the using statement advantage of all versions of C# over Java 1-6 has been removed.)
Not all of your summary is correct:
In Java methods are virtual by default but you can make them final. (In C# they're sealed by default, but you can make them virtual.)
There are plenty of IDEs for Java, both free (e.g. Eclipse, Netbeans) and commercial (e.g. IntelliJ IDEA)
Beyond that (and what's in your summary already):
Generics are completely different between the two; Java generics are just a compile-time "trick" (but a useful one at that). In C# and .NET generics are maintained at execution time too, and work for value types as well as reference types, keeping the appropriate efficiency (e.g. a List<byte> as a byte[] backing it, rather than an array of boxed bytes.)
C# doesn't have checked exceptions
Java doesn't allow the creation of user-defined value types
Java doesn't have operator and conversion overloading
Java doesn't have iterator blocks for simple implemetation of iterators
Java doesn't have anything like LINQ
Partly due to not having delegates, Java doesn't have anything quite like anonymous methods and lambda expressions. Anonymous inner classes usually fill these roles, but clunkily.
Java doesn't have expression trees
C# doesn't have anonymous inner classes
C# doesn't have Java's inner classes at all, in fact - all nested classes in C# are like Java's static nested classes
Java doesn't have static classes (which don't have any instance constructors, and can't be used for variables, parameters etc)
Java doesn't have any equivalent to the C# 3.0 anonymous types
Java doesn't have implicitly typed local variables
Java doesn't have extension methods
Java doesn't have object and collection initializer expressions
The access modifiers are somewhat different - in Java there's (currently) no direct equivalent of an assembly, so no idea of "internal" visibility; in C# there's no equivalent to the "default" visibility in Java which takes account of namespace (and inheritance)
The order of initialization in Java and C# is subtly different (C# executes variable initializers before the chained call to the base type's constructor)
Java doesn't have properties as part of the language; they're a convention of get/set/is methods
Java doesn't have the equivalent of "unsafe" code
Interop is easier in C# (and .NET in general) than Java's JNI
Java and C# have somewhat different ideas of enums. Java's are much more object-oriented.
Java has no preprocessor directives (#define, #if etc in C#).
Java has no equivalent of C#'s ref and out for passing parameters by reference
Java has no equivalent of partial types
C# interfaces cannot declare fields
Java has no unsigned integer types
Java has no language support for a decimal type. (java.math.BigDecimal provides something like System.Decimal - with differences - but there's no language support)
Java has no equivalent of nullable value types
Boxing in Java uses predefined (but "normal") reference types with particular operations on them. Boxing in C# and .NET is a more transparent affair, with a reference type being created for boxing by the CLR for any value type.
This is not exhaustive, but it covers everything I can think of off-hand.

The following is a great in depth reference by Dare Obasanjo on the differences between C# and Java. I always find myself referring to this article when switching between the two.
http://www.25hoursaday.com/CsharpVsJava.html

C# has automatic properties which are incredibly convenient and they also help to keep your code cleaner, at least when you don't have custom logic in your getters and setters.

Features of C# Absent in Java
• C# includes more primitive types and the functionality to catch arithmetic exceptions.
• Includes a large number of notational conveniences over Java, many of which, such as operator overloading and user-defined casts, are already familiar to the large community of C++ programmers.
• Event handling is a "first class citizen"—it is part of the language itself.
• Allows the definition of "structs", which are similar to classes but may be allocated on the stack (unlike instances of classes in C# and Java).
• C# implements properties as part of the language syntax.
• C# allows switch statements to operate on strings.
• C# allows anonymous methods providing closure functionality.
• C# allows iterator that employs co-routines via a functional-style yield keyword.
• C# has support for output parameters, aiding in the return of multiple values, a feature shared by C++ and SQL.
• C# has the ability to alias namespaces.
• C# has "Explicit Member Implementation" which allows a class to specifically implement methods of an interface, separate from its own class methods. This allows it also to implement two different interfaces which happen to have a method of the same name. The methods of an interface do not need to be public; they can be made to be accessible only via that interface.
• C# provides integration with COM.
• Following the example of C and C++, C# allows call by reference for primitive and reference types.
Features of Java Absent in C#
• Java's strictfp keyword guarantees that the result of floating point operations remain the same across platforms.
• Java supports checked exceptions for better enforcement of error trapping and handling.

Another good resource is http://www.javacamp.org/javavscsharp/
This site enumerates many examples that ilustrate almost all the differences between these two programming languages.
About the Attributes, Java has Annotations, that work almost the same way.

Generics:
With Java generics, you don't actually get any of the execution efficiency that you get with .NET because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. For instance if you have a Foo<T> class the java compiler generates Byte Code as if it was Foo<Object>. This means casting and also boxing/unboxing will have to be done in the "background".
I've been playing with Java/C# for a while now and, in my opinion, the major difference at the language level are, as you pointed, delegates.

Please go through the link given below
msdn.microsoft.com/en-us/library/ms836794.aspx
It covers both the similarity and difference between C# and java