Type.GetType(string)

[the fuzz]

yeah g'day..... is it somehow possible to not include the version & public
key token in the call to Type.GetType(string)

ie something like

Type.GetType("System.Windows.Forms.ListView, System.Windows.Forms");

instead of

Type.GetType("System.Windows.Forms.TextBox,
System.Windows.Forms,Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089");

The first version doesn't work because the type
System.Windows.Forms.ListView doesn't reside in the current assembly or
mscorlib, but i don't want to have to include version information when
retrieving a type.

cheers
the fuzz

 

[Mattias Sjögren]

yeah g'day..... is it somehow possible to not include the version & public
key token in the call to Type.GetType(string)

You can use Assembly.LoadWithPartialName and pass in a partially
qualified assembly name. But see
http://blogs.msdn.com/suzcook/archive/2003/05/30/57159.aspx for good
reasons why you shouldn't do that. Why don't you have a compile time
reference to the assembly instead and use the typeof operator?



Mattias

 

[the fuzz]

You can use Assembly.LoadWithPartialName and pass in a partially
qualified assembly name. But see
http://blogs.msdn.com/suzcook/archive/2003/05/30/57159.aspx for good
reasons why you shouldn't do that. Why don't you have a compile time
reference to the assembly instead and use the typeof operator?

I serialize user controls at design time to an xml document which is stored
in a db, and provide a runtime designer so that our customers can manipulate
the layout of our program (but not add new controls). At runtime when a form
is loaded the xml document is recursed and the child controls properties are
set according to how the customer has modified the layout. kinda simplified
xaml

An xml document in its simplest form looks like the following at the moment:

<Test.Login assembly="DisplayEngine">
<System.Windows.Forms.ListView assembly="System.Windows.Forms,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="listView1" view="Details" location="360, 32" tabIndex="7" />
</Test.Login>

I worry that when new versions of the .net framework come out this will pose
an upgrade challenge because of the embedded versioning in the assembly
attribute. eg. my program will want to run on v2 which i know i can enforce
through the <supportedRuntime> & <requiredRuntime> attributes, but the xml
will still contain references to v1.1. do you think this will be an issue,
also wouldn't third party UI controls on my forms also have the same problem
here?

thanks,
the fuzz

 

[Mattias Sjögren]

I worry that when new versions of the .net framework come out this will pose
an upgrade challenge because of the embedded versioning in the assembly
attribute. eg. my program will want to run on v2 which i know i can enforce
through the <supportedRuntime> & <requiredRuntime> attributes, but the xml
will still contain references to v1.1. do you think this will be an issue,
also wouldn't third party UI controls on my forms also have the same problem
here?

The framework's unification feature should ensure that the
System.Windows.Forms assembly version matching the framework version
you're running under is loaded, even if you're requesting an older
version. For more details on unification policy, see

http://weblogs.asp.net/junfeng/archive/2004/11/23/268388.aspx
http://blogs.msdn.com/alanshi/archive/2004/02/15/73244.aspx



Mattias