When creating a Type from a string type name [e.g., via Type.GetType(<type name string>)], when is it necessary to qualify the type
name with an assembly name? In other words, when is "Namespace.Path.To.Type.TypeName, HostingAssemblyName" required, rather than
just "Namespace.Path.To.Type.TypeName"?

Also, in those cases where the HostingAssemblyName qualification is required, what format is required? Does the version, culture and
public key information need to be included (in some or all cases)?

- Mark

Hello Mark,

Why not just use typeof(<your type>) like Type theType = typeof(Test); if
this Test type is known at compile time?

MO> When creating a Type from a string type name [e.g., via
MO> Type.GetType(<type name string>)], when is it necessary to qualify
MO> the type
MO>
MO> name with an assembly name? In other words, when is
MO> "Namespace.Path.To.Type.TypeName, HostingAssemblyName" required,
MO> rather than
MO>
MO> just "Namespace.Path.To.Type.TypeName"?
MO>
MO> Also, in those cases where the HostingAssemblyName qualification is
MO> required, what format is required? Does the version, culture and
MO>
MO> public key information need to be included (in some or all cases)?
MO>
MO> - Mark
MO>
---
WBR,
Michael  Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

Michael,

Because the Type isn't known at compile time. For example, I have a wizard library which lets you pick wizards and wizard pages to
include in a wizard you create in a custom designer at design-time. In such a case the library needs to be able to deal with Types
that are not (and, in fact, cannot be) known when the library is written.

- Mark

Mark,

If you don't specify the assembly name, the calling assembly and
mscorlib.dll will be searched. So the answer is, whenever the type is
not implemented in any of those assemblies.


You should always include the full assembly name.


Mattias

Mattias,

Thanks for the quick reply. I'd like to pull on the thread a bit more, if you don't mind.

What I should've explained in my earlier post is that most of the time I'm using the string Type name to create Types at design
time, using the IDesignerHost.GetType() method. This method seems to be the only reliable way of creating Types from class
definitions that are part of a project at design time. So what I really would like to know is what "rules" apply to Types created
through that interface. Can you enlighten me about that?

Here are some interesting things I've noticed about IDesignerHost.GetType():

IDesignerHost.GetType() doesn't seem to "care" that the assembly name is not included, provided the Type you're creating is defined
somewhere in the current solution. In fact, it cares so little that even the following will create the correct Type:

ProjectA:
    ClassA

ProjectB:
    ComponentB

Calling IDesignerHost.GetType("ProjectA.ClassA, ProjectB") from within a custom designer for ComponentB will return
typeof(ProjectA.ClassA)...even though the wrong assembly name is appended to the Type name (I found this out as a result of a
bone-headed mistake, not by design).

It also appears that I can leave off the assembly name in any call to IDesignerHost.GetType(), provided that the Type is defined in
the current solution or referenced in the current project. In terms of the example above, if I move ProjectA out of the solution,
but retain a reference to it in ProjectB (which is now the only project in the solution), then
IDesignerHost.GetType("ProjectA.ClassA") still returns a valid Type.

- Mark

Hi Mark,

Is project A and project B strong typed? Also, which is referencing which?
If B is referencing A, we should use

ProjectA.ClassA, ProjectA

Assume the ProjectA is the namespace for ClassA, and also the assembly name.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Kevin,

Neither is strong named.

You may have been confused by my example because, well, the way the Framework handles calls to IDesignerHost.GetType() is pretty
confusing!

To enlarge upon my earlier example:

ProjectA (assembly name AssemblyA):
    ComponentA

ProjectB (assembly name AssemblyB):
    references ProjectA
    ComponentB
        CustomDesignerB (for ComponentB)

Within CustomDesignerB, you would expect to have to call IDesignerHost.GetType("ProjectA.ComponentA, AssemblyA") in order to create
a Type representing ProjectA.ComponentA.

Calling IDesignerHost.GetType("ProjectA.ComponentA") works just as well. In fact, from a little bit of testing it appears that you
never have to specify the assembly in the IDesignerHost.GetType() call, provided the Type you're creating is defined in an assembly
referenced in ProjectB.

That's sort of understandable: whatever routine searches for the metadata used to create a Type probably starts by looking in the
current project (ProjectB, in my example) and the assemblies it references.

But what's really weird is that IDesignerHost.GetType("ProjectA.ComponentA, AssemblyB") works just as well. Apparently, if the
metadata search can find the information it needs from the Type name, minus the assembly add-on, it ignores the assembly add-on.

I discovered this by accident; I meant to do the call as IDesignerHost.GetType("ProjectA.ComponentA, AssemblyA"), but goofed up.

At this point my main interest is in understanding how IDesignerHost.GetType() does its work, since it looks like what I need, but
the documentation on it is pretty sparse. I like that it can create Types at design-time which are defined in the source code of the
project I'm building (I need that capability in some of my custom designers and UITypeEditors). But I'd like to know more details,
so I can see if it may cause some problems for me down the road.

Do you have access to any information on the "guts" of how IDesignerHost.GetType() works, and how it differs from Type.GetType()?
They do behave differently!

In my example, calling Type.GetType("ProjectA.ComponentA, AssemblyA") or Type.GetType("ProjectA.ComponentA") within CustomDesignerB
returns a null...unless you first call IDesignerHost.GetType(), after which Type.GetType() works just fine. I presume that means
IDesignerHost.GetType() is loading metadata from the current project someplace where Type.GetType() can access it, but that
Type.GetType() isn't smart enough to do that load itself.

- Mark

Hi Mark,

Unfortunately, I don't know the difference of the implement of these two
method. You can try to use the reflector to check them. The
IDesignerHost.GetType is implemented by the VS.NET IDE, not .NET framework.

Also, we can only make sure that if we get correct results with correct
usage. It is an abnormal way to use the IDesignerHost.GetType, if you
supply the incorrect assembly name. It might lead to unexpected results.

Kevin Yu
Microsoft Online Community Support

============================================================================
==========================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
============================================================================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

When to Strong Name an Assembly?
FW 1.1 problem
.NET Frame work 1.1 install problem
compare byte[]
Monitor.Wait problem